Voilà ce que personne ne dit à voix haute dans l'écosystème startup en 2025. Vous shippez 3x plus vite. Le prototype impressionne les investisseurs. Vous pouvez 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 votre code de manière autonome) est du levier pour les mauvais problèmes. Vous gagnez sur la vitesse d'exécution à court terme. Vous perdez sur la lisibilité, l'ownership du code, et votre capacité à onboarder quand vous levez. Trois choses qui définissent votre 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.
"Mehdi, Cursor m'a permis de sortir un MVP en 3 semaines au lieu de 3 mois. Comment vous pouvez 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 votre CTO hire dans 8 mois va comprendre en 20 minutes.
Et là vous me dites : "Mais je ferai du refactoring plus tard."
Plus tard n'existe pas dans une startup. Plus tard c'est quand vous avez des utilisateurs qui reportent des bugs à 2h du matin. Plus tard c'est quand votre 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.
C'est la croyance la plus répandue dans les startups B2B SaaS en 2025. Et elle est partiellement vraie, c'est exactement ce qui la rend dangereuse.
Oui, vous pouvez accumuler de la dette technique startup avant le PMF si c'est de la dette consciente. Un raccourci que vous documentez. Un workaround que vous savez localiser. Une abstraction que vous comprenez 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. Vous vous l'avez acceptée parce qu'elle passait les tests. Et maintenant c'est dans votre base de code comme un objet non identifié.
Voici les chiffres qui vous dérangent :
Multipliez ça par une base de code générée en partie par des agents que vous ne pouvez pas questionner. Vous comptez combien ?
1. Distinguez 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 ? Laissez Devin l'écrire seul. Votre système d'authentification ? Votre modèle de données ? Votre 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, vous ne laissez 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 votre branche principale, quelqu'un dans l'équipe doit pouvoir répondre à ces 3 questions sans regarder la doc :
Si personne ne peut répondre : le code ne merge pas. C'est un gate simple. Brutal. Nécessaire.
3. Utilisez 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.
Vous demandez à un agent de coder une feature précisément spécifiée. Vous ne lui demandez pas de décider comment structurer votre base de données. Vous ne lui demandez pas de choisir entre une architecture monolithique et des microservices. Ces décisions ont des conséquences que l'agent ne vit pas : vous si.
4. Maintenez un "Living Architecture Document". Peu importe votre vélocité, peu importe le nombre d'agents que vous utilisez : vous avez besoin d'un document vivant qui explique pourquoi votre 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 vous avez prises. Si vous êtes incapable de l'écrire, c'est le signal que vous ne comprenez plus votre propre base de code. Et là vous avez un problème de growth engineering existentiel : vous ne pouvez 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évoyez 12 heures de revue dédiée. Ce temps n'est pas perdu. Il est investi dans votre capacité à recruter, à onboarder, et à passer une due diligence technique sans suer.
Voici ce qui se passe réellement quand vous arrivez 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 votre 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. Votre 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 vous coûtent tout. C'est exactement la promesse du agentic coding sans garde-fous.
Je ne suis pas en train de vous dire d'arrêter d'utiliser Cursor ou Devin. Je suis en train de vous dire de les utiliser sur les bons problèmes. Le agentic coding excelle sur :
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 vous lui donnez 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 votre équipe.
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 votre stack, vous avez 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 vous n'avez pas négocié.
Le growth engineering durable (celui qui vous 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 : vous devez rester propriétaire de ce que vous construisez. L'agent vous aide à construire plus vite. Il ne peut pas être propriétaire à votre place.
Le agentic coding est un outil puissant. Comme tous les outils puissants, il amplifie ce que vous faites bien et ce que vous faites mal. La question c'est de quel côté vous voulez amplifier.
L'audit gratuit, c'est 45 minutes. On regarde votre dette technique et votre growth engineering avant qu'un VC le fasse pour vous.
Réserver mon audit gratuit →Le mécanisme structurel qui rend vos agents IA dangereux en prod.
Pourquoi votre CFO va vous détester si vous construisez sur Computer Use sans calculer.
Le vrai signal faible 2025 : task paralysis et procrastination sophistiquée.