Quand les agents numériques deviennent collègues : piloter sécurité et conformité à l'âge des modèles ouverts

Les agents numériques ne sont plus un simple sujet de veille. Ils commencent à agir comme de véritables collègues : ils lisent, résument, codent, interrogent des outils, déclenchent des workflows et prennent parfois des décisions opérationnelles dans un cadre défini. Pour un responsable projet, un lead technique ou une direction IT, le sujet n’est donc plus seulement l’adoption de l’IA, mais la manière de l’intégrer sans fragiliser la sécurité, la conformité et la gouvernance existante.

Cette évolution arrive à un moment charnière. Depuis le 2 août 2025, les obligations du règlement européen sur l’IA applicables aux modèles à usage général sont entrées en application, avec des attentes explicites sur la transparence, le droit d’auteur et la documentation technique. En parallèle, les agents autonomes deviennent un objet de normalisation, de politique publique et d’outillage concret. Autrement dit : l’âge des modèles ouverts impose de penser ensemble performance, responsabilité et contrôle.

Des assistants aux collègues numériques : un changement de niveau de risque

Tant qu’un modèle se contente de générer un brouillon de texte ou de proposer quelques lignes de code, l’exposition reste relativement contenue. Dès qu’un agent peut enchaîner des actions, appeler des API, manipuler des données métiers, écrire dans un dépôt ou interagir avec un SI, il change de statut. Il devient un acteur opérationnel, avec un périmètre d’action, des permissions et un potentiel d’impact comparable à celui d’un collaborateur outillé.

C’est précisément ce glissement qui rend la sécurité des agents numériques centrale. Le NIST a publié en 2026 une analyse des réponses à son appel à commentaires sur la sécurité des agents d’IA, signe clair que le sujet n’est plus expérimental. Quand une agence de normalisation s’en saisit, cela indique que les risques observés sont suffisamment structurants pour nécessiter des référentiels, des pratiques partagées et un vocabulaire commun.

Pour les entreprises, la conséquence est simple : piloter des agents numériques ne consiste pas à “déployer un chatbot plus intelligent”. Il faut raisonner en termes d’identité, de droits, de supervision, de journalisation, de segmentation, de traçabilité et de responsabilité. En pratique, cela rapproche fortement la gouvernance de l’IA de celle des comptes à privilèges, des intégrations sensibles et des chaînes logicielles critiques.

L’AI Act et les modèles ouverts : ce qui change concrètement

Le cadre européen a franchi une étape décisive avec l’entrée en application, le 2 août 2025, des obligations visant les modèles d’IA à usage général. La Commission européenne a précisé que les fournisseurs de GPAI doivent notamment divulguer certaines informations, respecter le droit d’auteur et fournir une documentation technique. Pour les modèles présentant un risque systémique, des exigences supplémentaires s’ajoutent, avec un niveau d’attente plus élevé sur la maîtrise des risques.

L’AI Act retient en outre un critère indicatif pour caractériser un GPAI : un calcul d’entraînement supérieur à 10^23 FLOP, combiné à la capacité de générer du texte, de l’audio, de l’image ou de la vidéo. Ce point est important, car il clarifie progressivement le périmètre des acteurs concernés. Pour les organisations qui consomment ou intègrent des modèles ouverts, cela ne signifie pas qu’elles portent toutes les obligations du fournisseur, mais qu’elles doivent mieux qualifier l’origine, les caractéristiques et les engagements de conformité de leurs briques IA.

La Commission a aussi rappelé que les obligations GPAI s’appliquent immédiatement aux nouveaux modèles depuis le 2 août 2025, avec un délai supplémentaire pour certains modèles déjà sur le marché. Cette trajectoire progressive est utile pour le pilotage projet : elle laisse un temps d’adaptation, mais elle ne doit pas être confondue avec une zone grise durable. Les décisions d’architecture prises aujourd’hui doivent déjà anticiper la documentation, la traçabilité et la réversibilité attendues demain.

Le Code de pratique GPAI : un levier pragmatique de conformité

Publié le 10 juillet 2025, le Code de pratique GPAI de l’Union européenne s’est imposé comme l’outil volontaire de référence pour les modèles ouverts et les modèles à usage général. Il couvre trois volets structurants : la transparence, le copyright et la sécurité/sûreté pour les modèles les plus avancés. Pour les fournisseurs, c’est un cadre très concret pour démontrer une volonté de conformité sans attendre que chaque point soit interprété au cas par cas.

