Agentic coding : pourquoi tu vas exploser ta stack avant d'atteindre le product-market fit

Temps de lecture : 8 min. Pour les fondateurs, CTOs, et growth engineers qui pensent que Cursor + Devin = équipe de dev.

Le agentic coding va te faire gagner du temps. Et te coûter ta boîte.

Voilà ce que personne ne dit à voix haute dans l'écosystème startup en 2025.

Tu shippes 3x plus vite. Le prototype impressionne les investisseurs. Tu peux aller en démo sans avoir recruté un seul dev senior. C'est magnifique. Et c'est exactement le piège.

Le agentic coding — laisser un agent IA écrire, refactoriser et déployer ton code de manière autonome — est du levier pour les mauvais problèmes. Tu gagnes sur la vitesse d'exécution à court terme. Tu perds sur la lisibilité, l'ownership du code, et ta capacité à onboarder quand tu lèves. Trois choses qui définissent ta survie post-seed.

J'ai accompagné des startups early-stage depuis 2016. J'ai vu des fondateurs signer un term sheet avec une stack que personne dans la nouvelle équipe ne comprend. C'est pas un problème de talent. C'est un problème structurel que le agentic coding aggrave à une vitesse industrielle.

---

Le contre-argument que tu vas me sortir

« Mehdi, Cursor m'a permis de sortir un MVP en 3 semaines au lieu de 3 mois. Comment tu peux dire que c'est un problème ? »

C'est pas un problème. C'est le début d'un problème.

La vitesse au stade pre-PMF est une vertu. Personne ne conteste ça. Le problème c'est que la vitesse générée par les AI coding tools comme Cursor ou Devin est une vitesse sans mémoire. L'agent génère du code fonctionnel. Il ne génère pas de code maintenable. Il ne génère pas de code que ton CTO hire dans 8 mois va comprendre en 20 minutes.

Et là tu me dis : « Mais je ferai du refactoring plus tard. »

Plus tard n'existe pas dans une startup. Plus tard c'est quand tu as des utilisateurs qui reportent des bugs à 2h du matin. Plus tard c'est quand ton dev senior démissionne parce qu'il ne comprend pas ce qu'il a hérité. Plus tard c'est la Series A qui se complique parce que la due diligence technique est un champ de mines.

---

Le consensus faux : « La dette technique, on la gère après le PMF »

C'est la croyance la plus répandue dans les startups B2B SaaS en 2025. Et elle est partiellement vraie — et c'est exactement ce qui la rend dangereuse.

Oui, tu peux accumuler de la dette technique startup avant le PMF si c'est de la dette consciente. Un raccourci que tu documentes. Un workaround que tu sais localiser. Une abstraction que tu comprends assez pour expliquer à un externe en 5 minutes.

La dette générée par le agentic coding seul, c'est une dette opaque. Personne n'en est propriétaire. L'agent l'a écrite. Toi tu l'as acceptée parce qu'elle passait les tests. Et maintenant c'est dans ta base de code comme un objet non identifié.

Voici les chiffres qui te dérangent :

• McKinsey estime que les équipes consacrent 20 à 40% de leur temps à traiter de la dette technique non planifiée.
• Une étude Stripe de 2018 estimait que les développeurs perdaient en moyenne 17,3 heures par semaine à gérer du code legacy — soit 42% de leur temps productif.
• Dans une startup de 5 devs à 60k€ annuel, ça représente environ 260k€ de coût caché annuel avant même de compter le turnover.

Multiplie ça par une base de code générée en partie par des agents que tu ne peux pas questionner. Tu comptes combien ?

---

Le framework pour utiliser le agentic coding sans exploser ta stack

1. Distingue le code « jetable » du code « structurant »

Tout le code n'a pas la même valeur de longévité. Un script de scraping one-shot pour valider une hypothèse ? Laisse Devin l'écrire seul. Ton système d'authentification ? Ton modèle de données ? Ta logique de billing ? Jamais sans supervision humaine.

La règle simple : si ce module va être touché par plus de 3 devs différents dans les 18 prochains mois, tu ne laisses pas un agent l'écrire seul. Point.

2. Impose un « Ownership Gate » avant chaque merge

Avant de merger du code généré par un agent dans ta branche principale, quelqu'un dans l'équipe doit pouvoir répondre à ces 3 questions sans regarder la doc :

• Pourquoi ce module existe ?
• Qu'est-ce qui se passe si il casse ?
• Comment on le debug en production à 3h du matin ?

Si personne ne peut répondre : le code ne merge pas. C'est un gate simple. Brutal. Nécessaire.

3. Utilise le agentic coding comme un junior, pas comme un CTO

Cursor, Devin, et les autres AI coding tools sont des outils d'exécution exceptionnels. Ils ne sont pas des outils de décision architecturale. La différence est critique.

Tu demandes à un agent de coder une feature précisément spécifiée. Tu ne lui demandes pas de décider comment structurer ta base de données. Tu ne lui demandes pas de choisir entre une architecture monolithique et des microservices. Ces décisions ont des conséquences que l'agent ne vit pas — toi si.

4. Maintiens un « Living Architecture Document »

Peu importe ta vélocité, peu importe le nombre d'agents que tu utilises : tu as besoin d'un document vivant qui explique pourquoi ta stack est ce qu'elle est. Pas comment elle fonctionne — pourquoi elle existe dans cet état.

