Tout le monde a déjà vu un agent produire du code parfaitement fonctionnel… et parfaitement contraire aux règles maison : la mauvaise librairie, un secret en dur, une convention de nommage ignorée. Le réflexe habituel - recoller les règles dans chaque prompt - ne tient pas à l'échelle d'une équipe. On oublie, on diverge, et personne ne sait plus quelle règle s'applique vraiment.
La réponse de Survol s'appelle les contraintes techniques d'organisation : des règles communes à tous les produits, injectées automatiquement au début de chaque session d'agent. Plus besoin de les répéter - elles sont là, par construction.
Gouverner une IA, ce n'est pas la surveiller après coup. C'est définir, avant, ce qu'elle a le droit de faire.
Trois niveaux d'autorité
Toutes les règles ne se valent pas. Certaines sont non négociables, d'autres sont de simples préférences. Survol distingue donc trois niveaux :
- Impérative - jamais contournée. L'agent doit s'y plier, point.
- Forte - l'agent peut la contester avec arguments. Sa contestation ouvre alors une décision produit, qu'un humain tranche.
- Préférence - appliquée par défaut, mais sans drame si le contexte justifie de s'en écarter.
Ce niveau intermédiaire - la contrainte « forte » - est le plus intéressant. Il refuse le choix binaire entre « l'agent obéit aveuglément » et « l'agent fait n'importe quoi ». L'agent peut dire « je pense qu'ici, votre règle dessert l'objectif, voilà pourquoi » - et c'est un humain qui décide. La règle reste, mais elle dialogue.
# Contraintes injectées au début d'une session [impérative] "Aucun secret en clair dans le dépôt" [impérative] "Toute entrée utilisateur est validée côté serveur" [forte] "Préférer la librairie maison X pour les appels HTTP" [préférence] "Commentaires de code en anglais"
Une hiérarchie claire
Les contraintes se cascadent selon une hiérarchie : organisation → produit → fonctionnalité. Une règle globale de l'organisation s'applique partout par défaut, mais peut être désactivée pour un produit donné (affichée comme telle, et réactivable à tout moment). Les globales appliquées par défaut ne polluent pas l'affichage : on ne montre que ce qui mérite attention.
Tout est tracé. Chaque application - et chaque contestation - d'une contrainte est journalisée. Vous pouvez répondre, des mois plus tard, à « pourquoi l'agent a-t-il fait ce choix ? » : la règle qui s'appliquait, son niveau, et la décision humaine s'il y a eu débat.
Pourquoi ça compte vraiment
C'est le chaînon qui manque à beaucoup d'équipes : entre « observer ce que fait l'IA » et « décider ce qu'elle a le droit de faire », il y a un monde. Les contraintes d'organisation matérialisent la seconde. Elles transforment une masse de bonnes intentions éparpillées en un cadre exécutable, cohérent d'un produit à l'autre, et auditable.
En résumé
- Vos règles sont injectées au début de chaque session - plus besoin de les répéter.
- Trois niveaux : impérative (jamais), forte (contestable, un humain tranche), préférence (par défaut).
- Hiérarchie organisation → produit → fonctionnalité, avec désactivation possible par produit.
- Chaque application et chaque contestation sont journalisées.
Donner de l'autonomie à un agent sans cadre, c'est jouer à la roulette. Lui donner un cadre clair, hiérarchisé et tracé, c'est exactement ce qui permet de lui faire confiance - et de dormir tranquille pendant qu'il travaille. Les contraintes d'organisation ne brident pas l'IA : elles la rendent fréquentable à l'échelle d'une entreprise.
