Pourquoi l'infrastructure pilotée par l'IA a besoin de preuves, pas seulement d'autorisations

Il y a quelques années, modifier une infrastructure tenait souvent à une simple connexion SSH et à un script bien documenté. Aujourd'hui, les agents IA prennent en charge des tâches bien plus lourdes : migrations, ajustements de capacité, correctifs de sécurité. Le vrai enjeu n'est plus seulement d'exécuter, mais de s'assurer que chaque opération est sûre avant qu'elle ne commence.

Le modèle classique de sécurité ne suffit plus.

RBAC : une réponse insuffisante face aux agents

Vos règles actuelles reposent généralement sur deux piliers :

• RBAC : « Cet utilisateur peut écrire en production. »
• GitOps : « Voici l'état cible que nous souhaitons. »

Mais ni l'un ni l'autre ne répond à la question essentielle : « Pourquoi ce changement précis est-il sûr à cet instant ? »

Un humain apporte son contexte et son jugement. Un agent IA, lui, n'apporte qu'une requête. Sans couche d'explication, on valide uniquement les droits d'accès, pas le raisonnement derrière l'action.

Le risque devient critique dès qu'il s'agit d'opérations avec état : migration de schéma, bascule de données, modification de configuration. Ces séquences sont irréversibles et comportent des dépendances. Votre système de contrôle d'accès n'y voit rien.

Le principe du « change control » fondé sur la preuve

L'idée est simple : chaque modification proposée doit être enveloppée d'une preuve cryptographique avant d'être exécutée. On signe le changement, on le valide, puis on l'applique.

Le flux se déroule ainsi :

1. L'agent soumet sa proposition avec son raisonnement.
2. Le système génère une preuve cryptographique.
3. Un moteur de règles vérifie la conformité.
4. Les signatures sont contrôlées.
5. La modification s'exécute uniquement si tout est valide.
6. Un journal complet, rejouable, est conservé.

Cette preuve inclut :

• Une simulation sur l'infrastructure réelle.
• La détection de dérive.
• Un scan de sécurité et le SBOM.
• Les empreintes des images et leur provenance.
• L'impact prévisible sur les SLO.
• La chaîne d'événements.

Tout est signé, horodaté et stocké avec les artefacts de release.

Exemple concret : migration Oracle vers PostgreSQL

Prenons une migration réelle d'un système Oracle/APEX vers PostgreSQL dans Kubernetes. Ce n'est pas un exercice simple. Il faut vérifier le cluster, geler la source, exporter les données, créer des points de restauration, mettre en place des tables fantômes, vérifier ligne par ligne, puis basculer le trafic.

Quand un agent IA demande à lancer cette séquence, la preuve capture :

• 23 contrôles de validation.
• 20 événements de suivi.
• 20 artefacts de preuve.
• Un score de release à 100 %.

La signature ed25519 permet de vérifier plus tard que rien n'a été altéré.

La double porte : preuve + politique

Même avec une preuve valide, l'autorisation explicite reste obligatoire. Dans les tests, deux demandes ont été bloquées :

• La première parce que l'opération n'était pas listée dans les règles.
• La seconde parce que la signature avait été modifiée.

C'est la défense en profondeur appliquée aux agents autonomes.

Ce que cela change pour votre infrastructure

Les outils GitOps classiques (Argo CD, Crossplane) ont été conçus avant l'essor des agents. Ils savent qui peut agir et quel est l'état voulu, mais pas pourquoi un changement est sûr maintenant.

Si vous passez à des déploiements assistés par IA, à des scalings autonomes ou à des migrations multi-cloud, vous avez besoin d'une traçabilité cryptographique de chaque mutation.

Par où commencer

• Vérifiez si votre système peut générer des preuves cryptographiques.
• Définissez des listes d'autorisation explicites pour les agents.
• Conservez des journaux signés et rejouables.
• Mesurez la confiance accordée à chaque changement.

L'infrastructure devient autonome. Votre contrôle des changements doit suivre le même chemin : passer de « avez-vous le droit ? » à « voici la preuve que c'est sûr ».