Construire un assistant qui n'a pas le droit de se tromper
Dantokpa, un cadenas, deux amis qui ne comptent pas pareil et un groupe électrogène : l'architecture d'un assistant fiable, expliquée sans jargon.
Au marché, personne n'aime celui qui invente
Tu arrives à Dantokpa, tu cherches un vendeur précis. Tu demandes ton chemin. Deux réponses possibles.
La première : « va tout droit, tourne à gauche après les bassines ». Tu marches vingt minutes. Ce n'était pas là. La personne ne savait pas, mais elle a préféré dire quelque chose plutôt que rien.
La deuxième : « je ne sais pas, demande à la dame là-bas ». Tu perds dix secondes. Tu trouves.
La deuxième réponse vaut mieux que la première. C'est toute la différence entre un assistant utile et un assistant dangereux — et c'est la phrase qui a décidé de toute l'architecture qui suit.
Maintenant remplace le marché par une mutuelle de santé, et la direction par un taux de remboursement. Se tromper ne fait plus marcher quelqu'un vingt minutes pour rien : ça devient un litige. C'est ce genre d'assistant que je construis, et cette phrase a décidé de toute son architecture.
Je ne peux pas nommer le projet réel : le décor est déplacé, les décisions techniques sont exactement celles que j'ai prises.
La consigne qu'on oublie, le cadenas qu'on ne contourne pas
Tu peux dire à tes enfants : « ne sortez pas sans prévenir ». C'est une consigne. Elle tient tant que tout le monde s'en souvient.
Ou tu peux mettre un cadenas au portail. Là, la question ne se pose plus.
Le programme qui répond aux adhérents, c'est la consigne. La base de données, c'est le cadenas. Et j'ai mis la règle dans le cadenas.
Concrètement, la base refuse physiquement d'enregistrer une réponse publiée sans trois choses : le document d'où elle vient, la date où on l'a vérifiée, et le niveau de confiance. Ce n'est pas un test qu'un développeur pourrait oublier de lancer. C'est un mur.
Deuxième cadenas : une réponse publiée ne se modifie plus. Jamais. Si l'information change, on en publie une nouvelle et on retire l'ancienne — mais l'ancienne reste, datée.
Pourquoi tant de rigidité ? Parce que si un adhérent conteste en octobre une réponse reçue en mars, il faut pouvoir montrer exactement ce que le système disait en mars. Une ligne qu'on peut retoucher rend cette preuve impossible.
Un développeur dirait : « les invariants sont dans le schéma, pas dans l'application ». C'est la même chose, dit en jargon.
Chercher une adresse à Cotonou
À Cotonou, personne ne cherche par le nom de la rue. On dit : « c'est après le carrefour, à côté de la pharmacie, en face du maquis bleu ».
Ce sont deux façons de chercher, et elles ne trouvent pas les mêmes choses.
Par le nom exact. Si tu connais le nom, tu tombes dessus directement. Si tu te trompes d'une lettre, tu ne trouves rien.
Par les repères. Tu décris ce qu'il y a autour. Ça marche même si tu ignores le nom — mais tu peux tomber sur la pharmacie d'à côté, qui ressemble beaucoup.
Un adhérent écrit « lunettes ». Le contrat, lui, dit « équipements d'optique médicale ». La recherche par le nom exact ne trouve rien. Il écrit « je viens d'accoucher » ; le contrat dit « prestation maternité ». Là encore, aucun mot commun.
Alors on garde les deux méthodes en parallèle. L'une cherche les mots exacts, l'autre cherche le sens. Chacune rattrape ce que l'autre rate.
Le nom technique de la seconde, c'est la recherche « vectorielle » : on transforme chaque phrase en une suite de nombres qui représentent son sens, et on compare les nombres. Deux phrases qui veulent dire la même chose se retrouvent proches, même sans un seul mot commun.
Kossi compte les fois, Fifamè note sur dix
On a donc deux moteurs qui répondent chacun de leur côté. Reste à les mettre d'accord. Et c'est là que ça se complique.
Prends une situation ordinaire : tu cherches un bon maquis, tu demandes à deux amis.
Kossi te dit combien de fois il y a mangé. Ça peut monter à quarante-sept. Fifamè, elle, note sur dix.
Si tu additionnes leurs chiffres, tu ne fais plus confiance qu'à Kossi. Ses quarante-sept écrasent une note qui ne dépassera jamais dix — même quand Fifamè a mis deux sur dix à l'adresse qu'il adore.
La solution tient en une phrase : on n'additionne pas leurs chiffres, on additionne leurs classements. Premier, deuxième, troisième. Là, la façon de compter de chacun n'a plus d'importance, et c'est l'adresse que les deux placent bien qui gagne.
La fusion par rang réciproque, une méthode simple pour combiner les classements de plusieurs systèmes, donne systématiquement de meilleurs résultats que n'importe quel système pris isolément.
Cormack, Clarke & Büttcher — SIGIR 2009 ↗
Les deux moteurs de recherche ont exactement ce problème. L'un rend des scores sans limite haute, l'autre des scores entre zéro et un. On compare donc les places, pas les notes. Ça porte un nom savant — la fusion par rang réciproque — pour une idée que tout le monde applique déjà sans le savoir.
Savoir dire « je ne sais pas »
On fixe un niveau minimum. En dessous, l'assistant ne répond pas : il passe la main à un conseiller.
C'est le zémidjan qui te dit « je ne connais pas ce quartier, prends celui-là il y va tous les jours » plutôt que de tourner une heure avec toi sur le compteur.
Une erreur que j'ai failli commettre : appliquer ce seuil après avoir mélangé les deux moteurs. Ça n'a aucun sens — une fois mélangé, le chiffre obtenu ne mesure plus rien de réel. Le seuil s'applique à chaque moteur séparément, avant le mélange, tant que ses chiffres veulent encore dire quelque chose.
Et on compte les fois où l'assistant se tait. Si ce nombre grimpe, ce n'est pas qu'il fonctionne mal : c'est qu'on lui pose des questions dont la réponse n'a pas encore été écrite. Ce compteur dit quoi rédiger ensuite.
Le virement passé, le message perdu
Tu envoies de l'argent à quelqu'un par Mobile Money. Puis tu l'appelles pour le prévenir. Deux gestes.
Si l'argent part mais que l'appel ne passe pas, la personne ne sait pas qu'elle a reçu. Si tu appelles mais que le transfert échoue, elle attend pour rien. Deux gestes, c'est deux occasions de rater.
Le système a le même souci. Quand une réponse est publiée, il faut l'enregistrer *et* prévenir les autres parties du système. Deux opérations. Deux façons d'échouer à moitié.
La parade est simple une fois qu'on la voit : on écrit le message à envoyer dans la base, en même temps que la donnée, d'un seul geste. Un petit programme passe ensuite ramasser les messages et les distribuer.
Soit les deux réussissent, soit aucun. Le demi-échec disparaît. Les développeurs appellent ça la « boîte d'envoi » — l'*outbox*.
Le service qui envoie le message commence par le stocker en base dans la transaction qui met à jour les données ; un processus séparé publie ensuite les messages.
Chris Richardson — Pattern: Transactional outbox ↗
Trois tricycles ou un camion-remorque ?
Tu dois livrer vingt sacs de riz par jour dans Cotonou.
Le camion-remorque transporte tout d'un coup. Mais il te faut un chauffeur poids lourd, un garage qui sait le réparer, une place pour le garer, et il ne passe pas dans les petites rues.
Trois tricycles font le même travail. Tu les répares toi-même, ils passent partout, et si l'un tombe en panne les deux autres continuent.
C'est exactement le choix entre les deux outils qui font tourner ce genre de système. Le premier — Kubernetes — est le camion : très puissant, utilisé par les géants du web, et qui demande une équipe pour s'en occuper. Le second — Docker Swarm — c'est les tricycles.
Pour trois ou quatre machines et une douzaine de programmes, le camion devient un projet à lui tout seul. J'ai pris les tricycles.
Ce que ça donne concrètement : les programmes sont répartis sur les machines selon leur rôle, les mots de passe ne traînent jamais dans des fichiers de configuration, et les échanges entre machines sont chiffrés. Tout ça sans qu'une personne seule y perde son week-end.
Le jour où le volume dépassera ce cadre, la question se reposera. Pas avant. On choisit l'outil à la taille du problème, pas à la taille de son CV.
Le groupe électrogène qu'on démarre avant la coupure
La SBEE coupe. Tu vas démarrer le groupe.
Si tu attends la coupure pour le lancer, tu as deux minutes de noir. Le frigo s'arrête, l'ordinateur redémarre, la connexion tombe.
Si le groupe tourne déjà quand tu bascules, personne ne remarque rien.
Mettre à jour un programme en service, c'est la même chose. La mauvaise méthode arrête l'ancienne version puis lance la nouvelle — et entre les deux, plus personne ne répond. La bonne méthode démarre la nouvelle d'abord, vérifie qu'elle fonctionne, et seulement ensuite éteint l'ancienne.
Et si la nouvelle version ne va pas ? Le système revient tout seul à la précédente. Pas une procédure écrite dans un document que personne ne relit à trois heures du matin : un retour en arrière automatique.
Le gardien qui note « rien à signaler »
Un gardien peut écrire « tout va bien » toute la nuit. Ça ne dit pas si le portail était fermé.
C'est le piège de la surveillance informatique. On mesure la mémoire, le processeur, la vitesse. Tous ces chiffres peuvent être au vert pendant que le système raconte n'importe quoi aux adhérents.
Alors l'alerte la plus importante de tout ce système ne surveille aucune machine. Elle compte les réponses envoyées sans document source. Sa valeur normale est zéro. Au premier écart, alerte immédiate — parce qu'une promesse vient d'être rompue.
À côté, on suit le nombre de fois où l'assistant s'est tu, le temps de réponse, et les demandes transmises à un conseiller qui traînent depuis deux jours. Chaque alerte correspond à une promesse faite à quelqu'un.
Dernier point, et il compte : les traces d'activité sont nettoyées des données personnelles avant d'être enregistrées, pas après. Nettoyer après, c'est n'avoir rien nettoyé.
Ce que je referais autrement
Trois choses, en toute honnêteté.
J'ai passé trop de temps à régler des détails avant d'avoir de quoi mesurer si mes réglages amélioraient quelque chose. Sans mesure, on optimise à l'aveugle et on appelle ça de l'intuition.
Le seuil du « je ne sais pas » aurait dû être réglable question par question dès le départ. Se tromper sur un horaire d'accueil et se tromper sur un taux de remboursement, ce n'est pas la même faute.
Et j'aurais installé la surveillance dès le premier jour, pas le trentième. Les trois premières semaines d'un système en service sont celles où il t'apprend le plus — je les ai regardées à travers une vitre sale.
Ce qu'il faut retenir
Aucune de ces décisions n'est spectaculaire. Aucune n'utilise la technologie la plus récente. Elles ont un point commun : elles répondent toutes à la même phrase, posée avant d'écrire la première ligne de code.
Une architecture, ce n'est pas un empilement de bons choix techniques. C'est une contrainte tenue jusqu'au bout, y compris là où c'est pénible — dans la base de données, dans les alertes, dans la façon de mettre à jour.
Si tu construis quelque chose qui n'a pas le droit de se tromper, la vraie question n'est pas « quelle technologie ? ». C'est : qu'est-ce que ce système n'a jamais le droit de faire — et qui l'en empêche quand tout le monde a oublié la règle ?
