Gouverner l'IA agentique, les MCP et les assistants d'IA pour le code

La complétion de code par IA intègre, de par sa conception, une revue humaine dans le processus. Un développeur écrit du code, une suggestion apparaît, et c'est lui qui décide de l'accepter ou non. Chaque ligne est vérifiée par une personne avant d'être mise en production.

L'IA agentique bouleverse ce cycle de revue. Un agent peut ouvrir une merge request, appeler un outil, modifier une configuration CI/CD et effectuer un push d'une modification, parfois sans qu'une personne n'examine chaque étape individuellement. Ajoutez à cela le Model Context Protocol (MCP), qui permet aux agents de se connecter de manière autonome à des outils et des sources de données externes, et les responsables d'ingénierie ne se demandent plus quel modèle produit le meilleur code : ils veulent au contraire savoir ce que l'agent est autorisé à faire, et comment prouver ce qu'il a accompli.

Une étude menée par GitLab auprès de plus de 1 500 développeurs et responsables technologiques révèle que 73 % des répondants s'inquiètent de la maintenabilité à long terme du code, et que 86 % estiment que, sans gouvernance claire, le code généré par l'IA peut aggraver la dette technique plus rapidement que les pratiques de développement traditionnelles.

Dans cet article, vous découvrirez comment relever de manière proactive certains des défis auxquels les organisations commencent à être confrontées en matière de gouvernance de l'IA agentique. Nous vous présenterons un framework de gouvernance pour l'IA agentique dans le développement logiciel, et nous examinerons ce qu'il convient de contrôler, les domaines où la revue humaine reste indispensable, comment mesurer un déploiement, ainsi qu'une liste de contrôle pratique pour les équipes qui cherchent à standardiser leurs pratiques sur GitLab Duo Agent Platform.

IA agentique : une approche différente en matière de gouvernance

Le modèle de sécurité d'un assistant de codage interactif est simple, car un humain intervient à chaque étape : un développeur pose une question, examine une suggestion, puis l'accepte ou la rejette.

Dans les workflows automatisés, l'IA agentique requiert une approche différente en matière de gouvernance. Lorsqu'un agent peut exécuter des tests, modifier des configurations et effectuer des actions en plusieurs étapes tout au long du cycle de livraison logicielle sans qu'un humain ne vérifie chaque étape, des questions pertinentes se posent :

• À quoi cet agent a-t-il accès ?
• Qu'est-il autorisé à faire ?
• Quelles actions a-t-il effectuées, et peut-on le prouver a posteriori ?

La plupart des équipes font déjà face à ce défi. 92 % des professionnels du DevSecOps signalent au moins un problème de gouvernance lié au code généré par l'IA, et les principales préoccupations sont les suivantes :

• Attribution du code : la capacité à distinguer le code généré par l'IA du code écrit par un humain.
• Traçabilité par rapport à l'intention : relier le code généré par l'IA à l'exigence métier qu'il était censé satisfaire.
• Documentation évolutive : les pratiques de documentation manuelles ne suffisent plus dès lors que les agents génèrent une part croissante du code source.

Une fois qu'un agent est approuvé pour un projet, il peut généralement écrire, supprimer et effectuer un push des modifications sans qu'une personne ne vérifie l'action avant qu'elle ne se produise. Vous restez néanmoins responsable de ce qui est intégré dans le code source, qu'une personne ou un agent ait effectué la modification.

La gouvernance de l'IA agentique n'est pas un complément à la gouvernance de la complétion de code. C'est une approche différente, fondée sur l'identité, les autorisations et l'auditabilité.

Les contrôles pour les MCP, les agents, l'accès aux modèles et les autorisations d'outils

Dès lors que les agents peuvent appeler des outils et se connecter à des systèmes externes via des protocoles comme le MCP, la gestion des autorisations devient le point de contrôle central. Un modèle de gouvernance efficace répond à trois questions avant qu'un agent s'exécute :

