DEV Community: Uig

1,5 mètre : le jour où mon robot a refusé de réparer la machine

Uig — Wed, 28 Oct 2026 17:04:54 +0000

Je tire le levier, la machine casse. Mon robot s'approche, pose un diagnostic et la répare. Quatre lignes dans un terminal. Trois jours pour en arriver là.

1,5 mètre

Mon robot était planté là, à 1,5 m pile de la machine. Il l'inspectait. Il avait son diagnostic. Et il ne la réparait pas. Jamais.

Pas de crash. Pas d'exception. Pas une ligne d'erreur. Juste un robot en contemplation devant une machine en panne, pour l'éternité.

La règle était simple : à 1,5 m ou moins, le robot peut s'occuper de la machine. Sauf que je l'avais écrite deux fois, dans deux états différents, et je me suis planté sur le signe. D'un côté <=, de l'autre >=. Deux versions d'une même règle, qui ont divergé pile là où personne ne regarde : sur la borne.

Je l'ai repéré en relisant le code pendant une revue, puis reproduit avec un test à 1,5 m pile. La correction : la règle n'existe plus qu'à un seul endroit, et le test reste posé sur la borne, comme un vigile.

Deux copies d'une même règle finissent toujours par se fâcher.

Un robot, une machine, un levier

Ce robot est le premier habitant d'un monde que je construis. Un monde où des agents décident. À terme, ce monde sera mon laboratoire. Une capsule temporelle où ce que j'apprends et ce que je construis restent au même endroit. Quelque chose qui m'appartient, mais que je partage. Avec des habitants dedans.

Pour l'instant, tout se passe dans le terminal, et rien n'est laissé au hasard. Le moteur est déterministe, et c'est voulu. Plus tard, un LLM proposera les actions du robot, et le moteur décidera de ce qui est permis. Le LLM propose, le moteur dispose.

Pourquoi je m'inflige ça

J'ai un cimetière de side projects. Vous aussi, probablement. Et avec la GenAI, les idées germent vite et pourrissent tout aussi vite.

Celui-ci, je le construis lentement. À contre-courant d'une industrie qui consomme toujours plus, toujours plus vite. Et en ralentissant, j'ai retrouvé un truc que je croyais perdu : le plaisir de coder. Chaque ligne. Chaque test.

Il réunit mes trois obsessions du moment : le creative coding (Three.js, shaders, animation), les agents IA (LLM, mémoire, tool calling) et l'IA de jeu (PNJ, simulation, comportements). Bref : des LLM-powered NPCs dans un monde 3D.

Je viens de PHP. Puis Black October est arrivé : deux RCE critiques au cœur du langage (CVE-2026-109618 et CVE-2026-109619), en plein raz-de-marée de rapports de sécurité assistés par IA. J'ai tourné ma veste et je suis passé à Python. J'y reviendrai dans un article dédié.

Une classe de plus, évidemment

Revenons à nos moutons.

Mon robot passe par quatre états : au repos, en déplacement, en inspection, en réparation. Pour coder ses transitions, deux options.

La table de transitions : un dictionnaire (état, événement) → handler. Plus proche de ma spec, plus simple à tracer. Raisonnable.

État initial	Événement	Précondition	Action	État final
idle	machine.broke	Robot à plus de 1,5 m de la machine	move_to vers le POI de la machine	moving

Ma spec pour modéliser les états du robot

Le state pattern : une classe par état.

J'ai pris le state pattern. Évidemment. Presque dix ans de PHP, ça ne se soigne pas en une semaine : quand on me tend une classe de plus, je la prends.

Ma justification officielle tient quand même la route : la logique de chaque état va grossir. D'autres états arriveront, comme thinking quand le LLM réfléchira. Un nouvel état, une nouvelle classe, sans toucher aux autres.

Une classe par état, donc. Et mon cerveau PHP a enchaîné tout seul : une classe par fichier. Des années de PSR-4, ça laisse des traces. En PHP, l'autoloader fait correspondre chaque classe à un fichier : App\Robot\IdleState vit dans src/Robot/IdleState.php, point. Alors quand je relis robot_fsm.py avec ses huit classes en 152 lignes, j'ai des sueurs froides.

