Sécurité de l’IA open source : retour à la réalité sur la chaîne d’approvisionnement

Le modèle le moins cher de votre pile n’est peut-être pas la partie risquée. La partie risquée, c’est le charmant tas de packages, de poids, d’agents, de plugins et d’autorisations que vous avez invités en production parce que la démo a fonctionné et que tout le monde a applaudi. L’IA open source n’est pas la méchante de l’histoire. Le méchant, c’est l’enthousiasme sans inventaire, ce qui revient à adopter un dragon et à l’étiqueter chien. Les modèles et outils ouverts donnent aux bâtisseurs un vrai levier : portabilité, inspection, personnalisation et moins de dépendance à l’humeur tarifaire d’un seul fournisseur. Mais la leçon opérationnelle est directe. Si votre pile d’IA est ouverte, votre processus de sécurité doit aussi avoir les yeux ouverts, avec des vérifications de provenance, une surveillance des dépendances et une modélisation des menaces avant que la chose commence à appeler des API comme un stagiaire caféiné avec un accès root.

Le risque s’est déplacé dans

le système de build Recorded Future’s Emerging Enterprise Security Risks of AI indique que l’adoption de l’IA agentique s’accélère à mesure que les logiciels d’entreprise ajoutent des agents spécialisés capables d’exécuter des tâches complexes à la vitesse de la machine. Le même rapport avertit que l’autonomie et l’échelle des agents peuvent permettre à des erreurs, de mauvaises configurations ou des manipulations malveillantes de se propager rapidement dans des systèmes interconnectés. Il indique aussi que l’IA agentique peut aggraver les faiblesses existantes de la chaîne d’approvisionnement logicielle, parce que des composants open source vulnérables ou malveillants peuvent être déployés plus vite et à grande échelle. Traduction : le graphe de dépendances n’est pas devenu maudit. Il a reçu une trottinette. La réponse des bâtisseurs n’est pas d’interdire l’open source et de se réfugier dans un bunker de panique propriétaire. C’est de traiter les composants d’IA comme des dépendances de production, parce que ce sont des dépendances de production, simplement avec davantage de distributions de probabilité et moins de messages d’erreur utiles. Les équipes doivent savoir quels poids de modèle elles utilisent, d’où ils viennent, quelle licence s’applique, quels packages les enveloppent et quelles autorisations reçoit chaque agent. Si cela vous paraît ennuyeux, félicitations, vous venez de découvrir l’ingénierie de la sécurité.

Black Duck affirme que la gouvernance est entrée dans l’ère de l’IA Le rapport

OSSRA 2026 de Black Duck, publié en mars 2026, présente le problème comme une question de gouvernance logicielle à l’ère de l’IA. Le rapport indique que l’explosion du développement assisté par l’IA a modifié le paysage des risques open source et changé la base de conformité aux initiatives réglementaires, notamment le règlement européen sur la cyberrésilience et le règlement sur la résilience opérationnelle numérique. Black Duck précise aussi que son analyse OSSRA repose sur des constats anonymisés issus de bases de code commerciales auditées par son équipe Audit Services, ce qui en fait moins une note fondée sur des impressions qu’un miroir que personne n’avait demandé. Pour les bâtisseurs d’IA, cela signifie que la surveillance des dépendances ne peut pas s’arrêter à la couche applicative. Le code de service de modèles, les frameworks d’orchestration, les outils d’évaluation, les connecteurs de données, les notebooks et le code généré ont tous leur place dans l’inventaire. La vérité un peu gênante, c’est que le développement assisté par l’IA peut pousser les équipes à produire plus de code avant de produire plus de processus. C’est ainsi que l’on se retrouve avec un magnifique prototype tenu ensemble par des packages abandonnés, des poids mystérieux et un script shell nommé final_final_really_final.sh.

La provenance n’est pas de

la paperasse, c’est du contexte d’exécution La First Key Update de l’International AI Safety Report indique que de nouvelles techniques d’entraînement permettant aux systèmes d’IA d’utiliser davantage de puissance de calcul ont aidé ces systèmes à résoudre des problèmes plus complexes en mathématiques, en codage et dans des disciplines scientifiques. Le rapport indique aussi que ces améliorations de capacité ont des implications pour des risques tels que les cyberattaques, tout en créant de nouveaux défis de surveillance et de contrôlabilité. Autrement dit, les modèles deviennent meilleurs précisément dans les tâches que les développeurs utilisent pour construire des systèmes, ce qui est merveilleux jusqu’à ce que vos garde-fous soient un post-it disant sois normal. Le Global Center on AI Governance, dans une recherche publiée le 21 février 2025, avertit que des modèles open source très performants pourraient être détournés par des acteurs malveillants pour perpétuer des crimes, causer des dommages ou saper les processus démocratiques. Les bâtisseurs n’ont pas besoin de résoudre la politique mondiale avant de livrer un produit utile, mais ils ont besoin d’une discipline de base sur la provenance. Enregistrez la source du modèle, sa version, sa licence, son hash, ses notes de sécurité, sa lignée de fine-tuning lorsqu’elle est disponible, et le propriétaire du déploiement. Si vous ne pouvez pas dire d’où vient un modèle, vous n’avez pas de stratégie d’IA. Vous avez un haussement d’épaules très coûteux.

Le débat politique devient une réalité produit Mapping the Open-Source

AI Debate du R Street Institute, publié le 17 avril 2025, traite l’IA open source comme une question de cybersécurité et de politique publique plutôt que comme une simple guerre théologique entre ouvert et fermé. C’est aussi le bon cadre pour les bâtisseurs. La question pratique n’est pas de savoir si l’IA open source est sûre dans l’abstrait, parce qu’un logiciel abstrait n’a jamais bipé personne à trois heures du matin. La question est de savoir ce que votre système peut faire, à quoi il peut accéder et à quelle vitesse un mauvais composant ou une mauvaise instruction peut se propager. Modélisez donc les menaces du flux de travail, pas seulement la fiche du modèle. Demandez-vous ce qui se passe si un package est malveillant, si un agent est poussé par un prompt à effectuer une action dangereuse, si un artefact de modèle est remplacé, si une dépendance devient obsolète ou si les identifiants sont plus larges que ce que la tâche exige. Placez des points de contrôle humains là où les actions franchissent des frontières de confiance, surtout pour les agents qui touchent aux données, à l’infrastructure, aux paiements, aux communications client ou aux systèmes internes. L’IA open source reste l’un des meilleurs moyens de construire des systèmes utiles sans attendre qu’une feuille de route fournisseur descende des nuages, mais la réduction ne fonctionne que si vous ne la financez pas avec de la réponse à incident. Pour les lecteurs qui construisent avec des modèles ouverts, la prochaine étape est pratique : inventorier la pile, surveiller les dépendances en continu, vérifier la provenance des modèles et faire une modélisation des menaces avant de donner à l’agent les clés du royaume. L’open source vous donne le bac de pièces détachées. La sécurité décide si vous construisez une voiture de course ou un canon à confettis pointé vers la prod.