1. Quels agents et flows sont autorisés ?
2. Où sont-ils autorisés à opérer ?
3. Quels modèles les agents peuvent-ils utiliser ?

En pratique, cela se traduit par plusieurs couches qui fonctionnent ensemble :

• Un catalogue centralisé pour les agents et les flows : plutôt que de laisser chaque équipe configurer ses propres intégrations d'agents, un catalogue d'IA partagé permet aux administrateurs de décider ce qui est publié, en s'alignant sur les rôles et la structure des groupes existants au sein de l'organisation.
• L'identité composite : l'identité de chaque agent d'IA doit être liée à l'utilisateur qui a demandé l'action, afin que toute action ne puisse jamais être attribuée à l'agent seul. Lorsqu'un agent tente d'accéder à une ressource, les deux entités (l'agent et la personne qui lui a donné l'instruction) doivent être authentifiées et autorisées avant que l'accès ne soit accordé.
• Les garde-fous d'approbation des outils : chaque outil d'agent peut être configuré pour s'exécuter de manière autonome, s'interrompre en attendant l'intervention d'un relecteur humain, ou rester bloqué, de sorte qu'une action sensible comme l'écriture d'un fichier ou la suppression d'une ressource attend une validation avant de s'exécuter.
• Les garde-fous de prompts : étant donné que les agents peuvent traiter des entrées non fiables (une page web, un commentaire sur un ticket, un fichier contrôlé par un attaquant), la plateforme doit détecter les tentatives de détournement du comportement de l'agent en cours de workflow, et pas seulement les consigner après coup.

L'objectif est de disposer d'un plan de contrôle qui traite les autorisations des agents de la même manière qu'une organisation traite déjà les autorisations des utilisateurs humains : celles-ci doivent être basées sur les rôles, auditables et cohérentes sur l'ensemble des projets.

Confidentialité des données et IA auto-hébergée : les questions essentielles à se poser

Le code source est l'un des actifs les plus sensibles d'une organisation, et chaque fonctionnalité d'IA qui y a accès soulève une question relative au traitement des données. Avant de déployer l'IA agentique à grande échelle, les responsables de l'ingénierie et de la sécurité souhaitent généralement obtenir des réponses claires à certaines questions :

• Le fournisseur entraîne-t-il ses modèles sur notre code ?
• À qui appartiennent les données d'entrée et de sortie ?
• Où se trouvent nos sous-traitants, et pouvons-nous être informés lorsque cette liste change ?

Pour les organisations évoluant dans des secteurs réglementés, la question de la localisation des sous-traitants appelle souvent une réponse sans équivoque : aucun traitement ne doit avoir lieu en dehors de leur propre infrastructure. C'est pourquoi l'auto-hébergement constitue un levier de gouvernance à part entière, et non une simple préférence de déploiement. Les options auto-hébergées permettent à une équipe d'exécuter ses agents d'IA sur une infrastructure qu'elle contrôle, tout en suivant précisément l'utilisation par les équipes et en satisfaisant aux exigences des régulateurs.

La prise en charge Bring Your Own Model va encore plus loin et permet aux administrateurs de connecter des modèles qu'ils ont déjà validés en interne et d'associer des modèles spécifiques à certains flows d'agents. Avec cette approche, un workflow sensible peut être rattaché à un modèle approuvé par l'organisation, tandis que les workflows moins sensibles utilisent une option gérée.

L'humain dans la boucle : décider où la revue reste indispensable

La gouvernance n'a pas pour objectif d'empêcher les agents d'agir de manière autonome. Elle consiste à décider, délibérément, où l'autonomie s'arrête et où la revue commence. Une politique opérationnelle distingue généralement deux modes :

• Le travail interactif, où un développeur est présent, examine chaque suggestion et l'approuve ou la rejette directement. C'est le mode que la plupart des équipes connaissent déjà grâce à la complétion de code par IA.
• Le travail automatisé ou headless, comme les agents qui s'exécutent dans des pipelines CI/CD sans qu'un développeur ne les surveille en temps réel. Dans ce cas, la revue doit intervenir soit avant l'action (via des garde-fous d'approbation intégrés aux outils), soit immédiatement après (via une piste d'audit qu'un humain peut vérifier).