Sauf qu'en Python, le fichier, c'est le module. Et un module regroupe ce qui va ensemble : aucune règle n'impose une classe par fichier, pas même la PEP 8. Huit classes qui parlent toutes de la même machine à états, c'est un module cohérent, pas un dépotoir. J'ai quand même sorti Action de events.py, parce qu'une action n'est pas un événement. Le reste attendra que ça fasse vraiment mal.

Excusez la digression, mais le prix à payer pour le choix du state pattern : si chaque état décide dans son coin, la trace des décisions s'éparpille. Exactement ce que je veux éviter, puisque tout le projet repose sur des décisions qu'on peut relire. Alors chaque état renvoie sa décision, et un seul endroit, la machine à états, l'applique et la journalise. Les états proposent, la machine dispose. Ça ne vous rappelle rien ?

Verdict quand thinking arrivera. Si je me suis trompé, vous le lirez ici.

Quatre claques Python

Python n'a pas de mot-clé interface. J'ai cherché. Pour donner un contrat à mes états, j'ai atterri sur ABC et @abstractmethod : une classe de base abstraite, RobotStateHandler, et une méthode handle que chaque état doit implémenter. Sauf que le contrat ne se vérifie qu'à l'instanciation. Oubliez handle dans une sous-classe, et Python vous laisse la déclarer tranquillement ; il ne râle qu'au moment où tu essaies de créer l'objet. PHP, lui, refuse la classe dès sa déclaration.

default_factory attend une fonction. Avec default_factory=list, mon robot est devenu une liste vide. Pas un robot cassé : une liste. Vide. Et Python n'a rien dit, parce qu'il ne vérifie pas les annotations de type à l'exécution.

Deux de mes tests portaient le même nom. Le second écrasait le premier, en silence. Un test qui passe parce qu'il n'existe plus. C'est ruff qui a cafté.

Les bugs vivent sur les bornes, alors mes tests y vivent aussi : 1,5 m pile pour la distance, et 0, 69, 70, 89, 90 et 100 pour les seuils d'usure du diagnostic.

J'ai noté une vingtaine d'autres notions. Je les garde pour une série « Un dev PHP apprend Python ».

La suite

Prochaine étape : tirer le levier depuis une page web et voir le robot réagir en direct.

Le code est sur GitHub : github.com/Arawnn/the-little-workshop. Et vous, vous faites quoi en ce moment ?

L'illusion de l'auto-citation

Uig — Mon, 19 Oct 2026 20:18:16 +0000

4 citations sur 4 vérifiées. 6 valeurs justes sur 24. Les valeurs existent bien, mais pas à la bonne place !

Contexte

Je suis en train de construire un petit package PHP pour analyser mes factures de climatisation. Les prix augmentent, mais difficile de savoir de « combien » précisément. Exemple, avec les chiffres d'une de mes vraies factures :

// (prix actuel - prix contrat) / prix contrat
((0,07405888 - 0,06178300) / 0,06178300) × 100 = 19,87 %  -> +20 % sur le kWh

Voici le flux du script de démo :

L'idée : fournir au LLM, ici un modèle local (gemma4:e2b) qui tourne avec Ollama sur mon Mac, trois ingrédients :

un prompt ;
l'extraction linéarisée d'une facture PDF ;
le schéma JSON, passé via le paramètre format, pour obtenir une réponse toujours structurée de la même façon.

Je demande aussi au modèle, pour chaque ligne, une citation : la ligne de la facture d'où il a tiré ses valeurs, copiée mot pour mot.

{ "label": "ACS", "base": "18,34", "citation": "ACS 2.475,00 0,00740931 €/L 21,00 18,34 € 3,85 € 22,19 €" }

Le code vérifie ensuite que la citation existe dans le texte d'origine de la facture, puis que chaque valeur figure dans la citation.

Tout est vert… puis plus rien

Avec une première version du prompt, les valeurs sont presque toutes justes, mais les citations ne servent à rien : le modèle n'y met que le libellé (« ACS ») au lieu de la ligne complète.

Je modifie donc mon prompt pour préciser ce qu'est une citation :

La citation est la ligne complète du tableau, telle qu'imprimée, et l'unité est celle du prix (€/L), pas celle de la quantité.

Et hourra : 24/24 pour les valeurs (6 champs × 4 lignes) et 4/4 pour les citations. C'est plié, terminé, bonsoir !

