Code généré par IA en due diligence : red flag ou maturité ?

La scène se produit désormais dans la plupart des due diligences tech. L'audit de la codebase révèle que 40 % du code provient d'outils de génération, Cursor, Copilot ou équivalent. Autour de la table, deux lectures s'affrontent. Pour l'un, c'est de la dette masquée produite par une équipe qui ne maîtrise plus son propre produit. Pour l'autre, c'est le signe d'une équipe qui a pris le virage avant les concurrents.

Le sujet du code généré par IA en due diligence mérite une réponse tranchée, alors la voici : ce pourcentage, seul, ne dit rien. Ce qui se joue dans l'audit se trouve un cran au-dessus, dans le système de production qui entoure ce code. Et à ce niveau-là, en 2026, le red flag a changé de camp.

Pourquoi la question "combien" est mal posée  

Le pourcentage de code généré mesure une origine, jamais une qualité. Deux entreprises affichant le même 40 % peuvent être aux antipodes l'une de l'autre. Dans la première, chaque contribution passe une revue exigeante, la couverture de tests a augmenté avec l'adoption des outils, et n'importe quel développeur senior peut expliquer n'importe quelle partie du système. Dans la seconde, le code s'accumule plus vite que la capacité de l'équipe à le comprendre, et la vélocité affichée dissimule un produit que plus personne ne sait faire évoluer sans assistance.

Même chiffre, deux valorisations opposées. Un auditeur qui s'arrête au pourcentage confond l'outil et l'usage, à peu près comme on jugerait une usine au nombre de ses machines sans regarder ce qui en sort.

Ce que l'auditeur regarde vraiment lors de l'audit en due diligence ia ?

Le regard s'est déplacé de la codebase vers le système de production. Le code lui-même devient presque secondaire : généré ou écrit à la main, il se lit, se teste et se mesure de la même façon. Ce qui distingue les équipes matures des autres tient dans l'encadrement, et les signaux d'alerte y sont faciles à identifier :

• Personne ne sait quelle part du code est générée. L'absence de mesure trahit l'absence de pilotage, et ce constat vaut pour toute la suite.
• Le code généré emprunte un chemin différent du reste : revue allégée, tests optionnels, mise en production accélérée parce que "l'outil est fiable".
• L'équipe ne peut pas expliquer des pans entiers de son produit sans réinterroger l'outil qui les a écrits.
• La productivité a augmenté mais la couverture de tests a baissé. Le déséquilibre entre les deux courbes annonce la dette de demain.
• Aucune trace de réflexion sur la dépendance : ni suivi des coûts, ni scénario de substitution des outils.

Ces signaux rejoignent ce que nous avons détaillé sur les risques de dépendance aux outils IA en due diligence. La question de la responsabilité complète le tableau : quand un incident touchera du code généré, quelqu'un devra pouvoir expliquer ce qui a été accepté et pourquoi. C'est d'ailleurs l'une des questions qu'un CEO devrait poser à sa propre équipe bien avant qu'un auditeur ne la pose à sa place.

Le red flag a changé de camp

Voici la partie qui fâche, ou qui rassure, selon le côté de la table où l'on se trouve. Une codebase récente qui ne contient aucun code généré est devenue un signal d'alerte à part entière.

Le raisonnement tient en peu de lignes. Les outils de génération offrent un gain de productivité documenté et massif. Une équipe qui n'en a rien fait en 2026 raconte quelque chose : une culture fermée au changement, un manque de veille, ou un déni sur l'évolution du métier de développeur, que nous avons décrite comme un passage de l'artisanal à l'industriel. Pour un investisseur, cela se traduit en projections très concrètes : une structure de coûts de développement qui décrochera de celle des concurrents, et une équipe dont la transformation reste entièrement à financer après l'opération.

L'inversion est là. Il y a trois ans, le code généré devait se justifier face à l'auditeur. Aujourd'hui, son absence aussi.

Questions à préparer avant une levée

Côté fondateur, la conséquence pratique tient en un principe : documenter avant d'être questionné. Mesurer la part de code générée, formaliser le processus de revue qui s'y applique, suivre l'évolution conjointe de la productivité et de la qualité, et pouvoir raconter les choix d'outillage comme des décisions plutôt que des adoptions subies. Un dossier de due diligence qui anticipe ces questions transforme un point d'inquiétude en preuve de maturité. La grille de lecture complète qu'appliquent les investisseurs dépasse le seul code généré, et fera l'objet d'un article dédié.

Reste une réalité que les deux côtés de la table devraient regarder en face : la plupart des grilles d'audit ont été conçues pour un monde où les humains écrivaient tout le code. Elles évaluent des pratiques de 2020 avec des critères de 2020. Les fonds qui mettront à jour leur lecture verront des signaux de maturité là où leurs concurrents voient encore des défauts, et inversement.

FAQ

Le code généré par IA est-il un problème en due diligence ?

Le code généré en lui-même ne constitue pas un red flag. Ce qui alarme un auditeur, c'est l'absence d'encadrement autour : pas de mesure de la part générée, pas de processus de revue spécifique, pas de suivi de la qualité, et une équipe incapable d'expliquer son propre produit. Un fort pourcentage bien encadré vaut mieux qu'un faible pourcentage subi.

Quelle part de code généré par intelligence artificielle est acceptable pour un investisseur ?

Il n'existe pas de seuil : 20, 40 ou 60 % ne signifient rien isolément. Ce qui est intéressant à évaluer, c'est le système de production, la traçabilité, la discipline de revue, l'évolution de la couverture de tests et la capacité de l'équipe à maintenir le code sans assistance. Le pourcentage sert tout au plus de point d'entrée à ces questions.

Comment les investisseurs auditent-ils une codebase en 2026 ?

L'audit s'est déplacé du code vers le système qui le produit : outillage et part de génération, processus de revue et de test, dépendance aux fournisseurs d'IA, coûts associés et courbe de qualité dans le temps. L'entretien avec l'équipe compte autant que l'analyse statique : sa capacité à expliquer ses choix révèle sa maîtrise réelle du produit.

‍