Points de décision clés à définir

La revue de code, les tests et la validation, ainsi que l'approbation du déploiement doivent tous être définis en répondant à certaines questions :

• Parmi ces tâches, lesquelles peuvent être accomplies par un agent sans assistance ?
• Parmi ces tâches, lesquelles nécessitent la validation d'une personne désignée avant que la modification ne soit appliquée ?

En pratique, chaque point de contrôle nécessite son propre mécanisme d'application, qui peut prendre la forme suivante :

• Les politiques d'approbation des merge requests déterminent qui doit effectuer une validation avant qu'une merge request ne soit fusionnée, qu'elle ait été ouverte par un agent ou un développeur.
• Les garde-fous d'approbation des outils pour les agents déterminent, outil par outil, si l'action d'un agent s'exécute de manière autonome, s'interrompt pour une revue, ou reste bloquée.
• L'application de scanners bloque une modification au niveau du pipeline jusqu'à ce qu'elle réponde aux exigences des contrôles de sécurité et de qualité requis par votre organisation.

Nous vous recommandons de mettre en place une politique de gouvernance de l'IA à l'échelle de l'organisation plutôt que de laisser chaque équipe définir ses propres pratiques. Vous favoriserez ainsi un usage et des politiques cohérentes, et faciliterez la vérification de votre utilisation de l'IA par les auditeurs.

Un contexte enrichi grâce à la couche décisionnelle

À long terme, il est avantageux de consigner ces approbations sous forme d'enregistrements structurés plutôt que de les laisser se perdre dans des fils de discussion ou de compter sur la mémoire d'un relecteur. Une exception accordée le trimestre dernier, la version de la politique en vertu de laquelle elle a été accordée et la personne qui l'a approuvée constituent exactement le type de référence dont les auditeurs et les futurs agents ont besoin au sein d'une organisation.

Les organisations qui traitent les décisions comme des événements durables et interrogeables bénéficient d'un avantage supplémentaire : le prochain relecteur (humain ou agent) disposera d'un contexte enrichi au lieu de repartir de zéro.

Apprenez-en davantage sur la couche décisionnelle et sur la façon dont la capture des événements décisionnels peut avoir un impact sur votre développement logiciel.

5 indicateurs pour mesurer le déploiement de l'IA

Cinq catégories méritent d'être suivies dès le départ. Examinez-les ensemble plutôt que de manière isolée, car une forte hausse de l'adoption sans analyse correspondante des indicateurs de risque constitue en soi un signal d'alerte.

1. Adoption : nombre d'utilisateurs actifs des fonctionnalités d'IA d'une semaine à l'autre, nombre de flows ou d'agents exécutés, et identification des équipes ayant activé les capacités agentiques par rapport à celles qui ne l'ont pas encore fait.
2. Acceptation et qualité : signaux downstream tels que le taux de retour en arrière sur les modifications assistées par l'IA, et la fréquence à laquelle les merge requests rédigées par l'IA sont approuvées sans modification. Le taux d'acceptation est un indicateur faible de l'efficacité à lui seul, car il ne fournit aucune information sur ce qu'il advient du code une fois qu'il a été accepté.
3. Risque : suivez la fréquence à laquelle les garde-fous d'approbation des outils suspendent une action pour revue, la fréquence à laquelle ces suspensions aboutissent à une action bloquée ou modifiée, et si l'activité d'un agent déclenche une violation de politique.
4. Remédiation : surveillez la couverture des scanners sur l'ensemble des projets, la part des vulnérabilités corrigées automatiquement par rapport à celles classées manuellement, et le délai de résolution des vulnérabilités une fois celles-ci signalées.
5. ROI : une fois que vous disposez d'un trimestre complet de données, explorez le retour sur investissement de votre déploiement d'IA. Mesurez le temps économisé par les développeurs sur les tâches désormais gérées par les agents, et comparez-le au coût par ticket résolu ou par modification fusionnée, en crédits ou en ressources de calcul consommées. Consultez ce tutoriel pour une analyse approfondie du ROI de l'IA : vous apprendrez à transformer des données d'utilisation brutes en informations exploitables et en calculs de ROI.