La Commission européenne indique d’ailleurs que la signature de ce code peut réduire la charge administrative et renforcer la sécurité juridique. C’est un signal fort pour l’écosystème. Dans les faits, lorsqu’un projet doit sélectionner un modèle, la présence ou non d’un engagement formel vis-à-vis de ce code devient un critère d’évaluation crédible, au même titre que la performance, le coût, la latence ou la qualité d’intégration.

Pour les entreprises utilisatrices, le bon réflexe consiste à transformer ce contexte réglementaire en grille d’achat et en politique d’architecture. Un modèle ouvert n’est pas automatiquement un modèle “moins conforme”, mais il doit être accompagné d’éléments vérifiables : provenance, documentation, posture copyright, modalités de mise à jour, stratégie de sécurité et capacité à répondre à des exigences d’audit. C’est là que la conformité cesse d’être un sujet purement juridique pour devenir un sujet produit et delivery.

Sécurité agentique : les menaces ne sont plus théoriques

Les travaux récents d’OWASP sur l’agentic AI vont dans le même sens : les agents introduisent une classe de risques spécifique. Parmi les menaces mises en avant figurent le détournement du comportement de l’agent, l’abus d’outils et l’abus d’identité ou de privilèges. Ces scénarios parlent immédiatement aux équipes techniques, car ils ressemblent à un mélange de prompt injection, de compromission d’intégration, d’élévation de privilèges et d’automatisation non maîtrisée.

La question n’est donc pas seulement de savoir si le modèle “répond bien”, mais s’il agit correctement dans un environnement adversarial. Un agent qui a accès à un gestionnaire de tickets, à un CRM, à une base documentaire ou à un dépôt Git peut produire de la valeur à grande vitesse ; il peut aussi propager une erreur, exfiltrer une information ou déclencher une action inappropriée avec la même efficacité. Plus l’autonomie augmente, plus la qualité des garde-fous devient déterminante.

Les signaux envoyés par l’industrie confirment cette réalité. OpenAI a publié en 2026 EVMbench pour mesurer la capacité des agents à détecter, corriger et exploiter des vulnérabilités de smart contracts. Le message sous-jacent est clair : à mesure que les agents progressent en cybersécurité, il faut renforcer les contrôles défensifs. Les capacités qui servent à auditer et durcir des systèmes peuvent aussi, si elles sont mal encadrées, amplifier des usages offensifs ou des erreurs à fort impact.

Outillage défensif : vers une sécurité assistée par l’IA

Le mouvement n’est pas seulement réglementaire, il est aussi très opérationnel. En 2026, OpenAI a annoncé des outils orientés sécurité pour les développeurs, comme Codex Security en recherche preview. L’intérêt de cette approche est de construire un modèle de menace spécifique au dépôt, afin de réduire les faux positifs et de mieux prioriser les vulnérabilités. On retrouve ici une logique familière pour les équipes produit : contextualiser l’analyse au plus près du code et du risque réel.

OpenAI met également en avant des contrôles défensifs et des partenariats open source, avec notamment la bêta privée d’Aardvark, un agent de recherche sécurité, ainsi que des scans gratuits pour des bases de code open source largement utilisées. Cela confirme un point souvent sous-estimé : l’IA n’est pas seulement un nouveau périmètre de risque, c’est aussi un nouveau moyen de renforcer l’hygiène de sécurité lorsqu’elle est déployée dans un cadre maîtrisé.

Pour autant, l’outillage n’exonère pas de gouvernance. Un agent de sécurité reste un agent avec des accès, des hypothèses, des limites et des biais. Il doit donc être soumis à des règles de revue, de séparation des responsabilités et de validation humaine adaptées au contexte. Dans une organisation mature, ces outils viennent augmenter les équipes, pas contourner les processus de contrôle.

Conformité continue : pourquoi le machine-readable devient stratégique

À mesure que les obligations s’étoffent, la conformité ne peut plus reposer uniquement sur des documents statiques produits à la main. NIST présente OSCAL comme une brique d’automatisation de la conformité et de la sécurité : un langage ouvert, lisible par machine, conçu pour moderniser les contrôles et réduire des audits de “mois à minutes”. Derrière la promesse, il y a une idée essentielle pour les projets numériques : rendre les preuves de conformité interopérables, traçables et exploitables par les outils.

