Quinze mois pour écrire le premier test. Il a trouvé un défaut que personne ne cherchait.

D’abord, ce qui a été fait correctement

Un MES est le logiciel qui pilote l’atelier. Il sait quel poste travaille sur quoi, ce qui sort d’une presse, ce qui part au traitement thermique, ce qui est rebuté. L’ERP, lui, ne le sait pas : il attend qu’on le lui dise. Chacun de ces faits a une conséquence en stock et une conséquence en comptabilité, donc le MES doit écrire dans l’ERP, en continu, pendant que l’atelier tourne.

La façon rapide de brancher les deux est de laisser le MES écrire directement dans les tables de Business Central, ou de lui fabriquer un point d’entrée sur mesure qui recopie la structure de ces tables. Ça marche le jour de la mise en service. Ça se casse à la première montée de version, et ça se casse en silence.

Sur ce projet, la toute première chose posée dans le dépôt, avant toute fonctionnalité, ce sont des pages API standard : ordres de fabrication, lignes de gamme, journaux article, sortie et consommation, avec un jeu de permissions dédié à ce seul usage. Pas de table exposée, pas d’endpoint maison.

La différence n’est pas cosmétique. Le MES ne parle plus à la base de données, il parle à un contrat. Quand une ligne est invalide, le contrat la refuse. Quand Business Central monte de version, deux fois par an, sur son propre calendrier, le contrat tient. C’est le sujet du guide développeur des API Business Central, et c’est aussi ce qui rend une mise à jour d’extension AL possible sans négocier avec l’intégrateur du MES.

C’est aussi vrai en amont de l’atelier, sur le chiffrage d’un devis de forge : les mêmes gammes, les mêmes postes, la même matière. Ce que le MES déclare en production, c’est ce que le devis avait promis.

Ensuite, quinze mois de « ça marche »

L’intégration est partie en production et y est restée. Elle faisait son travail. Personne ne remontait de problème. Il n’y avait pas un seul test automatisé dessus.

C’est l’état par défaut de la plupart des intégrations ERP en service aujourd’hui, et il est parfaitement confortable, parce qu’une intégration qui n’est pas testée ne vous dit rien. Elle ne vous dit pas qu’elle va bien. Elle ne vous dit pas non plus qu’elle va mal. Elle ne dit rien, et l’absence de plainte se lit comme une preuve.

Une app de test a fini par arriver dans le dépôt. Deux jours plus tard, un commit séparé porte un titre qui mérite d’être lu deux fois : faire tourner les tests AL pour de vrai dans la CI. Les tests existaient depuis deux jours et ne s’exécutaient pas. Écrit n’est pas exécuté, et un test qui ne tourne pas est un commentaire.

Ce que le premier test a trouvé n’était pas ce qu’on cherchait

Le défaut qu’on soupçonnait était bénin : on pensait qu’un enregistrement refusé répondait quand même « c’est bon » à l’appelant. Une mauvaise réponse, ennuyeuse, réparable.

Le test a montré autre chose. Le refus, lui, remontait bien. Mais le code qui prépare l’enregistrement attache un abonnement à un évènement, et il ne le détache qu’à la fin. Quand l’enregistrement échoue, cette fin n’est jamais atteinte. L’abonnement reste accroché à la session.

À partir de là, tout appel suivant échoue. Pas seulement les mauvais : les bons aussi. Un seul article bloqué par erreur dans le référentiel, et les trois API — journal article, sortie, consommation — refusent tout jusqu’à ce que la session soit renouvelée. Pour l’atelier, ça veut dire un MES qui ne déclare plus rien, sans erreur métier lisible, en plein milieu d’une production.

Ce défaut vivait là depuis quinze mois. Il ne s’était jamais manifesté parce qu’il faut un refus pour le réveiller, et que les refus sont rares. Il l’aurait fait le jour où un article aurait été bloqué au mauvais moment, et personne n’aurait fait le lien.

Ce que ça dit du reste

Deux choses, et la seconde est la plus inconfortable.

La première : le contrat a fait son travail. La ligne invalide a été refusée. Une intégration branchée en direct sur les tables l’aurait écrite, et le problème serait aujourd’hui dans vos stocks au lieu d’être dans un message d’erreur. Le défaut trouvé ici est un défaut de la couche de refus, pas du refus lui-même.

La seconde : quinze mois, c’est trop long, et le dépôt en garde la trace parce qu’on n’a pas réécrit l’histoire. Un test n’est pas une garantie de qualité, c’est un instrument de mesure. Tant qu’il n’y en a pas, vous ne savez pas dans quel état est votre intégration, et l’absence de panne n’est pas une information. Trois jours après avoir branché l’instrument, on avait la réponse.

Si vous avez une intégration que personne n’a testée

La question à poser n’est pas « est-ce qu’elle marche ». Elle marche, sinon vous le sauriez.

La question est : qu’est-ce qui se passe quand elle refuse quelque chose. Est-ce que le refus remonte à l’appelant. Est-ce que le système est dans le même état qu’avant. Est-ce que l’appel suivant fonctionne encore. Aucune de ces trois réponses ne s’obtient en regardant tourner l’intégration un jour normal, et les trois décident de ce qui arrive à votre atelier le jour anormal.

C’est exactement ce qu’on va chercher dans un bilan de clarté Business Central.