2026-07-03 · 8 min
Une checklist concrète pour autoriser les agents IA dans un environnement professionnel : données, secrets, commandes, audit, licences, SSO et critères de revue.
Autoriser un assistant IA de code n'a plus le même sens qu'en 2023. À l'époque, l'outil suggérait quelques lignes. En 2026, il peut lire un dépôt, modifier plusieurs fichiers, lancer des commandes, générer des tests, ouvrir une pull request ou préparer une migration. La gouvernance doit suivre ce saut d'autonomie.
La bonne question n'est pas "faut-il interdire les agents ?" mais "quelles permissions leur donner, sur quels dépôts, avec quelles preuves et quelle revue humaine ?". Une interdiction totale pousse souvent les usages dans l'ombre. Une autorisation structurée permet au contraire de capter la productivité sans perdre le contrôle.
1. Cartographier les données accessibles
Listez les dépôts par sensibilité : open source, produit interne, données client, sécurité, paiement, infrastructure. Un outil acceptable sur un dépôt marketing peut être interdit sur un dépôt contenant des secrets opérationnels ou du code réglementé. Les pages de sécurité officielles doivent expliquer la rétention, l'entraînement des modèles et les options d'exclusion.
2. Séparer lecture, écriture et exécution
Un agent qui lit du code n'a pas le même risque qu'un agent qui écrit sur le disque ou lance des commandes. La politique interne doit distinguer ces niveaux. Lecture seule pour l'exploration, écriture contrôlée pour les tâches de dev, exécution terminal limitée aux scripts autorisés pour les environnements sensibles.
3. Exiger une trace d'audit lisible
Chaque session utile doit produire une trace : objectif, fichiers modifiés, commandes lancées, erreurs rencontrées, tests exécutés, limites connues. Sans cette trace, la revue humaine devient plus lente que le gain généré. C'est un critère d'achat, pas une option de confort.
4. Vérifier SSO, SCIM, politiques et séparation des espaces
Pour une équipe, le plan individuel ne suffit presque jamais. Il faut regarder l'authentification, la gestion des sièges, les politiques par organisation, l'exclusion de fichiers, les logs admin et la désactivation rapide d'un utilisateur. GitHub Copilot docs, Claude Code docs et les pages enterprise des fournisseurs doivent être lues sous cet angle.
5. Définir ce qu'un agent n'a jamais le droit de faire
- Lire ou afficher des secrets, tokens, clés privées ou fichiers d'environnement.
- Modifier une configuration production sans revue explicite.
- Supprimer massivement des fichiers sans validation humaine.
- Installer des dépendances non approuvées dans un dépôt sensible.
- Envoyer du code propriétaire vers un service non autorisé.
6. Mettre en place un pilote mesurable
Un pilote sérieux dure deux à quatre semaines et mesure des tâches réelles : correction de bug, ajout de page, refactor local, génération de tests, migration mineure. Les métriques importantes sont le temps gagné, le taux de retouche, le nombre d'erreurs introduites, la satisfaction développeur et la charge de revue.
La checklist d'achat
| Point | Exigence minimale |
|---|---|
| Données | Rétention claire, entraînement contrôlable, exclusions disponibles. |
| Identité | SSO ou contrôle organisation fiable pour les équipes. |
| Permissions | Différence nette entre lire, écrire et exécuter. |
| Audit | Historique exploitable des actions et décisions. |
| Réversibilité | Désactivation simple, export des données utiles, pas de lock-in excessif. |
| Prix | Quotas et limites lisibles avant l'achat. |
Le verdict
Les agents IA de développement doivent être gouvernés comme des outils d'exécution, pas comme de simples assistants de texte. Une DSI qui pose les bonnes limites peut autoriser des workflows très puissants sans ouvrir la porte à l'improvisation. Le fournisseur gagnant sera celui qui aide l'équipe à aller vite tout en rendant chaque action compréhensible, auditable et réversible.