Cette approche répond très bien à la montée des exigences sur le cycle de vie des modèles. Quand un agent utilise plusieurs composants, plusieurs jeux de données, plusieurs permissions et plusieurs environnements d’exécution, la question n’est plus seulement “sommes-nous conformes ?”, mais “pouvons-nous le démontrer en continu ?”. C’est là que les formats machine-readable deviennent stratégiques, parce qu’ils relient gouvernance, sécurité, delivery et audit.

Pour un chef de projet IT ou un responsable de programme, la leçon est pratique : il faut intégrer la conformité dès la conception des workflows, des pipelines et des référentiels. Journalisation structurée, inventaire des modèles, cartographie des accès, versioning des prompts sensibles, traces de validation et pièces de preuve ne doivent pas être ajoutés en fin de projet. Ils doivent faire partie du design opérationnel dès le départ.

Chaîne d’approvisionnement IA : modèles, données et dépendances sous contrôle

Le NIST relie explicitement l’IA, la conformité et les chaînes d’approvisionnement logicielles à travers ses travaux sur l’AIBOM. La recommandation est claire : suivre l’état des modèles open source et des jeux de données avant usage. Autrement dit, la gouvernance d’un agent ne s’arrête pas à son interface ou à son fournisseur principal ; elle s’étend à toutes les briques qui conditionnent son comportement et son niveau de risque.

Ce point est particulièrement critique avec les modèles ouverts. Leur flexibilité est un avantage considérable, mais elle impose une discipline accrue sur la provenance, les licences, les mises à jour, les dépendances et les éventuelles vulnérabilités associées. Une entreprise qui déploie un agent sur un modèle open source sans gouvernance de supply chain prend un risque comparable à celui d’un produit logiciel assemblé sans visibilité sur ses composants.

Dans la pratique, cela suppose de mettre en place un inventaire vivant : quel modèle est utilisé, dans quelle version, avec quels jeux de données complémentaires, quels outils externes, quelles politiques de sécurité, quelles restrictions d’usage et quel processus de mise à jour. Cette visibilité est la base d’un pilotage crédible. Sans elle, ni la sécurité ni la conformité ne peuvent être durablement tenues.

Gouverner les “employés numériques” comme des actifs d’entreprise

Les entreprises les plus avancées ne traitent déjà plus les agents comme de simples expérimentations isolées. Un cas publié par BNY en 2026 décrit un environnement gouverné dans lequel le prompting, le développement d’agents, la sélection de modèles et le partage se font avec permissions, sécurité et supervision standardisées. Cette approche est intéressante, car elle ne sépare pas l’innovation de l’encadrement ; elle les fait progresser ensemble.

BNY indique aussi avoir étendu ses processus juridiques et de conformité existants à l’IA générative, plutôt que de créer un cadre totalement séparé. C’est probablement l’un des enseignements les plus utiles pour les organisations. Quand les agents numériques deviennent collègues, la bonne réponse n’est pas forcément de bâtir une gouvernance parallèle, mais d’adapter les fonctions de contrôle déjà en place : gestion des accès, revue des risques, validation juridique, supervision métier, audit et gestion du changement.

En tant que démarche projet, cela invite à construire une gouvernance simple et actionnable. Qui peut créer un agent ? Qui peut lui donner des droits ? Qui valide les connecteurs à des outils sensibles ? Qui revoit les journaux d’activité ? Qui déclenche la suspension d’un agent en cas d’incident ? Ce type de clarification est bien plus utile qu’une charte générique, parce qu’il transforme l’IA en capacité exploitable à l’échelle, sans perdre le contrôle.

Au fond, piloter sécurité et conformité à l’âge des modèles ouverts revient à reconnaître une évidence : les agents numériques sont en train d’entrer dans l’organigramme opérationnel des entreprises. Ils ne signent pas un contrat de travail, mais ils disposent d’un périmètre d’action, d’un niveau d’autonomie, d’un accès à des outils et d’un potentiel d’impact qui justifient un pilotage au même niveau d’exigence que n’importe quel actif critique.

Pour les décideurs, la bonne stratégie n’est ni l’interdiction par réflexe, ni l’ouverture sans garde-fous. Elle consiste à articuler innovation et maîtrise : choisir des modèles et fournisseurs documentés, s’appuyer sur le Code de pratique GPAI quand il est pertinent, intégrer les principes OWASP pour l’IA agentique, instrumenter une conformité continue avec des formats lisibles par machine, et gouverner les agents comme des membres encadrés du système d’information. C’est à cette condition que les agents numériques pourront réellement devenir des collègues utiles, et non des risques invisibles.