Votre code a déjà une histoire. Strategic Provenance la rend tangible.
Votre code a déjà une histoire. Strategic Provenance la rend tangible.
Ce qu'un DSI devrait être en mesure de démontrer concernant son référentiel en 2026, et comment V-PROOF y parvient.
Depuis le 11 septembre 2026, la loi sur la cyber-résilience (Cyber Resilience Act) oblige déjà les fabricants de produits comportant des éléments numériques à signaler les vulnérabilités activement exploitées et les incidents graves. Il s'agit de la première obligation directe imposée aux fabricants par un règlement qui s'appliquera dans son intégralité à compter du 11 décembre 2027. Parallèlement, une part croissante du nouveau code est rédigée à l’aide d’assistants d’IA, et n’est souvent pas déclarée.
La question posée par l'auditeur a changé. Elle n'est plus : « Avez-vous une politique de développement sécurisé ? ».
La plupart des organisations ne sont pas en mesure d'y répondre. Non pas par manque de données : la base de données contient toutes les informations nécessaires. Mais parce qu'il leur manque une couche permettant de transformer cet historique en élément de preuve.
Dans le code, la distance est la même.
Trois angles morts qui n'apparaissent sur aucun tableau de bord
Un concentré de savoir-faire
Il existe des domaines du système que seule une personne comprend. Personne ne l'a décidé ainsi, c'est simplement ainsi. Le jour où cette personne s'en va, le risque cesse d'être théorique.
IA non déclarée
Le commit indique « fix ». Personne ne sait si ces 600 lignes ont été écrites par un développeur ou par un assistant. Pour votre auditeur, votre assureur et votre client, cette distinction a son importance.
Des changements que personne n'explique
Entre deux versions, il y a des centaines de modifications. La direction, le client et l'auditeur ont besoin de savoir ce qui a changé sur le plan commercial, et non pas de connaître les différences.
Qu'est-ce que la « Strategic Provenance » ?
Strategic Provenance est le module de V-PROOF qui analyse le référentiel et le transforme en six vues de gouvernance. Chacune répond à une question précise et chaque résultat peut être certifié comme preuve.
Qui peut bien comprendre ça ?
Domaines du système, commits lus, auteurs et « bus factor » par domaine (nombre de personnes qui devraient partir pour que personne ne comprenne plus cette partie du système). Lorsqu’un domaine dépend d’une seule personne, ou lorsqu’un seul auteur y a apporté des modifications au cours des derniers mois, la plateforme déclenche une alerte.
Et cela ne se limite pas à l'écran : ces données sont directement enregistrées dans le registre des risques avec un identifiant traçable. Le risque de concentration passe ainsi du stade de l'intuition à celui du contrôle.
Les faits et les opinions, séparément
C'est le modèle qui fait l'objet du plus grand nombre de questions et qui exige le plus de précautions. V-PROOF fait la distinction entre deux notions que la quasi-totalité du marché confond :
- IA déclarée. Lignes ajoutées par des commits dont le message mentionne un coauteur de l'IA. Il s'agit d'un fait avéré : cela figure dans le commit lui-même.
- IA estimée. Ce que le modèle linguistique considère comme ayant probablement été rédigé par une IA. Il s'agit d'une estimation, qui est affichée séparément, avec son niveau de confiance.
Si votre équipe déclare 1 % et que l'estimation atteint 30 %, la différence ne prouve pas en soi qu'il y ait eu dissimulation : l'estimation n'est qu'une opinion du modèle. Mais elle indique où chercher, probablement au niveau de la culture de déclaration. La vue présente une ventilation par mois et par auteur, exclut les fichiers verrouillés, générés, fournis par des fournisseurs, binaires et contenant des secrets, et sépare les lignes générées par les bots.
Un auditeur peut contester une estimation. Il ne peut pas contester ce qui figure dans le commit. C'est pourquoi nous ne les fusionnons jamais.
Le système, schématisé
Modules du référentiel et leurs dépendances, représentés à partir du glossaire généré par l'analyse. Affichage par domaines ou par modules d'un domaine, mise en évidence des composants et exportation au format SVG, PNG ou Mermaid pour la documentation technique.
Et cela indique honnêtement de quoi il s'agit : ce que le modèle a lu, et non les importations du code. La transparence concernant la méthode constitue également une preuve.
Le changement, dans le langage des affaires
Vous sélectionnez deux points numérisés dans la base de données et V-PROOF vous renvoie :
- Liste des éléments ajoutés, modifiés, supprimés et inchangés.
- Quels changements fonctionnels ont été apportés, formulés en langage d'affaires.
- Notes de mise à jour en espagnol, en anglais et en catalan, sous deux formes : technique et destinée aux clients.
Ce qui ne représentait auparavant qu’un après-midi de travail pour un chef de produit est désormais un document prêt à être présenté au comité, au client et à figurer dans le dossier technique.
Les vérifications du code, à chaque lecture
Chaque analyse terminée déclenche automatiquement les contrôles de code définis dans Govern, le module de gouvernance de V-PROOF où sont enregistrés les contrôles et le registre des risques :
- Secrets : identifiants présents dans le référentiel, détectés et masqués par le scan lui-même.
- Statuts : licences autorisées, sous surveillance, sans licence enregistrée ou non autorisées, et vulnérabilités connues faisant l'objet d'avis publics.
- IA déclarée : pourcentage de lignes récentes issues de commits mentionnant la co-rédaction par l'IA.
- Tests par zone : fichiers de test par rapport aux fichiers sources, zone par zone.
Mis en œuvrePartiellementNon mis en œuvre
Chaque exécution enregistre des données probantes et une auto-évaluation du contrôle dans Govern. Le contrôle n'est plus une case que l'on coche une fois par an, mais devient un suivi continu.
Des preuves qu'il ne faut pas prendre pour argent comptant
Les résultats sont exportés vers un document Word (.docx) destiné au dossier et certifiés par V-Seal®: empreinte SHA-256, enregistrement sur la blockchain (L1/L2) et vérification publique par des tiers. L'auditeur n'est pas obligé de nous croire. Il peut le vérifier par lui-même.
La confidentialité dès la conception : votre code ne sort pas
La première objection de tout directeur technique est légitime : « Est-ce que vous envoyez mon code à un modèle ? ».
Seuls les résumés du glossaire et les messages de commit sont transmis au modèle. Jamais de code. Jamais d'e-mails.
Les données confidentielles sont masquées lors de l'analyse, avant que quoi que ce soit ne quitte votre environnement. Le modèle utilisé et les données qui lui sont transmises s'affichent à l'écran à chaque opération faisant appel à l'IA, car un principe de confidentialité qui n'est pas visible n'est pas un principe, mais une simple promesse.
Le point de vue de l'auditeur : six questions
Si nous évaluions une plateforme de gouvernance du code avec un regard d'analyste, voici les questions que nous poserions. Et voici nos réponses.
| Question de l'auditeur | Réponse de V-PROOF |
|---|---|
| Faites-vous la distinction entre les faits vérifiables et les estimations ? | Oui. L'IA déclarée et l'IA estimée sont toujours présentées séparément, avec un niveau de confiance indiqué. |
| Ces constatations se transforment-elles en risques maîtrisés ? | Oui. Les alertes de connaissance sont enregistrées dans le registre des risques avec leur propre identifiant. |
| Les contrôles font-ils l'objet d'une évaluation continue ? | Oui. Pour chaque scan effectué, avec une attestation écrite sur Govern. |
| Ces éléments sont-ils vérifiables par un tiers ? | Oui. Certifié par V-Seal avec hash et ancré dans la blockchain, vérifiable publiquement. |
| La propriété intellectuelle du code est-elle protégée ? | Oui. Le code n'est jamais envoyé au modèle ; les secrets sont masqués. |
| Est-ce utile pour les entreprises, et pas seulement pour l'ingénierie ? | Oui. Des notes de mise à jour en trois langues et deux formats, ainsi qu'un résumé des fonctionnalités de chaque modification. |
Et ce qu’il ne fait pas, pour être clair. L’estimation de l’IA est un avis du modèle, pas une preuve ; c’est pourquoi elle est présentée séparément. La carte d’architecture reflète ce que le modèle a lu, et non une analyse statique du code. Et une mention de co-auteur IA dans un commit est un fait documentaire : elle atteste que l’équipe l’a déclarée, et non que cette déclaration soit exhaustive. Le fait de le mentionner constitue également une preuve.
Quels sont les changements pour chaque rôle ?
DSI
Pour la première fois, un aperçu des risques liés aux logiciels que vous pouvez présenter au conseil d'administration : concentration des connaissances, dépendances, utilisation de l'IA et couverture des tests, avec des données probantes étayant chaque chiffre.
Direction technique et ingénierie
Identifier les domaines présentant un « bus factor » égal à 1 avant qu'il ne soit trop tard, et documenter l'architecture sans y consacrer un sprint.
Développeurs
Moins de rapports manuels. Les notes de version, la carte d'architecture et les contrôles proviennent directement du référentiel. Et l'utilisation de l'IA n'est plus une simple hypothèse, mais une norme au sein de l'équipe.
Conformité, risques et délégué à la protection des données (DPO)
Des preuves techniques qui ne reposent ni sur des entretiens ni sur des feuilles de calcul, et qui s'inscrivent dans les cadres déjà utilisés pour les audits.
Cadre réglementaire
Le référentiel sait déjà tout. Il peut désormais le prouver.
Pendant des années, le code a été l'actif le plus précieux et le moins bien géré des entreprises technologiques. Nous conservions tout et ne pouvions rien tester.
Strategic Provenance change la donne. Qui comprend chaque composante du système, quelle part a été rédigée par l'IA, quels changements ont été apportés à chaque version et quels contrôles sont respectés : tout cela est mesuré à chaque analyse, certifié et vérifiable par n'importe qui.
Le code est saisi.
L'origine est vérifiée.
