La démo fonctionne. Puis le développeur initial part, un grand compte demande des preuves de sécurité ou un investisseur veut évaluer l’actif. Une autre équipe doit alors assumer la responsabilité du produit, pas seulement parcourir son dépôt. L’origine IA du code n’est pas, à elle seule, un verdict : ce sont les preuves disponibles et la capacité réelle de reprise qui tranchent.
La réponse en 60 secondes
Cherchez six signaux :
- une architecture et des dépendances compréhensibles ;
- un build et une mise en production reproductibles ;
- des accès, secrets et données sous contrôle ;
- des parcours critiques testés au-delà du cas nominal ;
- une restauration et une exploitation démontrables ;
- des responsables humains nommés et une dette connue.
Ils conduisent à trois décisions : reprendre et exploiter, reprendre avec un renforcement délimité, ou suspendre la reprise et engager un sauvetage.
Dans cet article
- Le vrai test n’est pas « qui a écrit le code ? »
- Trois moments où la reprise devient un problème business
- Les six dossiers de preuves
- Le test de reprise en dix questions
- Décider : reprendre, renforcer ou suspendre
- Ce qu’un audit professionnel doit produire
- Conclusion : une reprise se démontre
Le vrai test n’est pas « qui a écrit le code ? »
Un logiciel peut avoir été largement assisté par l’IA et rester exploitable. Il peut aussi fonctionner en démonstration tout en dépendant d’un compte personnel, d’une procédure mémorisée ou d’un composant abandonné. Les travaux disponibles décrivent des résultats variables selon la tâche, les outils et le contexte ; ils ne permettent pas de classer tout code IA comme supérieur ou inférieur (NCSC, synthèse de Geruslu et al.).
La vraie question est celle de la propriété vérifiable : une équipe humaine identifiée peut-elle expliquer les flux, produire une version, la déployer, observer un incident et décider d’un correctif ? Plus la conséquence d’une erreur est élevée, plus la revue doit être approfondie. Nommer un responsable ne prouve rien à lui seul, mais aucune décision sensible ne devrait rester sans responsable.
Trois moments où la reprise devient un problème business
Le constructeur ou l’agence quitte le projet
La livraison du dépôt ne transfère ni les comptes cloud, ni le savoir de déploiement. Le risque apparaît lorsque la nouvelle équipe ne peut pas livrer ou traiter un incident sans rappeler la personne sortante.
Un client entreprise demande des preuves
Le client veut savoir qui accède aux données, comment une version est validée et ce qui suit un échec. Une politique écrite ne remplace pas une démonstration. Les contrôles restent proportionnés aux conséquences ; les accès et autorisations des agents IA peuvent être examinés séparément.
Un investisseur ou un acquéreur ouvre la due diligence technique
Une démo ne renseigne pas sur la continuité de service ou les dépendances critiques. Il faut identifier ce qui est transférable, ce qui doit être renforcé et ce qui reste inconnu avant la décision.
Les six dossiers de preuves qu’une équipe repreneuse doit obtenir
Une preuve peut être un artefact actuel ou une action exécutée par l’équipe repreneuse. La documentation indique le chemin ; la démonstration confirme qu’il reste praticable.
Carte du système et des dépendances
Question acheteur : que faut-il comprendre et posséder pour faire fonctionner le parcours critique ? Preuves : schéma actuel, flux de requêtes et de données, inventaire des services et fournisseurs, versions, comptes et responsables. Absence révélatrice : dépendance oubliée, point unique de défaillance ou réversibilité non préparée. Le guide ANSSI-Mission French Tech recommande précisément d’anticiper les dépendances critiques et leur réversibilité (guide officiel).
Build et mise en production reproductibles
Question acheteur : la nouvelle équipe peut-elle produire et publier une version depuis la source ? Preuves : environnement déclaré, commande de build, pipeline, artefact relié à une révision, déploiement et retour arrière exécutés. Absence révélatrice : étapes manuelles cachées ou dépendance à la mémoire du constructeur. La provenance relie un artefact à sa source et à ses étapes de production, sans prouver sa qualité (SLSA).
Sécurité, identités, données et secrets
Question acheteur : qui contrôle réellement les accès et les actifs sensibles ? Preuves : inventaire des identités, propriétaires des comptes, droits effectifs, rotation ou révocation démontrée, emplacement des secrets sans exposer leurs valeurs, dépendances et pipeline inspectés. Absence révélatrice : compte personnel irremplaçable, secret partagé ou privilège sans propriétaire. OWASP traite ces éléments comme une surface connectée, et non comme un simple scan (guide OWASP).
Tests des parcours critiques et preuves d’échec
Question acheteur : le comportement important tient-il aussi face aux entrées invalides et aux abus plausibles ? Preuves : exigences reliées aux tests, cas normaux, limites, erreurs et abus, résultats, défauts connus et revue compétente. Absence révélatrice : suite verte qui ne teste que ce que le même agent a prévu. Des tests réussis restent une entrée utile, pas une assurance indépendante.
Exploitation, restauration et support
Question acheteur : l’équipe sait-elle détecter, décider, communiquer et restaurer ? Preuves : journaux, métriques ou traces reliés au parcours client, alertes attribuées, procédure d’exploitation, exercice de rollback ou de restauration observé et historique d’incidents. Absence révélatrice : sauvegarde jamais restaurée ou alerte sans destinataire. Un plan de reprise gagne en valeur lorsqu’il est exercé et documenté (Google Cloud).
Responsabilité humaine, décisions et dette connue
Question acheteur : qui décide après le transfert, et sur quelles connaissances ? Preuves : responsables nommés pour produit, code, données, exploitation et support ; journal de décisions ; dette priorisée ; sessions de transfert et exercice pratique réalisé par l’équipe entrante. Absence révélatrice : documentation orpheline ou responsabilité implicite. La dette technique doit être reliée à une conséquence, pas utilisée comme justification automatique d’une réécriture.
Le test de reprise en dix questions
Cette liste est une aide à la décision, pas un score. Chaque réponse doit pointer vers un artefact actuel, une action démontrée ou un responsable nommé.
- Quel schéma relie le parcours client critique aux services, données et fournisseurs qui le rendent possible ?
- Quel inventaire indique la version, le propriétaire, l’état de maintenance et la contrainte de sortie de chaque dépendance critique ?
- Quelle révision de source a produit l’artefact actuellement déployé, et par quelles étapes vérifiables ?
- Un membre de l’équipe repreneuse peut-il exécuter aujourd’hui le build, le déploiement et le retour arrière prévu ?
- Quel registre relie comptes, identités, rôles, secrets et droits de révocation à des propriétaires de l’organisation ?
- Quels résultats couvrent le parcours critique dans les cas nominal, limite, invalide et abusif ?
- Quelle alerte issue d’un signal exploitable permet à un responsable nommé de diagnostiquer une panne visible par l’utilisateur ?
- Quelle restauration ou quel rollback du périmètre critique a été exercé, observé et consigné ?
- Qui décide, répond, communique et remet le service en état lors d’un incident ?
- Quelle dette connue, quel journal de décisions et quel transfert pratique la nouvelle équipe a-t-elle effectivement examinés ?
Décider : reprendre, renforcer ou suspendre
Le résultat dépend du contexte et des conséquences, pas d’un seuil universel.
| Situation observée | Décision | Prochaine action |
|---|---|---|
| Les parcours critiques sont compris ; build, déploiement, observation et restauration sont démontrés ; les responsabilités sont attribuées. | Reprendre et exploiter | Transférer progressivement les accès, puis surveiller les premiers changements. |
| Le cœur est opérable, mais quelques lacunes circonscrites affectent la sécurité, les tests, la réversibilité ou l’exploitation. | Reprendre avec un renforcement délimité | Définir les risques, propriétaires, critères de sortie et ordre des correctifs. |
| L’équipe ne peut pas reconstruire, déployer ou restaurer le périmètre critique, ou des inconnues bloquent la responsabilité. | Suspendre la reprise et engager un sauvetage | Stabiliser l’accès et le service, reconstituer les preuves, puis réévaluer la reprise. |
Ce qu’un audit professionnel doit produire
Un audit utile ne livre pas seulement une liste de défauts. Il produit une carte orientée décision de l’architecture, des dépendances et des responsables ; il indique quels builds, déploiements, signaux et exercices opérationnels ont été observés. Pour structurer le dialogue acheteur-fournisseur, le NIST SSDF offre un vocabulaire de pratiques, sans constituer une certification de reprise.
Le rapport priorise chaque risque par sa conséquence business : parcours interrompu, données exposées, publication impossible ou dépendance à une personne. Il propose une feuille de route délimitée, avec responsables et critères de sortie. Il nomme les inconnues et les sujets exigeant un spécialiste, par exemple juridique ou test d’intrusion. Il ne garantit ni sécurité, ni conformité, ni acceptation, et n’impose pas de délai standard.
Conclusion : une reprise se démontre
Posséder les fichiers n’est pas encore posséder le produit. La reprise devient crédible lorsqu’une autre équipe peut comprendre, changer, déployer, observer et restaurer le service sous une responsabilité humaine explicite. Certains produits construits avec l’IA passent ce test ; d’autres demandent un renforcement circonscrit. Tous n’ont pas besoin d’être réécrits.
Préparez la reprise avant qu’elle ne devienne une urgence
Pour une conversation de cadrage de 30 minutes, apportez un accès en lecture au dépôt ou un export, les notes d’architecture et de déploiement disponibles même incomplètes, un parcours client critique, les incidents connus ou irritants de support, ainsi que la date et le contexte du transfert ou de la revue.
Cet échange permet d’établir un premier chemin de décision : reprendre, délimiter un renforcement ou préparer un sauvetage. Ce n’est ni un audit gratuit, ni une promesse de certification ou d’acceptation.
Questions fréquentes
Non. Les résultats publiés sont mixtes et dépendent de la tâche et de la validation (étude de Molison et al.). Jugez le produit sur son comportement critique, sa sécurité, son opérabilité et ses responsables.
Non. Ils peuvent faire remonter des points à examiner, mais un constat significatif doit être replacé dans l’architecture, vérifié et relié à une conséquence. Un scan propre ne démontre ni l’absence de vulnérabilité ni la capacité d’exploitation. La revue manuelle reste nécessaire pour les comportements critiques.
Lorsque l’architecture empêche durablement le parcours cible, que les dépendances ne peuvent plus être maintenues, ou que restaurer une capacité d’exploitation coûterait plus que reconstruire le périmètre utile. Cette décision exige des scénarios comparés ; l’étiquette « code IA » ne suffit pas.
Sa disponibilité facilite les explications et des exercices progressifs, mais elle ne doit pas devenir une dépendance permanente. Un élément de preuve important est que l’équipe entrante exécute elle-même les gestes critiques, avec un soutien sortant borné lorsqu’il est disponible.
Non. Il peut révéler des besoins d’escalade, mais son périmètre doit être explicite. Un test d’intrusion, une analyse de conformité, un examen contractuel ou une validation de propriété intellectuelle demandent leurs propres compétences et preuves. Pour une transaction, voir le service due diligence technique d’IZZY.
Sources et méthode
Ce cadre synthétise des guides officiels, des spécifications techniques et des travaux de recherche ouverts et contrôlés le 22 juillet 2026. Ces sources éclairent les preuves à demander ; elles ne constituent ni une norme universelle de reprise, ni une mesure de tous les produits construits avec l’IA. Les recherches citées restent bornées à leurs méthodes et échantillons.
- NCSC - The “vibe coding spectrum” approach to AI-assisted software development
- ANSSI et Mission French Tech - Guide de cybersécurité à l’usage des start-up du numérique
- OWASP - Secure Coding with AI Cheat Sheet
- NIST - Secure Software Development Framework, SP 800-218
- Google SRE - The Evolving SRE Engagement Model
- Google SRE - Reliable Product Launches at Scale
- Google Cloud - Perform testing for recovery from failures
- SLSA - Provenance, specification v1.2
- NIST - Incident Response Recommendations, SP 800-61 Rev. 3
- OpenTelemetry - Observability primer
- Molison et al. - Is LLM-Generated Code More Maintainable & Reliable than Human-Written Code?
- Geruslu, Aliyeva et Tüzün - Factors Influencing the Quality of AI-Generated Code