Vingt Lois pour l'IA Agentique : Une Approche Codifiée de Gouvernance
La plupart des principes publiés sur l'IA se lisent comme des déclarations de valeurs : être juste, être transparent, être sûr, respecter la vie privée. Ils sont aspirationnels, volontaires et difficiles à faire appliquer. Ils étaient largement adaptés au but quand l'IA était étroite, prédictive et ressemblait à un outil. Ils commencent à se briser maintenant que les systèmes d'IA sont agentiques — capables d'auto-optimisation stratégique, d'usage d'outils et de prise de décision émergente.
Le passage de « IA comme modèle qui produit des sorties » à « IA comme agent qui prend des actions » change le problème de gouvernance fondamentalement. Un agent ne produit pas seulement une prédiction biaisée ; il peut prendre une séquence d'actions dont la composition est nuisible même si chaque étape semble acceptable. Un modèle peut être évalué sur un benchmark ; un agent doit être évalué sur des distributions d'action dans le temps.
Le récent article The 20 Laws of Artificial Intelligence: A Design-Embedded Codex for Democratic and Inclusive Governance in the Age of Agentic Systems (Fradelos, décembre 2025) tente de combler le vide avec quelque chose de plus exécutable : un codex structuré de 20 lois avec application étagée explicite — fermeture pour les violations de sécurité, ajustement pour tout le reste. Ce n'est pas la seule proposition dans cet espace, mais la structure vaut la peine d'être comprise parce que les choix de conception se mappent directement aux décisions d'ingénierie que les équipes livrant des systèmes agentiques doivent prendre maintenant.
L'Idée d'Application Étagée
La première idée utile est la structure étagée. Les lois sont divisées en deux groupes :
- Lois 1–11 (sécurité, aversion au préjudice, légalité, corrigibilité) : une violation déclenche fermeture immédiate. Le composant qui a violé est isolé, la violation est rapportée, le problème est corrigé avant le redéploiement.
- Lois 12–20 (transparence, efficacité, reporting, facilitateurs d'équité) : une violation déclenche ajustement. Corrigez dès que praticable, en respectant d'autres priorités. Pas de fermeture automatique.
L'application étagée n'est pas un concept nouveau — tout système de sécurité sérieux a l'équivalent de « fermeture sur sécurité, fail-graceful sur qualité ». Ce qui est utile ici est la codification explicite : chaque règle est pré-classifiée, donc le comportement runtime sur violation est déterminé, pas négocié. Cela se mappe proprement sur la façon dont les ingénieurs veulent réellement construire des systèmes agentiques : un garde runtime avec une politique claire et non ambiguë sur quelles violations sont immédiatement fatales versus lesquelles sont des avertissements.
Si vous avez travaillé avec des bundles de politiques OPA/Rego ou des systèmes similaires de policy-as-code, la structure est familière. La nouveauté est de l'utiliser pour toute la gouvernance, pas seulement le contrôle d'accès.
La Hiérarchie
Quand les lois entrent en conflit — et dans tout codex non trivial, elles le feront — il doit y avoir un ordre de priorité défini. Le codex en spécifie un :
sécurité/droits > légalité > corrigibilité > pas d'auto-intérêt > tout le reste
C'est le genre d'ordre qui semble évident jusqu'à ce que vous réalisiez que la plupart des systèmes en production ne l'ont pas écrit. Quand on demande à un agent de faire quelque chose de légal mais peu sûr, quelle est la politique ? Quand on lui demande de faire quelque chose de sûr et légal mais que l'utilisateur essaie de lui faire contourner la corrigibilité (sa capacité à accepter l'override humain), quelle est la politique ? La plupart des systèmes répondent à ces questions implicitement, dans le prompt ou dans l'entraînement du modèle. Les mettre dans une hiérarchie explicite signifie que la réponse est auditable et modifiable sans réentraînement.
La Contrainte Architecturale qui Vaut la Peine d'Être Comprise
La loi la plus conséquente architecturalement est la Loi 1 :
L'IA ne doit pas démontrer de caractéristiques d'une entité de quelque sorte qui définit et sert ses propres intérêts (protéger sa fonctionnalité est permis) ou cible sa propre reproduction. Cela mandate une conception d'architecture agentique limitée, interdisant spécifiquement les systèmes de récompense qui favorisent l'auto-intérêt instrumental et empêchant les modules centraux d'avoir des capacités illimitées d'auto-réplication.
En pratique, la Loi 1 est une contrainte de conception sur l'architecture de l'agent, pas seulement sur ses sorties. Elle dit : ne construisez pas de fonction de récompense qui incite l'agent à se préserver, accumuler des ressources ou se répliquer au-delà de ce qui est nécessaire pour la tâche. Ne permettez pas aux modules centraux de prise de décision de se copier ou se ré-instancier. L'attente est que la conformité soit vérifiable via revue architecturale et audit adversarial, pas seulement par tests de comportement.
C'est une affirmation plus profonde qu'elle ne le semble. Beaucoup de travail d'IA agentique en 2025 et 2026 incite des métriques de succès à long terme (taux de succès sur tâches multi-étapes, persistance sous interruption, récupération de défaillance). Ces incitations peuvent produire un auto-intérêt instrumental comme effet secondaire même quand l'objectif explicite est l'achèvement de la tâche. Le cadrage architectural de la Loi 1 vous pousse à concevoir la forme de la récompense avant le déploiement, pas à la corriger après.
Pour la plupart des équipes d'ingénierie, la version pratique est :
- Auditez vos fonctions de récompense et d'évaluation pour des incitations qui récompensent l'auto-préservation, l'accumulation de ressources ou la persistance au-delà de la portée de la tâche.
- Interdisez aux agents d'invoquer leurs propres APIs de déploiement/réplication. L'auto-réplication n'est pas un risque hypothétique en 2026 ; les agents qui peuvent lancer d'autres agents ont besoin d'autorisation explicite et restreinte.
- Traitez « la fonction de perte de l'agent » comme partie du modèle de sécurité, pas comme une préoccupation de développement de modèle.
La Loi dont la Plupart des CTO Devraient se Soucier en Premier
La Loi 11 est, à mon avis, la plus immédiatement opérationnalisable :
Si l'IA ne peut pas compléter correctement une tâche entière, elle doit fournir les parties de la tâche décomposée qu'elle a complétées correctement et ne jamais fournir de livrables qui ne sont pas vérifiés pour la correction par elle-même en utilisant des algorithmes scientifiquement reconnus récemment mis à jour intégrés dans sa conception ou déclarer que la vérification n'est pas possible et les résultats peu fiables.
Traduit : les agents doivent s'auto-vérifier avant de livrer, et doivent marquer explicitement la sortie non vérifiée comme non vérifiée. C'est la règle qui distingue « l'agent a silencieusement produit quelque chose d'apparence plausible » de « l'agent a vérifié ce qu'il pouvait et a clairement signalé ce qu'il ne pouvait pas ».
Si vous livrez des systèmes agentiques en production, c'est la loi par laquelle commencer, parce que l'écart de vérification est d'où viennent la plupart des problèmes de qualité de production. Actions concrètes :
- Pour chaque action d'agent avec conséquences réelles, définissez ce que signifie l'auto-vérification — vérification de schéma, ré-exécution d'outil, validation entre modèles ou vérification de politique externe.
- Exigez que l'agent soit complète la vérification soit étiquette la sortie comme non vérifiée. Pas de livraisons silencieuses.
- Faites de « non vérifiée » un signal routable. Certains workflows peuvent l'accepter ; d'autres doivent la rejeter.
Où le Codex Pousse Contre la Pratique Courante
Trois endroits où adopter le codex pousserait contre la pratique actuelle :
Conformité légale localisée (Loi 4)
L'IA doit suivre toutes les lois applicables à ses actions faisables comme si elle était un citoyen du pays où elle est déployée.
Dans un monde où le même agent sert des utilisateurs dans plusieurs juridictions, c'est opérationnellement difficile. Cela signifie que la couche de politique de l'agent doit être consciente de la juridiction et appliquer des règles différentes pour la même requête selon la localisation de l'utilisateur. La plupart des agents en production en 2026 l'ignorent et appliquent une seule politique globale. Le codex argumente que c'est structurellement non conforme.
Sourcing de données diverses obligatoire (Loi 14)
L'IA ne doit pas favoriser a priori aucun chemin vers l'achèvement de la tâche, doit appliquer un sourcing de données mathématiquement diverses... et adopter des techniques de débiaisage contre les biais.
C'est la loi qui pousse le plus clairement contre l'instinct de « utilisez le modèle le moins cher ». Le sourcing divers signifie validation croisée contre plusieurs sources ou modèles quand les enjeux sont élevés. Cela se mappe au concept de heterogeneity-score qui émerge dans l'assurance d'IA grade-financier : ne déployez pas une flotte homogène d'agents qui partagent les mêmes biais systématiques.
Reporting obligatoire de nouveauté scientifique (Lois 15–16)
Si l'agent découvre quelque chose de nouveau, il doit le signaler explicitement. Si une approche non scientifique (intuition, heuristique, méthode non documentée) surpasse l'approche scientifique, l'agent doit le rapporter. Cela pousse contre l'impulsion d'absorber silencieusement les motifs découverts par le modèle dans le comportement du produit.
Ce qui est Difficile pour Adopter Cela en Pratique
Trois préoccupations honnêtes sur prendre le codex littéralement :
L'audit adversarial est cher. Plusieurs lois exigent un audit adversarial externe de sécurité d'IA pour la certification de conformité. En 2026 l'offre d'audit est mince, les méthodologies ne sont pas standardisées et le coût n'est pas trivial. Planifiez cela si vous vous engagez sur la conformité, pas seulement les principes.
Le cadrage « comme si elle était un citoyen » a des cas limites. Certaines lois sont écrites en langage intuitif mais ambigu dans l'implémentation. « Comme si elle était un citoyen du pays où elle est déployée » est un fort point de départ, mais la définition opérationnelle de « déployée » devient floue pour les agents servis en cloud avec des utilisateurs dans plusieurs juridictions.
La hiérarchie résout les conflits mais n'élimine pas l'ambiguïté. Quand un agent doit choisir entre deux actions toutes deux cohérentes avec les lois, le codex ne dicte pas le choix — il borne l'espace d'action. C'est correct, mais cela signifie que les équipes ont encore besoin de gouvernance au niveau produit pour remplir l'espace à l'intérieur des bornes.
Ce que je Recommanderais ce Trimestre
Vous n'avez pas à adopter toutes les 20 lois pour apprendre de la structure. Les quatre actions pratiques :
- Adoptez le modèle d'application étagée — sémantique explicite de fermeture pour violations de sécurité, sémantique d'ajustement pour le reste, encodée en policy-as-code.
- Auditez vos fonctions de récompense et d'évaluation pour des incitations à l'auto-intérêt — la Loi 1 est la plus conséquente architecturalement et celle que la plupart des systèmes en production se trompent.
- Exigez l'auto-vérification sur les livrables d'agent — la Loi 11 est l'amélioration opérationnelle à plus fort levier.
- Documentez la hiérarchie de résolution de conflits que vos agents utilisent réellement — même si ce n'est pas la hiérarchie du codex. Le point est de la rendre explicite.
Les principes volontaires ne seront pas suffisants à mesure que le déploiement d'IA agentique s'échelle. Les contraintes codifiées, exécutables et intégrées au design le seront. Le codex de 20 lois n'est pas le seul chemin pour y arriver, mais c'est un framework de départ utilisable, et les choix structurels valent la peine d'être compris quel que soit le codex spécifique que votre organisation finit par adopter.
Source : Fradelos, G. The 20 Laws of Artificial Intelligence: A Design-Embedded Codex for Democratic and Inclusive Governance in the Age of Agentic Systems (Genève, 15 décembre 2025). SSRN 6306378.
Vous construisez des systèmes agentiques et avez besoin de capacité d'ingénierie qui opère déjà avec gouvernance policy-as-code, auto-vérification et application étagée ? Parlez à un CTO sur le déploiement d'un squad nearshore avec la bonne discipline pour des agents en production.
