Comment saurons-nous qu'il fonctionne encore après la mise en production ?

Ce qui change après la mise en production

Trois choses bougent toutes seules. Le fournisseur met à jour le modèle, parfois sans changer de version, et les réponses changent de ton ou de longueur. Vos données dérivent : nouveaux produits, nouvelles politiques, documents qui en contredisent de plus anciens. Et vos utilisateurs apprennent ce que le système sait faire et se mettent à demander des choses que le jeu d'évaluation n'avait jamais imaginées.

Aucune de ces choses ne s'annonce. Le système continue de répondre, avec assurance, et le premier signe de problème est en général un client ou un collègue qui le remarque. Un système en production a besoin de quelque chose qui le surveille et qui ne soit pas une personne lisant chaque réponse.

Des règles qui vérifient chaque réponse

Avant d'être affichée, une réponse passe une série de contrôles écrits pendant la construction. Certains sont simples : la réponse cite un document source, elle ne contient pas de prix sauf s'il vient du catalogue, elle ne promet pas de date. D'autres sont un second modèle à qui l'on pose une question étroite sur la réponse du premier. Une réponse qui échoue n'est pas affichée. L'utilisateur reçoit une réponse de repli, et l'échec est journalisé.

Ces contrôles sont la raison pour laquelle le petit modèle de la note précédente est sûr à utiliser. Ils produisent aussi le chiffre le plus utile de tout le système : à quelle fréquence des réponses sont bloquées, et pour quelle raison. Quand ce chiffre bouge, quelque chose a changé en amont.

Un échantillon hebdomadaire, noté

Chaque semaine, un échantillon de requêtes réelles et de leurs réponses est tiré des journaux et noté contre votre jeu d'évaluation, avec les critères que votre équipe a écrits avant la mise en production. Les cas nouveaux de l'échantillon que le jeu ne couvrait pas y sont ajoutés, pour que le jeu grandisse avec l'usage réel plutôt qu'avec nos suppositions.

La note est une tendance, pas un verdict. Une mauvaise semaine après une mise à jour du fournisseur est un signal pour regarder. Trois semaines en baisse sont un signal pour agir. Comme le même jeu tourne depuis le prototype, la tendance est comparable sur toute la vie du système.

Des alertes pour ce qui ne peut pas attendre

Certains changements ne doivent pas attendre l'échantillon hebdomadaire. Le coût par requête qui monte, la latence qui dépasse la limite que votre produit tolère, le taux de blocage qui bondit, la recherche qui ne renvoie rien pour une classe de questions. Ils déclenchent des alertes dans votre cloud, vers vos canaux, avec une ligne dans le manuel qui dit quoi vérifier en premier.

Les alertes sont réglées pour être rares. Une alerte qui sonne tous les jours est ignorée dès la deuxième semaine, et celle qui compte l'est alors aussi.

Le rapport mensuel

Une page, en langage clair, pour la personne responsable du système qui ne lit pas les journaux. La tendance des notes hebdomadaires. Ce qui a été bloqué et pourquoi. Les incidents, leur cause et ce qui a changé en conséquence. Le coût. Ce que nous recommandons de changer le mois prochain, et ce que nous recommandons de laisser tel quel.

Il est écrit pour pouvoir être transmis à un directeur sans un appel pour l'expliquer. S'il a besoin d'un appel, il n'est pas fini.

Le nôtre ou non

Cette routine ne dépend pas de qui a construit le système. Une équipe avec un assistant qui fonctionne aujourd'hui et personne pour le surveiller demain peut commencer ici : un audit de ce qui existe, un jeu d'évaluation écrit avec l'équipe s'il n'y en a pas, une supervision dans son cloud, et un premier rapport un mois plus tard.