Migration d'une stack outbound vers une architecture Claude-native
« Notre stack a tenu à 100 prospects. Elle casse à 5 000. On veut pas un dev pour patcher, un architecte pour rebuild. »
Ce qu'on observe sur le marché
Les SaaS B2B, équipes RevOps et agences cold email entre 5 et 20 personnes ont massivement bricolé leur stack en 2022-2024 autour d'Airtable + n8n + Markdown + outils d'envoi (Instantly, Smartlead, Lemlist). Ce stack tient parfaitement entre 50 et 500 prospects actifs. Il commence à craquer entre 500 et 1 000. À 5 000, il casse.
Les symptômes sont prévisibles : les automatisations n8n sautent silencieusement, les bases Airtable explosent à 160 tables interconnectées, les prompts vivent dans des champs texte non versionnés, les actions humaines qui devraient être automatiques s'accumulent. L'équipe passe plus de temps à patcher qu'à exécuter.
Le déclencheur arrive quand le dirigeant comprend que recruter un développeur pour patcher reproduit le problème. Ce qu'il cherche : un architecte qui rebuild proprement, sur une stack robuste (Postgres normalisé + MCP servers + agents Claude), et qui forme l'équipe à la maintenir.
Cas observé
Le pattern qu'on rencontre : agence cold email ou SaaS B2B early-revenue avec une équipe de 8 à 15 personnes, dont 1 à 2 personnes RevOps qui ont bâti la stack au fil de l'eau. Volume de 1 000 à 5 000 prospects actifs simultanément, 3 à 8 séquences en parallèle, et des marges qui se dégradent à mesure que les patches s'accumulent.
Stack logicielle actuelle (à remplacer)
Airtable (~160 tables interconnectées) · n8n (workflows d'enrichissement et d'envoi) · prompts Markdown versionnés sur la branche principale · Instantly ou Smartlead pour la diffusion · Slack pour les alertes manuelles
Stack cible (à construire)
Postgres normalisé (Supabase) comme source de vérité · MCP servers comme interface entre les agents et la donnée · agents Claude pour le scoring, l'enrichissement, la rédaction · interface admin légère pour les opérations exceptionnelles
Déclencheur exprimé
« On vient de passer un week-end à patcher des sync cassées. C'est la troisième fois ce mois-ci. Si on continue comme ça, on plafonne à 5 000 prospects et on perd le client suivant. Il faut rebuild, pas patcher. »
Workflow proposé
Formaliser — cartographie des 160 tables et flux
Lecture de l'existant : tables Airtable, workflows n8n, prompts versionnés, points de friction quotidiens documentés par l'équipe RevOps. Identification de ce qui doit migrer, de ce qui doit disparaître, de ce qui doit être réécrit. Livrable : un schéma de la stack cible validé.
Orchestrer — architecture cible Postgres + MCP + agents
Modèle de données normalisé sur Postgres, MCP servers comme couche d'accès, agents Claude orchestrés autour des cas d'usage clés (enrichissement, scoring, rédaction de séquence, gestion de réponse). Définition de la stratégie de migration progressive par segment.
Réaliser — build 6 à 10 semaines en migration progressive
Construction segment par segment : on migre une séquence cliente, on observe, on ajuste, on migre la suivante. La stack actuelle continue de tourner pendant la migration. À chaque étape, l'équipe RevOps utilise déjà la nouvelle architecture sur une partie du flux.
Garantir — 30 jours en parallèle avant bascule
La nouvelle stack tourne 30 jours en parallèle de l'ancienne sur tous les segments. Métriques comparées quotidiennement (taux d'envoi, taux de réponse, erreurs silencieuses, sync cassées). Bascule complète une fois la fiabilité confirmée à 99,5 % minimum.
Évoluer — runbook ops et formation équipe
Documentation opérationnelle : comment ajouter une nouvelle séquence, comment debugger un agent, comment ajouter un MCP server. L'équipe RevOps devient autonome sur les évolutions courantes. Plus besoin de nous appeler pour ajouter un champ ou changer un prompt.
Outcome attendu
- →Scalabilité de 100 à 5 000+ prospects sans casse
L'architecture cible tient en charge à un ordre de grandeur supérieur. La marge de croissance se chiffre en années.
- →Fiabilité passée d'environ 90 % à 99,5 %
Les sync silencieuses et les actions manuelles d'urgence disparaissent. Les week-ends de patch aussi.
- →Vélocité multipliée sur les nouvelles séquences
Lancer une nouvelle séquence passe typiquement de 2 jours de bricolage à 2 heures de configuration documentée.
- →Autonomie de l'équipe RevOps
L'équipe possède la stack, sait l'opérer, sait l'étendre. La dépendance à un prestataire externe disparaît.
Votre cas ressemble à celui-là ?
Décrivez-nous votre situation en quelques lignes. Nous vous répondons sous 48 h avec un diagnostic rapide.
Échanger avec un architecte →Cas pratique observé depuis la veille marché européenne. Identité du donneur d'ordre anonymisée. Chiffres reconstitués à partir du brief original et des ordres de grandeur sectoriels.