Quelle partie de votre code a été écrite par une IA ? La question n'est plus d'ordre technique.
Des assistants de code dans chaque équipe, des dizaines de branches et un dépôt dont personne ne connaît l'intégralité. Pour la direction technique, c'est un problème de contrôle. Pour le service juridique, c'est une question de paternité et de licences. Pour l'auditeur, c'est une question de preuves.
Le référentiel que personne ne connaît dans son intégralité
Un dépôt V-PROOF analysé en septembre comptait 163 branches et 446 commits provenant de quatre auteurs. Ce n'est pas un cas extrême. C'est tout à fait normal pour n'importe quelle équipe qui développe depuis un an.
À cette échelle, savoir ce qui existe, qui l’a modifié et pourquoi dépend de la mémoire de deux ou trois personnes. Et si l’on ajoute à cela le fait qu’une partie du code est proposée par un assistant d’IA, la question de savoir qui en est l’auteur cesse d’être purement théorique.
Avant la branche, pas après
Verifiable AI Code Governance analyse chaque modification avant la demande de fusion, en la comparant aux règles de développement définies par l’organisation elle-même, et non à des règles génériques. Elle examine quatre éléments lors de chaque analyse :
Identifiants dans le code.
Éléments clés et variables sensibles détectés à chaque modification.
Licences et vulnérabilités.
Licences autorisées ou interdites et vulnérabilités connues rendues publiques.
Attribution mesurée.
Quelle part des nouvelles lignes provient de commits co-rédigés par l'IA ?
Couverture par zone.
Fichiers de test par rapport aux fichiers de code dans chaque partie du projet.
Lorsqu’une modification enfreint une règle ou révèle un secret, elle est signalée et consignée comme preuve. Les contrôles assurent une surveillance ; ils n’entravent pas le travail de l’équipe. Chaque modification est répertoriée comme « mise en œuvre », « partiellement mise en œuvre » ou « non mise en œuvre », avec les chiffres qui le justifient, dans le même registre de gouvernance que le reste de l’IA.
La paternité de l'œuvre, mesurée
Le numéro d'identification (IA) déclaré est celui qui suscite le plus de discussions au sein de la direction. Il constitue le point de départ pour déterminer qui est l'auteur d'un logiciel et quelles licences s'y rattachent.
Avec une mise en garde qu’il convient de souligner : cet outil mesure ce qui est déclaré dans les commits. Une utilisation de l’IA qui n’est pas mentionnée dans le commit n’apparaît pas. C’est pourquoi la politique de déclaration de la co-auteurie est tout aussi importante que l’outil lui-même.
Du « commit » à la preuve
Un commit peut être verrouillé avec son glossaire et son historique : quel code était présent, ce qu’il faisait et qui l’a modifié, le tout figé à un instant précis et attesté par une preuve cryptographique. Il est vérifié sur le portail public et exporté à l’intention d’un auditeur ou d’un client.
Pour ceux qui commercialisent des logiciels en Europe, cela correspond à ce qu’exigera la loi sur la cyber-résilience : savoir de quels composants se compose un produit et être en mesure de le prouver.
Ce qu'il ne fait pas
La détection des secrets et des vulnérabilités ne relève pas d'un test d'intrusion. Les contrôles consistent en des auto-évaluations vérifiées par une personne en charge de cette tâche. Quant à l'analyse fonctionnelle, elle est générée par un modèle choisi par l'organisation, via son propre compte ; seuls les résumés et les messages de commit sont transmis, jamais le code.
Si vous souhaitez découvrir le fonctionnement de la mémoire technique du projet, nous vous l'expliquons dans l'article « Votre code a déjà une histoire ».
Chaque commit est attribué. Chaque déploiement est traçable.
Quatre-vingt-dix secondes. Du commit à la preuve.
Enregistrement sur le portail V-PROOF : audit du référentiel, rapport humain/IA et validation sécurisée.
Voir la démo