En suivant ces cinq indicateurs ensemble, vous pouvez détecter rapidement les problèmes liés au déploiement de l'IA. Un déploiement peut sembler réussi en termes d'adoption et d'acceptation, tout en accumulant des risques qui n'apparaîtront qu'au cours d'un audit six mois plus tard. Avec les indicateurs mentionnés ci-dessus, vous obtenez une vision globale de la valeur apportée par l'IA à votre organisation.

Votre liste de contrôle de gouvernance pour GitLab Duo Agent Platform

Voici une liste de contrôle pratique à suivre avant d'étendre l'IA agentique au-delà d'un projet pilote :

• Consultez le Centre pour la transparence de l'IA et vérifiez votre compréhension de l'utilisation des données, des fournisseurs de modèles et des engagements relatifs aux sous-traitants.
• Déterminez, au niveau de la plateforme, quels agents et flows sont approuvés pour utilisation, et publiez-les via le catalogue d'IA de GitLab plutôt que de laisser les équipes les configurer elles-mêmes.
• Configurez les garde-fous d'approbation des outils sur « toujours autoriser », « toujours demander » ou « toujours refuser », en fonction de la sensibilité de l'outil.
• Mettez en place l'identité composite afin que chaque action d'agent soit liée à la personne qui l'a demandée, et que l'accès nécessite l'autorisation des deux.
• Pour les charges de travail réglementées, évaluez les options de déploiement auto-hébergé et Bring Your Own Model au regard de vos exigences en matière de résidence des données.
• Documentez des points de contrôle impliquant une intervention humaine pour la revue de code, les tests et la validation, et l'approbation du déploiement.
• Activez le streaming des événements d'audit pour l'activité des agents, afin que chaque action soit consignée dans la même piste d'audit que votre organisation examine déjà.
• Définissez vos indicateurs de déploiement (adoption, acceptation, risque, remédiation, ROI) avant de les étendre au-delà du projet pilote, et examinez-les ensemble à intervalles réguliers.

Revisitez cette liste à chaque cycle de release. La gouvernance de l'IA agentique n'est pas une configuration ponctuelle. L'apparition de nouveaux agents, de nouveaux outils et de nouveaux modèles soulève souvent de nouvelles questions en matière de gouvernance.

Quand la rapidité de l'IA agentique rencontre le contrôle en entreprise

L'IA agentique redéfinit ce qui doit être gouverné. Auparavant, la complétion de code demandait à un développeur si une suggestion était pertinente. L'IA agentique demande ce qu'un agent est autorisé à modifier, qui a donné son approbation et si l'action peut être prouvée ultérieurement.

Répondre pleinement à ces questions exige une gouvernance intégrée à la plateforme elle-même, et non ajoutée après coup. GitLab Duo Agent Platform fournit un catalogue d'IA, des garde-fous d'approbation et un streaming des événements d'audit directement dans la plateforme où le travail s'effectue, de sorte que la gouvernance ne soit pas rajoutée après coup. Les équipes bénéficient à la fois de la rapidité apportée par l'IA et du contrôle en entreprise, car les garde-fous font partie intégrante du workflow, et non d'un processus parallèle.

Démarrez un essai gratuit de GitLab Duo Agent Platform. Vous disposez de l'édition Gratuite ? Inscrivez-vous en quelques étapes simples. Si vous utilisez déjà GitLab Premium ou GitLab Ultimate, vous pouvez activer GitLab Duo Agent Platform et utiliser les GitLab Credits inclus dans votre abonnement.