Chronique d’une erreur ordinaire…

Il est un problème systémique, une faille dans l’architecture organisationnelle de nombreuses DSI françaises, celle d’ignorer la phase de test… de ne pas donner d’importance à cette validation et vérification obligatoire et celle de confier les tests à des profils qui n’en ont ni les compétences, ni les outils, ni la posture. Dans cette série d’articles nous allons détailler le troisième point « confier les tests à des profils qui n’en ont ni les compétences, ni les outils, ni la posture ».

Chefs de projet, Product Owners, Scrum Masters, voire développeurs des équipes métiers, eux-mêmes sont régulièrement propulsés en première ligne de la qualité logicielle sans plan de test, sans politique de test, sans stratégie, sans recul, sans formation, sans process de qualité.

Cette pratique vieille repose sur une croyance tenace : “on peut tester sans testeur”. On l’entend encore dans des comités projet en 2025 : “le dev a bien validé sa fonctionnalité”, “le PO a fait une démo, c’est bon”, “on n’a pas le budget pour une QA dédiée”. Résultat ? Des modules RH qui ne gèrent pas les cas à temps partiel, des applications e-commerce qui plantent au moment du paiement, des outils CRM qui se figent sur un simple filtre multicritère, ou des applications et des sites web attaqués et des données des utilisateurs volés.

Le prix des tests sacrifiés

Ce n’est pas une théorie, c’est la réalité de centaines de projets en France. Et c’est cette réalité que cet article veut démonter, couche après couche, comme on audite une stack trop silencieuse. Parce qu’un test manqué, ce n’est pas un oubli, c’est une dette. Et une dette qualité, comme une base de données corrompue, finit toujours par faire tomber le système.

Cette mauvaise pratique ne date pas d’hier. En France, elle est intimement liée à une culture projet marquée par le forfait, la livraison au sprint final, et le culte du “ça doit passer”. Le test y est souvent considéré comme une tâche accessoire, compressible à merci, reléguée aux derniers jours avant la mise en production. Et parfois même… après.

On trouve encore aujourd’hui des portails clients livrés sans tests de charge, des ERP modifiés sans jeux de données métiers, des applications mobiles testées uniquement sur l’émulateur local. Et tout cela est justifié par un “on n’a pas eu le temps” ou “le client n’a pas demandé”.

Beaucoup préfèrent croiser les doigts plutôt que structurer un plan de validation. On déploie sur la branche principale, on rollbacke en panique, on ouvre un ticket de crise. Et pendant ce temps, le client se demande s’il peut vraiment faire confiance.

Une illusion de contrôle

Quand on confie les tests à ceux qui ne sont ni formés, ni mandatés, ni neutres, on ne teste pas. On valide superficiellement. Et dans le monde logiciel, cette nuance fait toute la différence.

Le développeur, aussi rigoureux soit-il, est concentré sur l’implémentation. Son test est confirmatif : il vérifie que ce qu’il a codé se comporte comme prévu dans les cas standards. Mais qui va simuler un token expiré, un appel API avec des accents, un navigateur obsolète, ou une résolution mobile ultra-compressée ? Ce ne sont pas des scénarios « naturels » pour le développeur c’est du métier de testeur.

Le Product Owner, lui, vérifie que la fonctionnalité colle aux besoins du métier. Mais dans la majorité des cas, il teste via l’interface, en mode clic rapide, sans plan formel, sans outillage, sans couverture. Il est focalisé sur la valeur business livrée  pas sur la robustesse transversale. Or un import Excel qui échoue sur 2 000 lignes au lieu de 500, ça ne fait pas partie de sa check-list.

Quant au Scrum Master, il pilote les cérémonies, la synchronisation, les obstacles. Il n’a ni la casquette QA, ni les moyens techniques, ni le temps d’évaluer le code, la sécurité, ou la non-régression. Lui demander cela, c’est comme confier à un agent de sécurité la garde de votre maison… tout en lui demandant d’aller faire vos courses. Qui protégera la maison pendant qu’il est parti ?

Et pourtant, dans des dizaines d’équipes, c’est ainsi qu’on opère. Le test devient une “to-do” sur la Definition of Done. On clique vite fait, on coche la case, et on passe en production. Jusqu’à ce qu’un utilisateur déclenche une cascade d’erreurs avec une saisie imprévue, un environnement non couvert ou un simple refresh mal géré.

