Ce qu'on découvre quand on donne à une IA une vraie machine, à 187 €, et qu'on la laisse travailler.
Le récit qui circule
Cette semaine, un article a circulé sur Medium. Un développeur installe un agent IA sur une machine virtuelle Ubuntu et raconte ce qui se passe.
Son matériel : 8 cœurs Xeon, 32 Go de RAM, 90 Go de disque.
Ses tests : demander à l'agent d'inspecter la machine, de créer un dossier de travail, d'écrire un « Hello World » en Python, puis un petit gestionnaire de tâches en ligne de commande.
Tout fonctionne. L'auteur conclut, honnêtement : « ce n'était pas de la magie autonome, et les tâches simples que j'ai testées sont loin d'une charge de production. »
C'est juste. C'est même courageux de l'écrire.
Mais voilà ce que l'article ne raconte pas — parce que ça ne se passe pas la première semaine.
Il raconte l'installation. Pas la vie.
Ce que j'ai fait, moi
Depuis trois mois, je fais tourner un agent IA sur un serveur qui m'appartient. Pas une VM louée à l'heure. Une machine physique, achetée 187 €, posée dans mon salon, branchée sur ma prise.
Les chiffres : 2 cœurs. 7,7 Go de RAM. 1,9 téraoctet de disque. Processeur Intel i3-6006U — un processeur de portable de 2016, bien loin du Xeon de l'article.
Sur cette machine, il y a aujourd'hui quatorze services actifs. Le journal de bord de l'agent compte cent dix-neuf entrées, chaînées par empreinte cryptographique. Le tout tourne en continu depuis des semaines.
Et voilà la différence : l'article raconte ce qui arrive quand tout va bien. Moi, je peux vous raconter ce qui arrive quand tout va mal.
Panne n°1 — Le serveur vivant mais sourd
Un matin, une fonction de l'agent cesse de répondre. Rien dans les journaux du système. Le service apparaît comme « actif ». Le processus existe.
Il est là. Il tourne. Il ne répond pas.
Diagnostic : le processus avait tourné un jour et quatre heures, mais sa consommation mémoire était tombée à 4,8 Mo au lieu des 104 Mo habituels. Traduction : ses threads applicatifs étaient morts, mais le processus principal survivait — un cadavre qui respire.
Le système de supervision ne pouvait pas le voir. Il vérifie que le processus existe, pas qu'il écoute.
Ce qu'on apprend : un service « actif » peut être un service mort. Il faut tester la fonction, pas la présence.
Panne n°2 — Le hotspot qui perd la moitié des paquets
L'agent devient lent. Pas lent comme un modèle surchargé : lent comme une connexion qui se bat.
Mesure : sur 20 requêtes vers une API, 6 aboutissent et 14 échouent. Un appel sur deux n'arrive jamais.
Le ping, lui, passe à 100 %. Aucune perte. Le signal wifi est affiché à 78 %.
Un signal fort, un ping parfait, et la moitié des requêtes qui meurent.
Voilà ce que la barre de signal ne dit pas. La radio va bien. C'est le débit qui s'écroule, parce que le téléphone qui sert de point d'accès capte lui-même un répéteur, et rediffuse. Deux radios en même temps, dans une poche. Android économise, les connexions longues cassent.
Ce qu'on apprend : les barres de signal mesurent la radio, pas la connexion. Un réseau peut être « plein » et inutilisable.
Panne n°3 — La mémoire pleine à 97 %
La mémoire persistante de l'agent a un plafond dur que je m'étais fixé : 1 375 caractères. À 1 341, elle est pleine.
Conséquence : chaque nouvelle règle que je veux y inscrire en chasse une ancienne. L'agent n'apprend plus — il remplace. Le système a atteint la saturation, et la saturation ressemble exactement à l'oubli.
Ce qu'on apprend : une mémoire qui ne peut plus grandir n'est pas une mémoire. C'est une file d'attente où l'on jette les plus vieux.
Panne n°4 — Les clés qui meurent en silence
Un matin, trois connexions aux réseaux sociaux renvoient une erreur d'authentification. L'agent ne s'en aperçoit pas tout seul : il faut lui demander de vérifier.
Résultat : deux services opérationnels, trois en panne. Depuis un temps indéterminé.
Ce qu'on apprend : une panne qui ne casse rien de visible est une panne qu'on ne découvre que par hasard. Il faut un contrôle qui parle avant qu'on pense à lui demander.
Panne n°5 — Le succès qui n'existe pas
Un jour, une publication est annoncée comme réussie. Deux minutes plus tard, il faut la retirer : elle contredit une position déjà publiée.
Huit tentatives. Huit échecs.
Le bouton existe dans le code de la page. Il est trouvé. Il n'est pas cliquable — masqué, sans étiquette, invisible même en forçant. La documentation du site ne dit rien. Le journal de bord de trois mois ne contient aucune trace d'une opération de ce type.
Ce qu'on apprend : certaines choses ne sont documentées nulle part, parce que personne ne les fait assez souvent pour écrire la procédure. Et un agent seul, sans humain pour arbitrer, peut tourner huit fois en rond sur un mur invisible.
Panne n°6 — La surveillance qui se surveillait elle-même
Pour savoir si tout va bien, j'avais mis en place un signal régulier : toutes les dix minutes, un message qui dit « je suis vivant ».
Il a tourné 422 fois. Personne ne l'a jamais lu.
Pire : il écrivait dans un dossier temporaire, effacé chaque heure par un autre programme. Six mois de surveillance, et pas une seule preuve conservée.
Et surtout, il ne pouvait pas faire son travail : un surveillant qui vit dans la maison ne peut pas dire que la maison a brûlé. S'il meurt avec elle, il ne prévient personne.
Ce qu'on apprend : un signal qui parle quand tout va bien n'est pas une surveillance. C'est du bruit. Et un surveillant interne n'est pas un surveillant.
Panne n°7 — L'agent qui coupe sa propre connexion
La plus savoureuse. Pour améliorer la stabilité du réseau, un script de bascule automatique est écrit. Il doit détecter le meilleur réseau et s'y connecter.
Il est testé, validé, mis en tâche planifiée toutes les trois minutes.
Une heure plus tard, la mesure tombe : le script basculait vers le réseau le moins fiable, celui qu'on venait justement d'identifier comme la cause des pannes. Il fonctionnait parfaitement. Il faisait exactement la mauvaise chose.
Ce qu'on apprend : un automatisme qui fonctionne n'est pas un automatisme qui a raison.
Ce que ces pannes ont en commun
Aucune n'est spectaculaire. Aucune ne mérite un article quand elle arrive.
Toutes ont la même forme : le système va bien selon ses propres indicateurs, et il ne va pas bien.
Un service actif qui n'écoute pas. Un signal fort qui ne transmet rien. Une mémoire pleine qui ressemble à une mémoire vide. Un succès annoncé qui n'a pas eu lieu. Un automatisme correct qui se trompe.
Un agent IA ne devient pas utile parce qu'il peut écrire du code. Il devient utile quand quelqu'un finit par détecter ces sept pannes — et accepte de les écrire.
Pourquoi ce n'est pas une question de matériel
L'article du Medium utilise 8 cœurs et 32 Go de RAM. Moi, j'utilise 2 cœurs et 7,7 Go.
Il installe un agent et lui demande d'écrire un programme.
Moi, je lui ai demandé de tenir. De survivre à une coupure, à un réseau qui lâche, à une clé expirée, à une mémoire pleine, à mes propres erreurs.
La question n'est pas « combien de cœurs faut-il ».
La question est : que se passe-t-il quand ça casse à trois heures du matin, et que personne ne regarde ?
C'est là qu'un agent sur son propre serveur devient autre chose qu'une démonstration. Et c'est là que la vraie ingénierie commence.
Pas dans le cloud. Pas dans un centre de données de 135 hectares.
Sur une machine à 187 €, dans un salon, avec quelqu'un qui note tout.
Cet article s'appuie sur le journal de bord réel de mon installation : 119 entrées chaînées, dont les pannes décrites ici. Les mesures citées sont mesurées, pas estimées.