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.
"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.
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, 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 :
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 ?
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 :
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.
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.
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 :
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.
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.
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.
L'audit gratuit, c'est 45 minutes. On regarde ta dette technique et ton growth engineering avant qu'un VC le fasse pour toi.
Réserver mon audit gratuit →Le mécanisme structurel qui rend tes agents IA dangereux en prod.
Pourquoi ton CFO va te détester si tu construis sur Computer Use sans calculer.
Le vrai signal faible 2025 : task paralysis et procrastination sophistiquée.