Dépendances et supply chain : gouverner ce que l’IA fait entrer dans votre logiciel

Un composant suggéré par un agent entre dans un projet en quelques secondes. Il en ressortira en plusieurs semaines, à condition que quelqu’un sache encore qu’il est là. Entre les deux, il s’exécute en production, le plus souvent avec les mêmes privilèges que l’application qu’il sert. La question qui compte n’est donc plus seulement « ce composant est-il sûr ? ». Elle est devenue : qui a décidé qu’il entrait, et sur quel critère ?

Dans un développement assisté par l’IA, cette décision a changé de main sans que personne ne l’ait formellement actée. L’ancre de cette série l’a établi : le risque a quitté le périmètre réseau pour s’installer dans la chaîne d’approvisionnement logicielle, le code généré, les dépendances, le pipeline de build. La première feuille a traité le code que l’IA écrit. Celle-ci traite ce que l’IA fait entrer : les composants tiers qu’elle mobilise, et l’assemblage qui les transforme en logiciel livré.

La thèse tient en une phrase : puisque la décision d’entrée d’un composant est devenue un flux machine à haute fréquence, elle ne se contrôle plus a posteriori, elle se gouverne par un régime d’admission que le système impose. Quatre temps pour y arriver : comprendre ce qui a changé dans la décision elle-même, voir la surface que l’on exécute réellement, poser les trois contrôles du régime d’admission, et faire du build le lieu où la provenance se prouve.

L’agent ne choisit pas vos composants comme un développeur

Avant l’assistance par IA, ajouter une dépendance était un acte ponctuel. Un développeur cherchait une bibliothèque, comparait deux ou trois candidates, regardait la date du dernier commit, parfois l’état des tickets ouverts, puis assumait son choix devant l’équipe. La décision était lente, imparfaite, mais délibérée : elle avait un auteur, un moment, et elle pouvait être discutée en revue.

Un agent ne procède pas ainsi. Il suggère un composant parce que ce composant est statistiquement plausible dans le contexte du code en cours, et il le fait des dizaines de fois par jour, au fil de la génération, sans comparaison, sans examen de la provenance, sans trace de l’alternative écartée. La décision d’entrée n’a plus d’auteur identifiable ni de moment dédié : elle est diluée dans le flux de production. L’ancre de la série a signalé le cas limite de cette mécanique, le composant suggéré qui n’existe pas encore et qu’un attaquant enregistre pour capter la suggestion attendue. Le cas courant est plus banal et plus massif : des composants légitimes, entrés sans que leur entrée ait été décidée.

Ce déplacement rend le contrôle a posteriori structurellement insuffisant. La revue de code, maillon indispensable pour relire ce que la machine a écrit, n’attrape pas ce qu’elle importe : une ligne d’import est syntaxiquement irréprochable, et rien dans le diff n’indique la santé du paquet qu’elle tire. Quant à l’audit périodique des dépendances, il photographie un état que le flux a déjà dépassé au moment où le rapport est lu. Un contrôle épisodique ne rattrape pas une décision continue.

L’enjeu n’est pas de retirer l’outil aux équipes : la vitesse gagnée est acquise, et personne ne reviendra à la sélection artisanale de chaque bibliothèque. L’enjeu est de reconnaître qu’une décision d’architecture, ce qui entre dans le socle du logiciel, a été déléguée par défaut à une machine. Une délégation par défaut n’est pas une politique.

Ce que vous exécutez n’est pas ce que vous avez choisi

Gouverner suppose de voir. Or la liste des composants qu’une équipe croit utiliser et la surface qu’elle exécute réellement sont deux objets différents. Chaque bibliothèque installée tire ses propres dépendances, qui en tirent d’autres : pour quelques dizaines de paquets choisis explicitement, un projet en exécute couramment plusieurs centaines. L’ancre a nommé cet angle mort ; la conséquence de gouvernance mérite d’être tirée jusqu’au bout : aucune décision sérieuse ne se prend sur une surface que personne ne sait décrire.

L’instrument qui rend cette surface visible existe et porte un nom : l’inventaire des composants logiciels, ou SBOM (software bill of materials, la nomenclature des composants d’un logiciel, versions et provenances comprises). Le référentiel international des éléments minimaux d’un SBOM, actualisé en 2026 et co-signé notamment par l’ANSSI, en fixe le socle : identification de chaque composant, sa version, son producteur, et les relations de dépendance entre eux. Rien d’exotique : un format normalisé, que les outils de build savent produire.

Le malentendu fréquent consiste à ranger le SBOM parmi les livrables de conformité, un document produit pour être archivé. C’est un contresens de pilotage. Un inventaire tenu à jour est d’abord un instrument de décision : le jour où une vulnérabilité majeure touche une bibliothèque répandue, la différence entre une organisation qui répond en deux heures à la question « sommes-nous exposés, où, dans quelles versions ? » et une organisation qui lance trois semaines d’investigation tient à l’existence de cet inventaire. La première décide, la seconde subit.

En contexte IA-augmenté, l’inventaire change aussi de nature. Un document rédigé serait périmé avant d’être relu ; l’inventaire doit être généré par la chaîne de build elle-même, à chaque construction, pour suivre le rythme du flux d’entrée. C’est la première pierre du régime d’admission : on ne peut admettre ou refuser que ce que l’on voit entrer.

Le régime d’admission : trois contrôles que le système impose

