Sections de l'article
Le même incident revient : un restaurateur ou un gérant de magasin appelle, tout excité. « Ça a marché parfaitement en démo. J’ai cliqué, le stock s’est synchronisé, la facture est partie, tout était instantané. » Il signe le contrat, installe le système en production. Le lendemain, c’est le client qui appelle. « Ça ne marche plus. Il envoie des factures en double, perd des données, et les clients appellent pour savoir où est leur argent. »
Le problème vient surtout de nos tests, pas du client. On vérifie le chemin idéal, pas le chemin qu’emprunte un système quand les choses déraillent : avec des données incomplètes, des requêtes simultanées et un réseau qui ralentit au moment le plus critique.
La démo est une cuisine vide
En production, un automatisme échoue souvent parce que les tests ne couvrent pas les données anciennes, les caractères inattendus, les commandes incomplètes, la latence et les accès concurrents. Une démo ne reproduit généralement aucune de ces conditions : la base contient des données propres, le réseau est local et aucun autre processus ne sollicite le serveur.
C’est comme si vous démontriez un nouveau four dans une cuisine vide, avec une seule poêle et une seule pomme de terre. Ça marche impeccablement. Ensuite, vous l’installez dans une vraie cuisine, avec dix cuisiniers, de l’huile qui éclabousse, des commandes qui arrivent en même temps et le frigo ouvert cent fois par jour. Le four n’a pas changé, mais l’environnement, lui, est beaucoup plus contraignant.
En production, l’automatisme échoue dès que ses concepteurs n’ont pas prévu les interactions entre utilisateurs et systèmes. Le code ne gère que le fonctionnement normal. Sans règle pour gérer les données manquantes ou les requêtes simultanées, le système s’arrête.
Erreurs que personne n’a prévues
En production, les erreurs surviennent quand l’automatisme rencontre des données ou des dépendances inattendues sans savoir quoi en faire. En démo, l’utilisateur saisit des données correctes, les champs sont complets et le serveur répond rapidement. En production, un serveur met un espace en trop dans un nom, un fournisseur envoie un fichier avec une colonne manquante ou une connexion réseau tombe exactement quand l’automatisme attend une réponse. L’instruction fonctionne, mais le système ne sait pas quoi faire quand cela arrive.
Un automatisme qui, en démo, lisait quelques enregistrements reçoit en production des milliers, certains avec des champs vides, d’autres avec des données vieilles de plusieurs années. Le blocage ne vient pas de la vitesse : le code ne savait pas traiter une valeur manquante. Il plantait.
Si vous ne testez que le fonctionnement normal, les échecs apparaîtront en production, souvent quand le gérant est en congé et que le remplaçant ne saura pas quoi faire d’un message d’erreur incompréhensible.
Les ressources ne sont pas infinies
La démo tourne généralement sur un ordinateur portable ou un serveur dédié, avec une seule connexion à la base de données. En production, le même automatisme rivalise avec d’autres applications pour la mémoire, le temps processeur et la bande passante réseau. Si vous n’avez pas prévu de limites d’attente, de reprises après échec ou d’espace de travail pour les écritures simultanées, le système ne tient plus la charge.
C’est comme avoir un seul évier dans une cuisine de restaurant. En démo, vous lavez un verre. En production, dix serveurs apportent des assiettes en même temps. Les assiettes s’accumulent et le service ralentit.
La différence en bref
| Démo | Production |
|---|---|
| Données propres, peu nombreuses, prévisibles | Données sales, nombreuses, imprévisibles |
| Aucune concurrence | Des dizaines de processus simultanés |
| Réseau local, latence zéro | Réseau réel, délais, pertes de connexion |
| Ressources apparemment illimitées | Ressources limitées, partagées |
| Un seul état possible | Des centaines d’états : erreurs, doublons, données partielles ou vides |
| Testé par l’ingénieur qui l’a écrit | Utilisé par des gens qui ne savent pas comment ça marche |
Comment changer le résultat
Listez d’abord les risques : où le processus peut-il échouer ? Que faites-vous si le fichier est vide ? Si la base de données répond par une erreur ? Si l’utilisateur ferme le programme au milieu du processus ?
Testez ces cas avant d’écrire le code principal, plutôt que d’attendre une erreur en production. En démo, montrez comment le système fonctionne, s’arrête, reprend après une erreur et préserve les informations.
Les patrons et les gérants n’ont pas besoin de connaître les timeouts ou les mécanismes de reprise. Ils doivent savoir demander, avant de signer, un plan de tests pour les cas d’échec. Demandez simplement : « Que faites-vous si le serveur ne répond pas ? Que faites-vous si l’employé se trompe dans les données ? » S’il reste vague, faites-lui préciser ces points.
Avant d’accepter un automatisme, exigez des tests sur les fichiers vides, les timeouts, les doublons et les arrêts en milieu de processus. Si le fournisseur ne peut pas montrer comment le système se rétablit après chaque incident, ne considérez pas la démo comme une preuve de robustesse.