Engineering Notes

Pourquoi je demande un audit READ-ONLY avant une modification sensible

Observer l’existant avant de laisser l’IA modifier un système réduit le risque et améliore la qualité de la décision.

3 min de lecture
  • Governance
  • AI-assisted Engineering
  • Security

Pourquoi cette pratique est apparue

Dans KOUSSEVO, certaines évolutions touchaient des éléments liés entre eux : relations, accès, documents ou sessions. Une modification apparemment locale pouvait avoir des conséquences sur un autre parcours.

J’ai progressivement séparé l’observation de l’implémentation. Avant de demander une correction, je demande à l’IA de décrire l’existant et de préciser ce qui est connu, supposé ou encore à vérifier.

Ce qu’est un audit READ-ONLY

Un audit READ-ONLY est une phase d’analyse sans modification du système examiné. Son objectif est de produire une compréhension suffisamment solide pour décider de la suite.

Il ne s’agit pas d’une garantie de sécurité à lui seul. Un outil, un script de diagnostic ou un test peut avoir des effets de bord. Le caractère « lecture seule » doit être vérifié pour les opérations envisagées, et les accès restent limités au périmètre autorisé.

Plus une opération est sensible, plus je cherche d’abord à réduire l’incertitude avant de modifier quoi que ce soit.

Ce que je demande à l’IA d’examiner

Je demande une analyse structurée autour de quelques questions :

  • Quel comportement est attendu et quel écart est observé ?
  • Quels composants et fichiers interviennent ?
  • Quelles règles existantes faut-il préserver ?
  • Quelle cause est démontrée, et quelles hypothèses restent ouvertes ?
  • Quelles dépendances et quels risques accompagnent les options proposées ?
  • Comment vérifier le changement et revenir en arrière ?

La cause racine doit être expliquée à partir des éléments disponibles. Si elle n’est pas établie, je préfère une hypothèse explicitement présentée comme telle à une certitude artificielle.

Ce que je refuse pendant cette phase

Je n’autorise pas de modification de fichier, de migration, de suppression ou de déploiement pendant l’audit. Je refuse également qu’une suggestion soit exécutée simplement parce qu’elle semble évidente.

Les commandes proposées sont examinées avant toute action. Aucun secret ni contenu privé ne doit être copié dans une documentation publique ou un compte rendu destiné à être partagé.

Ce que l’audit apporte

L’audit rend la décision plus concrète. Je peux comparer des approches, connaître les fichiers impactés et définir les critères d’acceptation avant d’engager l’implémentation.

Il aide aussi à limiter le changement : une cause identifiée ne justifie pas une refonte générale. L’intervention doit rester compréhensible, vérifiable et proportionnée au besoin.

Quand je l’utilise

Je privilégie cette phase avant une migration, une suppression de données, une modification d’authentification, un changement de relations ou un déploiement sensible.

Le niveau de détail dépend du risque. Pour une opération réversible et très limitée, l’analyse peut être courte. Pour une opération touchant des données ou des accès, elle doit expliciter les contrôles, le point de restauration et les conditions d’arrêt.

À retenir

Observer avant de modifier permet de séparer analyse et action. L’IA prépare les éléments de décision ; je valide l’approche et le périmètre avant de lui confier l’implémentation.