Analyse technique critique et constructive du stack Twisper (circa 2019-2021), traduit dans le monde technologique de 2026 (IA, agents, MCP, vibe coding), avec les bases d'un PRD pour vibe-coder un démonstrateur avec Audiogami inside.
D'après le document technique (section 5.2), l'infrastructure Twisper reposait sur un stack AWS classique mais solide pour l'époque.
| Composant | Technologie | Verdict 2026 |
|---|---|---|
| Compute | AWS EC2 | Dépassé — serverless/containers |
| Stockage objets | AWS S3 | Toujours pertinent |
| Base NoSQL | DynamoDB | Pertinent mais alternatives existent |
| Base relationnelle | MySQL / MariaDB | OK mais PostgreSQL domine |
| Cache | Redis | Toujours standard |
| CRM | SugarCRM (SaaS) | Obsolète pour ce use case |
| Gestion de projet | Jira / Agile | OK mais lourd pour startup |
| Design | Adobe Illustrator, Axure | Remplacé par Figma + IA |
| Architecture réseau | VPC multi-AZ (Ireland + Frankfurt) | Bonne pratique maintenue |
Cette architecture multi-régions avec 3 environnements, VPC peering et séparation des workloads montre que l'équipe technique (Santos à Lisbonne) savait construire de l'infra production-grade. C'est un atout pour un restart : l'expertise existe.
Un modèle de données centré sur la confiance plutôt que sur la notation. Le choix de DynamoDB (graphe clé-valeur) était cohérent pour modéliser des relations sociales et des recommandations géolocalisées à grande échelle.
Twisper ne réinventait pas la carte mais ajoutait une couche de sens social par-dessus Google Places. L'idée reste valide.
L'endpoint twisper.app/api/v1/{endpoint} montre une approche API-first qui permet des clients multiples (iOS, Android, web). C'est prescient et toujours la norme.
Pour une startup 2019, c'était en avance sur la courbe de conformité RGPD.
Une analyse honnête des contraintes héritées et de leur impact sur un restart.
| Limite | Impact restart |
|---|---|
| Monolithique sur EC2 — Pas de containers, pas de serverless | Critique |
| Dépendance totale à Google Maps API — Pricing imprévisible | Modéré |
| Pas de pipeline ML/IA — Aucune couche d'intelligence | Critique |
| CRM SugarCRM externalisé — Pas d'intégration native | Critique |
| Pas de monitoring applicatif — Seulement AWS CloudWatch basique | Modéré |
| DRP minimaliste — "On remonte en quelques minutes" | Modéré |
| Stack logiciel vieillissant — Java, jQuery, Foundation CSS | Critique |
Dans un stack qui n'existe plus (faillite 2021) → pas de code réutilisable directement
Connaît l'architecture mais le code est probablement perdu ou obsolète
Mais pas de données exploitables (conformité RGPD post-faillite)
Nom et positionnement "positivity" toujours disponibles et pertinents
Le graphe de confiance positive + la découverte géolocalisée + l'authenticité des recommandations restent des problèmes non résolus en 2026. Google Reviews est pollué. TripAdvisor perd en crédibilité. TikTok est éphémère et non structuré.
La voix — via Audiogami — est le chaînon manquant qui peut rendre la recommandation authentique, émotionnelle, et difficilement falsifiable.
Le stack recommandé pour Twisper 2026 : zéro DevOps, scaling automatique, coûts proportionnels à l'usage.
| Couche | Twisper 2026 (recommandé) |
|---|---|
| Frontend | Web app progressive (PWA) — React/Next.js ou SvelteKit |
| Backend | Edge functions + API serverless — Supabase / Vercel / Cloudflare Workers |
| Base de données | Supabase (PostgreSQL) avec pgvector pour embeddings |
| Auth | Supabase Auth ou Clerk — social login, magic links |
| Cartographie | Mapbox ou MapLibre (open source) + Google Places API (complément) |
| IA / LLM | Agents IA via MCP — Claude/GPT comme orchestrateur |
| Voice | Audiogami API — voice-to-structured-data |
| CRM | Notion / Airtable comme CRM léger + automations n8n |
| Hébergement | Vercel (front) + Supabase (back) + Cloudflare R2 (storage) |
| Monitoring | Sentry (erreurs) + PostHog (analytics produit) |
En 2026, les applications ne sont plus des interfaces figées — elles sont orchestrées par des agents. Pour Twisper :
Analyse les recommandations vocales (via Audiogami), détecte le sentiment, catégorise automatiquement, enrichit les métadonnées (lieu, type, contexte)
Vérifie l'authenticité des voix, détecte les patterns de fake reviews, cross-référence avec des profils vérifiés
Recommande des lieux en fonction du profil de goûts de l'utilisateur, construit à partir de ses recommandations vocales passées et de son graphe social
Le protocole MCP (Anthropic) permet aux agents de se connecter à n'importe quelle source de données (Google Places, Notion, CRM) via un protocole standardisé. Twisper 2026 peut exposer ses données via MCP pour être consommé par d'autres agents.
// MCP Server Twisper — Endpoints exposés search_recommendations(location, category, radius) → Chercher des recommandations vocales géolocalisées submit_voice_testimonial(audio_url, place_id) → Soumettre via Audiogami (transcription + structuration) get_trust_score(business_id) → Score de confiance basé sur les témoignages vocaux vérifiés // Accessible par : ChatGPT, Claude, Gemini, n'importe quel agent IA
Cela permettrait à n'importe quel agent IA (ChatGPT, Claude, Gemini) d'accéder aux recommandations Twisper nativement.
Contrairement à Twisper 2019 qui voulait être une app destination (téléchargez notre app), Twisper 2026 doit être une couche de confiance intégrable :
Un restaurant peut afficher ses témoignages vocaux Twisper sur son propre site
Les développeurs peuvent intégrer les recommandations Twisper dans leurs apps
QR code, WhatsApp, Telegram — pas besoin de télécharger une app
Les utilisateurs peuvent chercher des recommandations Twisper directement dans leur assistant IA préféré
Le problème fondamental de Twisper 2019 était : comment garantir que les recommandations sont authentiques ? La réponse textuelle est désormais compromise par l'IA générative. N'importe qui peut générer 1000 faux avis en quelques minutes.
La voix porte l'émotion, l'hésitation, l'enthousiasme. C'est beaucoup plus difficile à falsifier de manière convaincante.
Générer des voix deepfake crédibles reste plus complexe et coûteux que de générer du texte.
Enregistrer un message vocal filtre naturellement les trolls et les bot farms.
L'analyse vocale (tone, sentiment, confidence) ajoute une couche de données impossible à obtenir par le texte.
L'utilisateur parle naturellement : "J'ai adoré ce petit restaurant..."
Audiogami transcrit en temps réel
L'IA extrait : lieu, catégorie, sentiment, éléments clés
Interface HITL : l'utilisateur confirme/corrige en un tap
L'agent lie au Google Place, ajoute les coordonnées, calcule le trust score
Carte, widget restaurant, API/MCP
Un score composite basé sur 5 facteurs :
Analyse deepfake detection, cohérence biométrique
Corrélation sentiment vocal / contenu sémantique
Historique, réseau social, fréquence
Géolocalisation au moment de l'enregistrement, timing cohérent
Réactions et confirmations du réseau social
Ce score pourrait devenir un standard ouvert ("Swiss Trust Voice") — valorisant l'ancrage suisse et les valeurs de neutralité et protection des données.
| Standard / Pratique | Maturité |
|---|---|
| MCP (Model Context Protocol) | Émergent |
| OpenAPI 3.1 + webhooks | Établi |
| WebAuthn / Passkeys | Établi |
| PWA (Progressive Web App) | Établi |
| Edge Computing | Établi |
| Vector search (pgvector, Pinecone) | Établi |
| Sovereign hosting | Émergent |
Des recommandations vocales courtes (30-60s) avec géolocalisation, partageables comme des Stories Instagram mais persistantes et structurées.
"Qu'est-ce que je mange ce soir à Genève ?" → L'agent Twisper répond en citant des recommandations vocales réelles de ton réseau.
Intégrer les recommandations Twisper dans l'app Revolut (paiement + recommandation = boucle fermée).
Un badge exportable que les restaurants peuvent mettre sur Google, leur site, Instagram.
Vendre la brique "voice testimonials" à d'autres plateformes (Booking, TheFork, etc.).
Le scénario B est le meilleur rapport valeur/effort pour convaincre des investisseurs et valider le concept.
Le démonstrateur doit fonctionner de manière autonome et démontrer la valeur intrinsèque du concept, indépendamment de tout partenaire. Les intégrations partenaires seront des extensions futures, mais le design doit les anticiper (API-first, architecture modulaire).
Les questions à trancher avant de rédiger le cahier des charges complet.
Scénario retenu → Scénario B (6-8 semaines, ~10K CHF)
Revolut-first ou standalone-first ? → Standalone-first
Verticale prioritaire — Hospitality premium (fine dining) ou tous restaurants ? Impact fort sur le scope du démonstrateur
Rôle de Santos — Disponible pour contribuer au démonstrateur ou seulement consultatif ?
Données existantes — Y a-t-il des assets récupérables de l'ancien Twisper (design, branding, base de lieux) ?
Hébergement — Full Suisse (Infomaniak/Exoscale) pour le narrative "Swiss made" ou pragmatique (Vercel/Supabase US) pour la vitesse ?
Budget Audiogami API — Les coûts de transcription/traitement vocal sont-ils inclus dans les 10K CHF du projet ou séparés ?
Rédiger le PRD / cahier des charges du démonstrateur Scénario B, en s'appuyant sur les sections 3 à 6 de cette analyse comme fondation technique et produit.