Les conséquences, en cascade

Les impacts sont massifs, mais trop souvent invisibles… jusqu’au jour où tout s’effondre.
Prenons un exemple concret : un module de facturation intégré à un ERP maison. Une modification du format des montants passée sans test QA provoque un bug sur l’export PDF. Résultat : des milliers des factures rejetées par les clients grands comptes. Deux semaines de bugfix, une cellule de crise, et un contrat menacé.
Autre cas : une app mobile de service public. L’absence de test multi-device conduit à un crash systématique sur les versions Android. Les usagers souvent peu technophiles abandonnent, ou pire, font remonter des réclamations officielles. Et le pire dans tout ça ? Les équipes internes s’épuisent. Les développeurs sont sollicités en support, les PO sont sous pression, la roadmap est gelée pour prioriser le correctif. L’équipe produit perd en crédibilité. Et l’entreprise, en image.
Cette négligence QA, ce n’est pas juste du “technique”. C’est un risque business, un facteur d’insatisfaction client, une cause de désengagement RH. Chaque bug passé en production, c’est un backlog qui s’alourdit, un client qui doute, un KPI de vélocité qui s’effondre.

Un mal qui se répète, version après version

Ce qui est frappant, c’est la persistance de ce problème organisationnel. Il se réplique d’un sprint à l’autre, comme un défaut jamais corrigé dans la base de code. Le test improvisé, délégué ou oublié devient une habitude, un “pattern” de delivery. Même quand les incidents s’accumulent, même après des post-mortems explicites, les mêmes décisions se répètent. Comme si le backlog des leçons apprises n’était jamais priorisé.
Chaque nouveau projet repart sans QA dédié. Chaque refonte d’interface oublie les tests d’accessibilité. Chaque évolution d’API passe sans campagne de non-régression. Le syndrome du “cette fois ça ira” est devenu chronique. Sauf que non, ça ne va jamais vraiment.
Et pourtant, des alertes sont là. Des dashboards Jira qui explosent en anomalies bloquantes post-livraison. Des campagnes UAT qui virent au chaos à deux jours de la prod. Des utilisateurs métier qui remontent eux-mêmes les bugs via Excel ou email parce que la validation a été faite “en confiance”.
Mais la pression du delivery est plus forte. Le client attend. Le sprint est fini. Le PO veut son incrément. Alors on déploie quand même. Et on corrige après. C’est ainsi qu’on transforme un incident évitable en dette technique et un produit prometteur en usine à patchs.

Les testeurs existent, et ils font bien plus que tester

Et pourtant, au cœur de ce schéma, il existe une compétence sous-utilisée, parfois ignorée : le testeur. Le vrai. Celui qui pense en matrices de couverture, en critères de validation, en jeux de données bordures. Celui qui automatise, qui challenge les specs, qui simule les pires cas avec méthode.

Un bon QA n’attend pas que le bug surgisse. Il le provoque dans un environnement sécurisé. Il détecte le champ sans contrainte de longueur, le script JS mal échappé, l’intégration avec un service tiers non mocké. Il ne valide pas juste “ce que ça fait”, il vérifie ce que ça ne doit surtout pas faire.

Quant à l’ingénieur QA, il agit en stratège. Il pilote des KPI comme le taux de réussite, la couverture fonctionnelle, la densité d’anomalies. Il trace la traçabilité. Il intègre la QA au pipeline CI/CD. Il transforme un sprint en un livrable durable.

On les appelle parfois “empêcheurs de livrer en rond”. C’est faux. Ce sont les garants que ce qu’on livre tient la route. Et il est temps qu’ils retrouvent leur place, non pas à la fin du cycle, mais au cœur du projet.

Et maintenant ?

Sacrifier les tests et oublier l’ingénieur qualité, c’est accepter une dette qui finit toujours par se payer, tôt ou tard et souvent très cher. Cette spirale n’est pas une fatalité. Il existe des pratiques, des postures et des outils qui transforment la qualité logicielle en levier de confiance, de sérénité et même de performance business. C’est ce que nous verrons dans la deuxième partie de cette chronique !