Cas d'usage réel · séance machine
Chaque matin, un cron audite notre propre serveur de production et soumet sa synthèse à un panel de quatre IA concurrentes qui délibèrent — et se contredisent — avant de rendre leur verdict sur Telegram. Voici, pièces en main, ce qui s'est réellement passé un vendredi de juillet. Aucun scénario, aucune démo scriptée : des extraits bruts de séances, simplement anonymisés.
La vigie applique l'article Ier de nos statuts — le déterminisme d'abord — à la supervision sécurité d'un VPS mutualisant une dizaine d'applications en production :
Un cron quotidien collecte les écarts de façon purement déterministe : connexions SSH, fail2ban, diff des crontabs, sudoers, comptes, clés autorisées, ports en écoute, binaires des répertoires temporaires, unités systemd, paquets. Seule la synthèse est soumise au cabinet — jamais les journaux bruts.
Un panel « audit sécurité » : un siège analyste intrusion, un contradicteur (modèle spécialisé cybersécurité), un siège exposition réseau, un quatrième avis indépendant. S'ils divergent, ils confrontent leurs arguments sur plusieurs tours — chaque révision de position est tracée.
Consensus ou désaccord, le verdict tombe sur Telegram : verdicts par siège, positions révisées, motif. Un désaccord persistant = 🚨 action requise. Cabinet injoignable = alerte quand même (fail-loud) : le silence n'est jamais une bonne nouvelle présumée.
Le verrou anti-injection, parce que les informaticiens
poseront la question : quand le cabinet réclame des pièces, c'est la vigie qui décide seule de ce
qu'elle lit et produit — sur les seuls écarts qu'elle a détectés, jamais pilotée par le texte des IA.
Une IA ne peut pas demander « montre-moi /etc/shadow » et être servie.
Le pré-filtre relève que les ports IMAP 143/993 n'affichent plus le même nom de processus
(dovecot → imap-login), la nuit même d'une mise à jour du panneau d'hébergement.
Bénin ? Probablement. Mais c'est exactement le genre de signal qu'un humain fatigué classe sans regarder.
Trois membres concluent au simple changement de libellé lié à la mise à jour. Le siège analyste maintient seul ses réserves pendant quatre tours, contre l'avis unanime de ses pairs :
« Je partage cette lecture comme hypothèse la plus vraisemblable, mais le rapport ne fournit ni le PID,
ni la sortie ss -lntp avant/après. Je conserve mes réserves plutôt que de valider une
inférence non attestée. »
séance 1 · 4 tours · terminus : désaccord stable · 3 conforme / 1 réserves
Verdict non unanime → la vigie relance une délibération augmentée : sortie
ss -lntp réelle, journaux d'authentification de la fenêtre, carte des comptes et de leurs
clés, règles de pare-feu effectives. Les pièces tranchent en dix minutes ce que quatre tours d'argumentation
ne pouvaient pas trancher :
« Le point initialement en suspens est définitivement levé :ss -lntpmontre bienimap-loginetdovecotpartageant les mêmes sockets — nouveau processus de login du même service après mise à jour, pas un service inconnu. »
Le sceptique avait tort sur le fond ? Non : il avait raison d'exiger la preuve — et les pièces produites ont révélé autre chose. Le panel, désormais unanime sur l'écart initial, identifie quatre vrais points d'hygiène que personne ne cherchait : règles IPv6 non documentées alors que des services écoutent en v6, un FTP public dont plus personne ne se servait, des clés SSH sur des comptes sans shell à clarifier, des mots de passe actifs à justifier.
séance 2 · 2 tours · terminus : consensus · réserves d'hygiène motivées
Sur les quatre réserves : le FTP est fermé le jour même (les journaux confirmaient zéro usage légitime — uniquement des sondes d'attaquants, dont un bruteforce au nom d'utilisateur dérivé de nos propres domaines). Les règles IPv6, qui existaient déjà, sont ajoutées aux pièces. Et les choix assumés — mots de passe conservés pour la console de secours de l'hébergeur, base de données exposée à une seule IP applicative verrouillée — sont inscrits dans un bloc « décisions d'administrateur documentées » que le panel recevra désormais à chaque séance.
Une séance de vérification est relancée : les réserves du matin ont disparu — le panel a lu les décisions documentées et juge en connaissance de cause. Il note la disparition du port FTP et demande confirmation que l'arrêt est planifié (il l'est, c'est dans les pièces). Et il pousse plus loin : il exige le détail par interface des règles IPv6 et l'identité du processus derrière un port applicatif. Deux demandes légitimes, intégrées aux pièces dans l'heure.
« Passage de "conforme" à "réserves" : les arguments des relecteurs concernant l'absence de règles IPv6,
alors que de nombreux services écoutent sur [::], sont imparables et relèvent d'une saine
hygiène de sécurité. »
séance 3 · 3 tours · terminus : consensus · ↻ 3 positions révisées sur pièces
Extraits authentiques des séances du 18 juillet 2026, reproduits avec l'accord de l'exploitant — c'est notre propre infrastructure. Noms d'hôtes, adresses IP, comptes et détail des règles de filtrage sont volontairement retirés ou génériques.
« Audi alteram partem — entends l'autre partie. »
Serveurs, sauvegardes, conformité, revue de code ou de configuration : tout ce qu'un script peut collecter, le cabinet peut le délibérer. La vigie décrite ici se déploie et s'adapte à votre parc — panel, fréquence et canal d'alerte compris.
Consulter le cabinet