Ce document, un dev senior doit pouvoir le lire en 30 minutes et comprendre les 5 décisions structurantes que tu as prises. Si tu es incapable de l'écrire, c'est le signal que tu ne comprends plus ta propre base de code. Et là tu as un problème de growth engineering existentiel : tu ne peux plus itérer de manière prévisible.

5. Impose un ratio humain/agent sur le code critique

Règle empirique que j'applique avec mes clients SaaS : pour chaque heure de code généré par agent sur un module critique, 30 minutes de revue humaine. Ce n'est pas du perfectionnisme. C'est de la gestion de risque.

Sur un sprint de 2 semaines avec 40 heures de agentic coding sur des modules structurants : prévois 12 heures de revue dédiée. Ce temps n'est pas perdu. Il est investi dans ta capacité à recruter, à onboarder, et à passer une due diligence technique sans suer.

---

Le piège que tout le monde ignore jusqu'à la Series A

Voici ce qui se passe réellement quand tu arrives en levée de fonds avec une base de code majoritairement générée par des agents sans supervision structurée.

Le VC mandate une due diligence technique. Un cabinet externe audite ta stack. Ils demandent à parler au dev qui a écrit le module de billing. Il n'y en a pas. C'est Cursor qui l'a écrit en novembre dernier. Ton lead dev peut expliquer ce qu'il fait, pas pourquoi il est structuré comme ça.

Résultat : la valorisation est ajustée à la baisse. Dans le meilleur cas. Dans le pire, le deal se complique parce que l'acquéreur potentiel ne peut pas estimer le coût de remédiation de la dette technique.

J'ai un client SaaS — je ne citerai pas le nom — qui est passé de la validation PMF à une levée de 1M€. La due diligence a failli capoter à cause d'un module de gestion des permissions que personne dans l'équipe ne pouvait expliquer. Il avait été généré par Devin 6 mois avant dans une session marathon pour tenir un délai de démo. Ça a tenu la démo. Ça a failli tuer le tour.

Les abstractions à coût caché sont magnifiques jusqu'au moment où elles te coûtent tout. C'est exactement la promesse du agentic coding sans garde-fous.

---

Ce que le agentic coding fait vraiment bien — soyons honnêtes

Je ne suis pas en train de te dire d'arrêter d'utiliser Cursor ou Devin. Je suis en train de te dire de les utiliser sur les bons problèmes.

Le agentic coding excelle sur :

• Les scripts d'automatisation one-shot — enrichissement de leads, scraping, preprocessing de données.
• Les tests unitaires — générer une couverture de tests sur du code existant que tu comprends.
• Le boilerplate répétitif — formulaires, endpoints CRUD standardisés, migrations de base de données simples.
• La documentation — générer une première version de doc à partir de code que TU as écrit.
• Les expérimentations isolées — feature flags, A/B tests, prototypes de concepts qu'on jettera si l'hypothèse est fausse.

Sur ces cas d'usage, la vitesse est réelle et le risque est contenu. L'agent fait ce qu'il fait le mieux : exécuter des tâches bien définies avec une scope claire.

Le problème arrive quand tu lui donnes une scope floue sur un domaine critique. Et dans une startup pre-PMF, tout est flou par définition. C'est la nature du stade, pas une faiblesse de ton équipe.

---

La vraie question à te poser maintenant

Pas « est-ce que j'utilise du agentic coding ? » La question est : est-ce que quelqu'un dans mon équipe peut expliquer chaque module critique sans regarder le code ?

Si la réponse est non sur plus de 20% de ta stack, tu as déjà un problème. Peu importe qui a écrit le code — agent ou humain.

La vitesse sans compréhension n'est pas un avantage compétitif. C'est un emprunt à un taux d'intérêt que tu n'as pas négocié.

Le growth engineering durable — celui qui te permet de scaler après la levée, d'onboarder des devs seniors, de passer une due diligence propre — repose sur une règle simple : tu dois rester propriétaire de ce que tu construis. L'agent t'aide à construire plus vite. Il ne peut pas être propriétaire à ta place.

---

Ce que tu fais cette semaine

Trois actions concrètes, dans l'ordre :

• Audite tes 5 modules les plus critiques. Pour chacun, est-ce que tu peux expliquer en 3 minutes pourquoi il est structuré comme ça ? Si non, bloque 2 heures pour le faire avant de toucher autre chose.
• Crée ton Ownership Gate. Un checklist de 3 questions que tout PR de code généré par agent doit passer avant de merger. Ça prend 20 minutes à écrire. Ça peut te sauver 6 mois de dette.
• Démarre ton Living Architecture Document. Une page Notion. Les 5 décisions structurantes de ta stack. Pourquoi, pas comment. Tu l'écris toi. Pas un agent.

Si tu veux aller plus loin sur ce sujet — et notamment sur comment structurer une stratégie de growth engineering qui reste scalable même avec des outils IA — je publie régulièrement sur growthconsult.net et sur YouTube @GrowthLoupe.

Le agentic coding est un outil puissant. Comme tous les outils puissants, il amplifie ce que tu fais bien — et ce que tu fais mal. La question c'est de quel côté tu veux amplifier.