Tester avant de construire

La quasi-totalite des erreurs viennent de la : le programme fait exactement ce qu'on lui a demande, mais la page, le site ou la donnee ne ressemblent pas a ce qu'on imaginait. Un bot ne devient fiable qu'apres avoir ete confronte au reel, plusieurs fois, sur des cas qui ne rentrent pas dans le moule.

Voici des exemples concrets, pris dans des projets differents : comparaison de prix, recherche d'emploi, analyse de donnees.

Un outil de comparaison de prix relevait la valeur d'un article sur une fiche produit. Il remontait des occasions en apparence excellentes. Sauf que sur ce site, le bas de la fiche affiche aussi les prix d'autres articles recommandes. Le programme lisait donc parfois le prix du voisin.

Quatre fausses alertes avant que le probleme soit compris, puis correction : la lecture est desormais limitee a la zone de la fiche qui correspond reellement au produit scanne. Un test en laboratoire n'aurait jamais revele ca, seule l'utilisation reelle l'a fait sortir.

Un comparateur interrogeait plusieurs sites de rachat pour trouver le meilleur prix. L'un d'eux s'est mis a bloquer les requetes automatiques. Le programme a continue de fonctionner normalement, en se rabattant sur une seule source, sans rien signaler. Les resultats restaient plausibles, ils etaient simplement devenus incomplets.

C'est le type de panne le plus dangereux, parce que rien ne casse visiblement. Depuis, une source indisponible est annoncee explicitement plutot que contournee en silence.

Sur un agregateur d'offres d'emploi, l'objectif etait de postuler automatiquement. Verification faite, les liens fournis par ce service ne mènent jamais au site de l'employeur mais toujours vers l'agregateur lui-meme. La candidature automatique y est donc structurellement impossible, quelle que soit la qualite du code.

Ce site a ete conserve, mais en recherche seule, et c'est indique noir sur blanc dans l'application. Annoncer une limite vaut mieux que la decouvrir en production.

Meme logique ailleurs : sur un site de rachat, la categorie generale plafonnait a une centaine de pages, ce qui rendait invisible toute une tranche de prix. La solution n'a pas ete de forcer, mais de parcourir les vingt-huit sous-categories separement.

Le meilleur exemple oppose deux outils qui font pourtant la meme chose. Le scanner mobile lit le code-barres imprime sur l'objet : ce code est un identifiant unique, il designe une edition precise et une seule, donc la valeur trouvee est la bonne. Fiable sur les livres comme sur les jeux video, les boites Lego, les figurines ou les disques.

Le bot de veille, lui, travaille sur des annonces en ligne qui n'affichent aucun code-barres. Il ne peut donc chercher que par titre. Or un titre n'identifie rien de precis : un meme film existe en dizaines d'editions dont les valeurs n'ont aucun rapport. Sur l'echantillon teste pour les disques et les films, la totalite des correspondances etaient fausses.

Conclusion appliquee telle quelle : ces categories restent couvertes par le scanner, qui dispose de l'identifiant, et sont exclues de la veille par titre, qui ne l'a pas. Le meme besoin, deux outils, et une limite qui vient de la donnee disponible plutot que du code.

Meme logique sur un autre projet : un site de livres d'occasion, techniquement tres simple a exploiter. Sur quatre cents titres verifies, aucun ne portait de code ISBN. Sans identifiant, aucune comparaison automatique fiable n'etait possible, et le programme n'a jamais ete ecrit. Le constat a ete fait avant, pas apres.

Quand un bot doit reperer un signal plutot qu'executer une tache, une erreur guette : constater qu'une regle a produit un bon resultat et en conclure qu'elle fonctionne. Un resultat ne prouve rien tant qu'il n'est pas compare a ce qu'aurait donne un tirage au hasard sur la meme periode.

Sur un projet de detection, six pistes ont ete testees, chacune contre un controle aleatoire respectant la structure des donnees.

Un resultat en dessous de 1 signifie que l'hypothese fait moins bien que le hasard. La seule qui semblait prometteuse a 1,29x s'est effondree une fois pris en compte le fait que des mesures consecutives ne sont pas des observations independantes : sa probabilite d'apparaitre par pur hasard etait de 18%, tres loin du seuil de 5% habituellement exige.

Conclusion livree telle quelle : aucune de ces pistes n'a ete integree. Une septieme, qui necessite de collecter des donnees non disponibles retroactivement, est en cours de mesure avec des criteres de decision fixes a l'avance plutot qu'apres avoir vu les resultats.

Une methode d'estimation avait ete construite pour anticiper des zones de tension sur un marche. Elle produisait des chiffres precis et convaincants. Le test retrospectif a montre qu'elle se declenchait a presque toutes les heures de la journee, y compris celles ou il ne s'est rien passe.

Elle a ete retiree des alertes principales et releguee a un canal de verification separe. Un indicateur qui sonne en permanence n'est pas seulement inutile : il noie les vrais signaux et rend l'ensemble du systeme inexploitable.

Une piste semblait indiquer que plusieurs dizaines de comptes appartenaient a une seule entite, sur la base d'une source de financement commune. En remontant la chaine jusqu'au bout, cette source s'est revelee etre un grand acteur du secteur par lequel des milliers de personnes passent chaque jour. La conclusion initiale etait fausse, et elle a ete corrigee avant d'etre publiee.

Le meme reflexe sert ailleurs. Sur le comparateur de prix, l'intuition disait que les plus gros ecarts concernaient les livres grand public. Une fois les cas reellement comptes, il s'est avere que la tres grande majorite etaient des manuels scolaires, universitaires ou medicaux. Les criteres ont ete reorientes en consequence, sur la base du comptage plutot que de l'impression de depart.

Un bot de surveillance envoyait une notification par evenement detecte. Probleme : une seule operation importante arrive parfois fragmentee en centaines d'evenements horodates a la meme seconde. Le resultat etait un mur de 247 notifications pour un fait unique.

La correction consiste a regrouper ce qui appartient au meme fait avant d'alerter, et a appliquer le seuil de declenchement au total reel plutot qu'a chaque fragment.

Un second defaut est apparu peu apres : un delai anti-repetition, declenche par une alerte mineure, avait masque l'alerte importante survenue quelques minutes plus tard. Corrige par une regle d'escalade qui laisse passer un evenement dont l'ampleur double par rapport au precedent. Ces deux corrections viennent d'observations en conditions reelles, pas de tests en laboratoire.

Le meme souci de justesse s'applique aux couts. Sur une automatisation qui publiait des fiches en masse, un plafond gratuit impose par la plateforme a ete depasse sans que personne s'en apercoive, et la facturation est tombee apres coup. Le plafond est desormais surveille et l'automatisation s'arrete avant de le franchir.

• Vous savez ce qui a ete verifie. Quand un bot vous est livre, les hypotheses qu'il applique ont ete testees, et je peux vous dire lesquelles ont ete ecartees en chemin.
• Vous n'heritez pas d'une fausse promesse. Si une idee ne tient pas apres test, je vous le dis plutot que de livrer quelque chose qui produit des chiffres rassurants sans fondement.
• Les alertes restent lisibles. Un systeme qui notifie trop finit par etre ignore, ce qui revient au meme que ne pas l'avoir.
• Ca continue de tourner. Les bots redemarrent seuls, journalisent leur activite, et les defauts qui apparaissent en usage reel sont corriges.