Mais ensuite, je me plante dans la normalisation des espaces : j'envoie au LLM le texte extrait normalisé. Et là, c'est la catastrophe : mon score de valeurs tombe à 6/24, alors que les citations sont toujours correctes, 4/4.

Toutes les valeurs sont présentes, mais pas dans les bons champs. Exemple sur la ligne ACS :

Champ	Valeur attendue	Valeur extraite
`quantity`	2.475,00	2.475,00 ✓
`price`	0,00740931	0,00740931 ✓
`vat_percent`	21,00	0.00000000 ✗
`base`	18,34	21,00 ✗
`taxes`	3,85	18,34 ✗
`subtotal`	22,19	3,85 ✗

Chaque montant a glissé d'une colonne.

Ce que la citation ne voit pas

Le schéma garantit une réponse structurée. La citation garantit que les valeurs extraites existent bien dans la source. Ni le schéma, ni la citation ne garantissent que le LLM range chaque valeur dans la bonne case.

Pourquoi les colonnes ont glissé

La normalisation a supprimé les tabulations qui permettaient au LLM d'identifier les colonnes de la facture.

Ce que pdfparser produisait (texte brut) :

Concepto → Cant. → Tarifa → %IVA → Base → Impuestos → Subtotal
ACS → 2.475,00 → 0,00740931 €/L → 21,00 → 18,34 € → 3,85 € → 22,19 €

Les flèches représentent une tabulation. 7 colonnes d'en-tête, 7 cellules de données. Une tabulation marque toujours le passage à la cellule suivante. Les espaces, eux, n'apparaissent qu'à l'intérieur d'une cellule (0,00740931 €/L, 18,34 €). Le modèle n'a qu'à compter les tabulations.

Après ma normalisation (tout devient espace) :

Concepto Cant. Tarifa %IVA Base Impuestos Subtotal
ACS 2.475,00 0,00740931 €/L 21,00 18,34 € 3,85 € 22,19 €

La ligne de données passe de 7 à 11 éléments : le modèle n'a plus de moyen fiable de deviner où finit une cellule, et il a probablement mal compté.

4 citations sur 4 vérifiées. 6 valeurs justes sur 24. Les valeurs existent bien, mais pas à la bonne place !

Et alors ?

Je l'ai détecté en local parce que je confronte les valeurs extraites aux valeurs attendues, avec un fichier que je connais à l'avance. En production, ce fichier n'existe pas.

Et en production, la même chose arrive sans erreur de notre part : quand un fournisseur change la mise en page de ses factures, quand on passe par un OCR, ou quand on change d'extracteur PDF. L'entrée change, et la structure disparaît silencieusement. Si je m'appuyais uniquement sur les citations, la facture serait passée.

Un contrôle qui, lui, l'aurait vu

Une solution possible, dans mon cas, est d'ajouter un point de contrôle déterministe : un calcul croisé (cross-checking) qui vérifie que les calculs sont corrects.

En reprenant la ligne ACS :

quantité × prix = 2 475 × 0,00740931 = 18,34, alors que le modèle a mis 21,00 dans base. Le calcul échoue, et l'extraction est rejetée.

Chaque contrôle voit une chose, et en laisse passer une autre :

Contrôle	Ce qu'il prouve	Ce qu'il laisse passer
Schéma JSON	Les champs existent, au bon type	Une valeur dans le mauvais champ
Citation	La valeur existe dans le document, sur la bonne ligne	Une valeur dans la mauvaise colonne
Calcul croisé	Les valeurs sont cohérentes entre elles	Une erreur qui garde les calculs justes (rare, mais possible)

Ce que je change dans mon pipeline

Je ne touche plus à l'entrée du modèle. Le texte envoyé au LLM reste brut, tabulations comprises. La normalisation sert uniquement à comparer, et elle s'applique à des copies.
Je ne considère plus une citation comme une preuve suffisante. Elle prouve qu'une valeur existe dans le document. Pour savoir si elle est dans la bonne case, j'ajoute un contrôle qui relie les valeurs entre elles : quantité × prix = base, et somme des lignes = total.
Je mesure avant de croire. Chaque changement (prompt, modèle, extracteur PDF) repasse sur des factures dont je connais les vraies valeurs. Sans ce score, j'aurais vu 4/4 citations vérifiées, et je serais passé à la suite.

Et vous, comment vérifiez-vous que vos extractions LLM rangent les bonnes valeurs dans les bonnes cases ?