Prenons une PME de négoce. Un correctif livré le mardi soir casse la facturation le mercredi matin, parce que personne n'avait vérifié que ce qui marchait la veille marchait encore. Une suite de tests automatisés existe précisément pour empêcher ce scénario, et rien ne devrait partir en production sans elle. Reste à savoir ce que contient cette suite, pourquoi aucune mise à jour ne devrait s'en passer et comment vérifier que votre prestataire de maintenance applicative en a vraiment une.
Le correctif qui casse autre chose, la panne la plus fréquente en maintenance
Quand une application tombe en panne après des années de fonctionnement, la cause est rarement une défaillance spontanée. Le plus souvent, quelqu'un a modifié quelque chose. Un développeur a corrigé un bug d'affichage sur le module devis, et son changement a touché une fonction partagée avec le module commandes. Le module commandes n'a pas été retesté. Trois jours plus tard, une commande sur dix n'apparaît plus dans l'export comptable.
Ce mécanisme porte un nom, la régression. On corrige un point, on en dégrade un autre, et personne ne le voit avant que l'utilisateur ne le signale. Pour un dirigeant, c'est la panne la plus coûteuse, parce qu'elle arrive après une intervention qu'on croyait terminée et qu'elle entame la confiance dans toute la chaîne de maintenance. La question posée en comité de direction n'est plus « le bug est-il corrigé » mais « que va-t-on casser la prochaine fois ».
Une équipe qui livre sans tests automatisés ne peut pas répondre à cette question. Elle peut seulement promettre d'avoir fait attention.
Ce qu'est un test automatisé, expliqué sans code
Un test automatisé est un petit programme qui exerce une fonction de l'application et vérifie que le résultat est celui attendu. Il rejoue un scénario précis, par exemple « créer un devis à trois lignes avec une remise de 10 %, puis vérifier que le total TTC affiché est juste ». Si le total est bon, le test passe. Sinon, il échoue et signale exactement où.
Un test seul ne sert pas à grand-chose. Leur force vient du nombre et de la répétition. Une application de gestion bien couverte peut compter plusieurs centaines de ces scénarios. Ils s'exécutent tous en quelques minutes, à chaque modification du code, sans intervention humaine. Un testeur qui devrait vérifier les mêmes centaines de cas à la main y passerait des jours, et en oublierait forcément une partie.
On distingue habituellement trois niveaux. Les tests unitaires vérifient une fonction seule, comme le calcul d'une TVA. Les tests d'intégration vérifient que plusieurs briques travaillent ensemble, comme l'enregistrement d'une commande en base de données puis son envoi vers l'outil comptable. Les tests de bout en bout rejouent un parcours complet dans l'interface, comme un utilisateur qui se connecte, saisit une commande et la valide. Un dirigeant n'a pas besoin de connaître le détail de chaque niveau. Il a besoin de savoir que les trois existent et que les parcours qui font tourner son entreprise sont couverts.
Non-régression, la suite qui rejoue ce qui marchait hier
La suite de non-régression est l'ensemble de ces tests, exécuté avant chaque livraison. Son rôle est simple à formuler. Tout ce qui fonctionnait hier doit encore fonctionner aujourd'hui, une fois le nouveau correctif intégré. Si un seul test échoue, la livraison est bloquée et le développeur corrige avant que quoi que ce soit n'atteigne les utilisateurs.
Reprenons la PME de négoce du début. Avec une suite de non-régression, le correctif sur le module devis aurait déclenché l'exécution de tous les tests, y compris ceux du module commandes et de l'export comptable. Le test « une commande validée apparaît dans l'export du jour » aurait échoué. Le développeur aurait vu l'échec dix minutes après sa modification, pas trois jours plus tard sur remontée du service comptabilité.
C'est ce qui change la nature du travail de maintenance. Sans suite de non-régression, chaque intervention est un pari. Avec elle, chaque intervention est vérifiée contre l'ensemble du comportement connu de l'application. La confiance ne repose plus sur l'attention d'une personne un soir de livraison, mais sur un filet qui se tend systématiquement.
Pourquoi chaque incident traité doit devenir un test
Une suite de tests n'est jamais terminée. Elle s'enrichit, et la meilleure source d'enrichissement est la liste des incidents réels. Chaque bug corrigé en production révèle un cas que personne n'avait anticipé. Le réflexe attendu d'une équipe de maintenance sérieuse est d'écrire le test qui reproduit ce bug avant même de le corriger, puis de vérifier que le test passe une fois la correction faite.
Ce test reste ensuite dans la suite pour toujours. Le même bug ne pourra plus revenir sans être détecté. Prenons une ETI industrielle qui a vu le même défaut de calcul de délai de livraison réapparaître trois fois en deux ans, à chaque fois réintroduit par une modification voisine. Un seul test écrit au premier incident aurait suffi à empêcher les deux suivants.
Ce principe donne aussi un indicateur lisible pour un dirigeant. Si la suite de tests grossit au fil des incidents, la maintenance capitalise. Si elle stagne alors que les tickets s'accumulent, l'équipe corrige sans apprendre, et les mêmes problèmes reviendront.
Tests et remise à niveau, monter de version sans crainte
Le deuxième moment où les tests deviennent indispensables est la remise à niveau technique. Toute application repose sur des composants externes, un langage, une base de données, des bibliothèques, qui évoluent et finissent par ne plus être maintenus. Les mises à jour de sécurité sur des dépendances obsolètes sont l'un des chantiers les plus repoussés dans les PME, précisément parce qu'on craint de tout casser.
Cette crainte est fondée quand il n'y a pas de tests. Monter une bibliothèque de deux versions majeures peut changer des comportements subtils, un format de date, l'ordre d'un tri, une gestion d'erreur. Sans suite de non-régression, la seule façon de savoir ce qui a bougé est de laisser les utilisateurs le découvrir.
Avec une suite solide, la remise à niveau devient une opération encadrée. On monte la version, on lance les tests, on lit la liste des échecs, on corrige un par un, on relance. Le périmètre de ce qui a changé est connu avant la mise en production. C'est pour cette raison qu'une offre de maintenance supervisée qui inclut des tests automatisés avant chaque livraison peut s'engager sur des montées de version planifiées, là où une maintenance sans tests les évite jusqu'à ce qu'une faille de sécurité les impose dans l'urgence.
Le même raisonnement s'applique aux composants d'intelligence artificielle. Un modèle de langage change de version, un fournisseur annonce une dépréciation, et les réponses du système ne sont plus tout à fait les mêmes. Un jeu d'évaluation rejoué en production joue pour un système IA le rôle que la suite de non-régression joue pour le reste de l'application.
Les tests visuels : quand l'écran est faux alors que le calcul est juste
Un test fonctionnel peut passer alors que l'écran paraît cassé à l'utilisateur : des prix qui chevauchent une description, un logo à la mauvaise couleur, un bouton masqué. Les tests visuels comparent une capture de référence avec la nouvelle version. Les outils récents ignorent les contenus qui changent normalement, comme une bannière ou un nom affiché, et ne signalent que les écarts qui comptent, ce qui évite l'avalanche de fausses alertes d'une comparaison pixel par pixel.
Ce que l'IA apporte à l'écriture des tests
Rédiger des centaines de scénarios à la main est long. Des outils d'IA lisent le code et les parcours réels des utilisateurs pour proposer des tests, y compris sur des cas limites qu'un humain oublie. Le résultat reste à relire par un ingénieur : l'IA accélère l'écriture, elle ne décide pas de ce qui compte pour votre activité. C'est aussi ce qui rend raisonnable de bâtir un premier filet sur une application reprise sans aucun test.
Ce que coûte l'absence de tests, en reprises et en jalons bloqués
Le coût de l'absence de tests ne se lit pas sur une ligne de facture. Il se lit dans les reprises. Un correctif livré, cassé, relivré, recassé, c'est trois interventions facturées pour un seul problème. Dans une PME de services typique, une part importante des tickets de maintenance d'un trimestre correspond en réalité à des retours sur des livraisons précédentes.
Les jalons glissent aussi. Une évolution attendue par le service commercial est prête, mais personne n'ose la mettre en production un vendredi parce qu'on ne sait pas ce qu'elle va toucher. On attend le lundi, puis la semaine suivante, puis on la couple avec une autre évolution pour limiter le nombre de mises en production, et le lot devient si gros que le risque augmente encore. Les équipes métier apprennent à ne plus rien demander.
Reste la dépendance à une seule personne. Sans tests, seule la personne qui connaît l'application par cœur peut y toucher sans trop de risque. Si elle part, ou si le prestataire ne répond plus, le repreneur avance à l'aveugle. La suite de tests est une partie de la documentation vivante de l'application, celle qui dit ce que le système est censé faire et qui le vérifie à chaque fois.
Comment un dirigeant vérifie que les tests existent vraiment
Un prestataire qui affirme faire des tests n'est pas forcément un prestataire qui en a. Quelques questions permettent de le savoir sans lire une ligne de code.
Demandez d'abord à voir le rapport d'exécution de la dernière livraison. Une équipe qui a une suite de non-régression peut montrer, pour chaque livraison, la liste des tests exécutés, leur durée et leur résultat. Si la réponse est « on teste à la main », vous avez votre réponse.
Demandez ensuite combien de tests existent et depuis quand le chiffre évolue. Un nombre stable depuis un an sur une application qui reçoit des correctifs chaque mois signifie que les incidents ne sont pas transformés en tests.
Demandez enfin si la livraison peut partir quand un test échoue. La bonne réponse est non, la livraison est bloquée tant que la suite ne passe pas intégralement. Si les échecs peuvent être ignorés au cas par cas, ils finissent par l'être tous.
Ces trois questions tiennent en un quart d'heure de réunion et disent l'essentiel sur la qualité de la maintenance que vous achetez. Elles font partie de ce qu'une PME doit exiger de son prestataire, et ont leur place dans tout audit de reprise avant de changer de prestataire.
Le cas des applications reprises sans aucun test
La situation la plus courante en reprise de maintenance est une application qui tourne depuis cinq ou dix ans sans un seul test automatisé. L'ancien prestataire connaissait tout de tête, il est parti, et le code arrive avec une documentation partielle et une liste de bugs ouverts.
Il ne faut pas chercher à tout couvrir d'un coup. Écrire des centaines de tests sur une application qu'on ne connaît pas encore prend des mois et sert souvent à peu de chose, parce qu'une partie de ce code ne sert plus. La bonne approche démarre par une cartographie. Quels sont les parcours qui font tourner l'entreprise, la prise de commande, la facturation, l'export vers la comptabilité, la synchronisation avec l'entrepôt. Ces cinq ou dix parcours reçoivent en priorité des tests de bout en bout, qui photographient le comportement actuel, même s'il comporte des défauts connus.
Ce premier filet permet d'intervenir sur l'application sans casser ce qui compte. Ensuite, chaque incident traité ajoute son test, chaque module touché reçoit sa couverture au moment où on y travaille. En quelques mois, une application reprise sans aucun test dispose d'une suite qui couvre l'essentiel de ce qui fait sa valeur. C'est une affaire de discipline, qui se voit dans le rapport d'activité bien plus que dans une présentation commerciale.
La suite de tests est ce qui sépare une maintenance qui répare d'une maintenance qui fait progresser un système, et c'est aussi le socle de ce qu'il faut surveiller après la mise en production d'une IA. La première vous ramène à l'état d'hier. La seconde vous permet de changer sans peur de perdre ce qui fonctionne.