La deuxième feuille de cette série a posé le principe qui commande tout le reste : face à une production machine, le contrôle qui tient est celui que le système impose, pas celui qu’une consigne demande. Appliqué aux dépendances, ce principe prend la forme d’un régime d’admission : trois contrôles structurels qui s’exercent sur le flux sans exiger de quiconque, humain ou agent, une discipline volontaire.

Premier contrôle : d’où ça vient. L’organisation définit les sources autorisées, en pratique un registre interne ou un proxy qui filtre les dépôts publics, et le système refuse par défaut ce qui n’en provient pas. Un paquet inconnu du registre ne s’installe pas, quelle que soit l’insistance de la suggestion. Ce contrôle neutralise mécaniquement les composants illégitimes ou usurpés : l’agent peut suggérer n’importe quoi, seul ce qui a été admis peut entrer.

Deuxième contrôle : que rien ne change sans décision. Les versions sont verrouillées, par fichiers de verrouillage, empreintes d’intégrité et signatures vérifiées, si bien qu’une montée de version est un acte explicite, tracé et attribuable, jamais l’effet de bord d’une réinstallation. Ce contrôle transforme la dérive silencieuse des versions en une série de décisions visibles, qui peuvent être groupées, planifiées et relues.

Troisième contrôle : que l’état se vérifie à chaque build. L’analyse de composition logicielle, dont l’ancre a posé le principe, cesse d’être un audit périodique pour devenir une barrière du pipeline : chaque construction confronte l’arbre des dépendances aux bases de vulnérabilités connues, et bloque au-delà d’un seuil de gravité défini par la direction, pas par l’équipe au cas par cas. Le seuil est une politique ; son application est mécanique ; ses exceptions sont des décisions enregistrées, avec un propriétaire et une échéance.

La cohérence de ces trois contrôles fait leur efficacité. Chacun s’exerce au moment où le flux passe, pas après ; aucun ne repose sur la vigilance d’un individu ; et l’agent y est soumis au même titre que le développeur, ce qui est exactement le but recherché. C’est aussi ce qui les distingue d’un audit de fin de parcours : ils ne ralentissent pas la production, ils en bornent le terrain. Une équipe qui travaille à l’intérieur du régime d’admission conserve toute sa vitesse ; simplement, ce qu’elle produit est admissible par construction.

Le build, dernier point où la provenance se prouve

Reste le moment où tout converge : la construction qui transforme le code et ses composants en artefact livré. L’ancre a traité la sécurisation de cette chaîne, ses droits, ses secrets, le contrôle de ce qui s’y exécute. La question ici est différente et complémentaire : que peut-on prouver de ce qui en sort ?

Un artefact de build est opaque par nature. Une fois construit, rien dans le binaire ou l’archive ne dit de quel commit il provient, avec quelles dépendances il a été assemblé, ni par quelle chaîne. Cette opacité devient un problème de gouvernance le jour où il faut répondre, devant un client, un assureur ou un régulateur, à la question : que contient exactement ce qui a été livré ? Y répondre par reconstitution a posteriori est long et incertain. Y répondre par la preuve suppose d’avoir fait produire cette preuve au moment du build.

C’est l’objet des attestations de provenance : des métadonnées signées, générées par la chaîne de build, qui lient l’artefact à son commit d’origine, à son inventaire de composants et aux étapes qui l’ont produit. Le cadre SLSA (Supply-chain Levels for Software Artifacts) en fait le cœur d’un modèle de maturité progressif : on n’exige pas tout le premier jour, on gravit des niveaux, de la simple traçabilité à la preuve difficile à falsifier. Pour une direction, l’intérêt du modèle tient précisément à sa gradation : il transforme « sécuriser la supply chain » en un chemin jalonné plutôt qu’en un chantier total.

Ce chaînon ferme la boucle ouverte par le prototype. Un prototype produit avec l’IA tient en démonstration sans rien prouver de ce qu’il embarque ; une application métier en production doit pouvoir établir, à tout moment, ce qui la compose et d’où cela vient. La distance entre les deux est exactement celle que le régime d’admission et la provenance viennent combler.

Qui décide de ce qui entre dans votre build ?

La question mérite d’être posée telle quelle en comité. Si la réponse honnête est « l’agent, au fil de l’eau, et l’équipe quand elle y pense », alors le régime d’admission n’existe pas encore, et la surface qui s’exécute en production n’a pas de propriétaire. Ce constat n’a rien d’une faute : c’est l’état par défaut de la plupart des organisations qui ont adopté le développement assisté sans réviser leur gouvernance d’approvisionnement. Un état par défaut, en revanche, n’est pas une décision.

Reprendre cette décision ne demande pas d’arsenal : un inventaire généré à chaque build, des sources autorisées, des versions verrouillées, une barrière de composition dans le pipeline, une provenance attestée. Chaque élément existe en standard, s’outille sans développement spécifique et s’impose une fois pour toutes. Ce qui manque le plus souvent tient à l’acte de gouvernance initial : décider que ce qui entre dans le logiciel se décide, et confier au système, plutôt qu’à la vigilance de chacun, la charge de faire respecter ce choix.

Le périmètre de la série se referme ainsi. Le code généré se relit, le contrôle s’impose, et ce qui entre dans le build s’admet selon un régime dont la sécurisation d’une application métier développée avec l’IA a posé le cadre d’ensemble : gouverner la fabrique du logiciel avec le sérieux qu’on réservait autrefois au réseau.