Un écosystème qui bouge vite
Le protocole évolue, les clients aussi, et les serveurs de la communauté suivent à des rythmes différents. Une configuration qui marchait il y a trois mois peut cesser de fonctionner sans que vous ayez rien touché.
Ce n'est pas une critique : c'est l'état normal d'une technologie récente. Cela impose seulement quelques habitudes que l'on prend ailleurs et que l'on oublie ici.
Épingler les versions
La règle la plus rentable : ne jamais dépendre d'une version « dernière » en production.
Un serveur récupéré à chaque démarrage dans sa version la plus récente introduit un changement que personne n'a décidé, au pire moment. Fixez une version précise, testez la nouvelle avant de l'adopter, et notez la date de la dernière mise à jour.
Cela vaut aussi pour les serveurs que vous écrivez : vos dépendances méritent le même traitement.
Ce qui casse en pratique
Le renommage d'un outil. Les demandes enregistrées et les habitudes des utilisateurs cessent de fonctionner. Si vous devez renommer, gardez l'ancien nom en alias pendant une période, comme on le ferait pour une route d'API.
Le changement de schéma d'un paramètre. Un paramètre devenu obligatoire fait échouer tous les appels antérieurs. Ajoutez plutôt un paramètre facultatif avec une valeur par défaut.
Le changement de forme du résultat. Moins visible, plus insidieux : le modèle continue d'appeler, obtient autre chose, et raisonne dessus sans signaler de problème.
Ces trois cas sont exactement ceux d'une interface de programmation classique, et les mêmes règles de compatibilité s'appliquent.
Suivre l'usage
Trois mesures suffisent, et elles se lisent en cinq minutes par mois :
- quels outils sont appelés, et lesquels ne le sont jamais
- le taux d'échec par outil
- le temps d'exécution
Le premier chiffre est le plus instructif. Un outil jamais appelé est soit inutile, soit mal décrit, et dans les deux cas il occupe de la place dans le choix du modèle. Le supprimer améliore la sélection des autres.
Un taux d'échec élevé sur un seul outil désigne presque toujours une description ambiguë : le modèle l'appelle avec de mauvais arguments parce qu'il a mal compris ce qu'il attendait.
Décider si un serveur mérite d'être maintenu
Trois questions, une fois par trimestre.
Ses outils sont-ils utilisés ? Le fait-il mieux qu'une intégration directe devenue disponible depuis ? Quelqu'un saurait-il le reprendre si son auteur partait ?
La dernière question est celle qu'on oublie. Un serveur écrit par une personne, non documenté, qui expose un système critique, est une dette qui ne se voit pas tant que cette personne est là.
À retenir
Épinglez les versions, testez avant d'adopter. Renommer un outil ou rendre un paramètre obligatoire casse les usages existants : traitez votre serveur comme une interface publique. Suivez les appels, supprimez les outils jamais utilisés, et vérifiez que quelqu'un d'autre pourrait reprendre le vôtre.