Les spécialistes du test dans le monde de demain : Christophe Moustier

Bonjour, peux-tu rapidement te présenter ?

Je suis Christophe Moustier :

• Développeur depuis 1982
• Premiers pas dans l’IA en 1995 avec la conception d’un réseau de neurones basé sur des fonctions radiales pour la détection de défaillances dans des systèmes hydrauliques
• « Agiliste » depuis 1999
• « Testeur » depuis 2006
• « Qualiticien » depuis 2008
• Mentor testing depuis 2017
• Mentor Software Craftsmanship depuis 2018
• Auteur des livres « Le test en mode agile » + « Conduite de tests agiles pour SAFe et LeSS » et d’autres ouvrages collaboratifs du CFTL

Qu’est-ce qui t’a amené à travailler dans le domaine du test et de la qualité ?

En 1999, j’ai dû organiser le travail de 30 personnes, j’ai eu dans mon équipe une qualiticienne câblée ISO9001 qui m’a ouvert des portes.

En 2003, l’offshore montait en pleine puissance et mes réflexions ont orienté ma stratégie professionnelle vers le domaine fonctionnel, dont le test, car les décisions et les budgets étaient difficilement délocalisables.

Dans ce contexte, j’ai rencontré un expert du test fonctionnel qui a commencé à me donner les bases telles que le « Risk-Based Testing » et la notion de « couloir de test ». De là, un partenariat entre Compuware et mon ESN a été monté, et j’ai commencé à mettre en œuvre mes premiers tests dans Test Director et automatiser mes scripts avec QA Run.

Depuis, cette marche m’a permis de progresser dans ce domaine, avec des responsabilités de Directeur Qualité qui étend le rôle de vérification/validation au domaine des processus, car d’après W.E. Deming, « Il ne suffit pas de faire de son mieux, ni même d’améliorer le produit. Il faut améliorer le système qui produit le produit. »​.

Comment fais-tu ta veille technologique ?

Par la technique – je suis un lecteur du magazine « Programmez ! » pour suivre les tendances et comprendre les évolutions technologiques des SUT (System Under Test) ainsi que les projets sur lesquels je suis impliqué afin de

• gagner en finesse sur les moyens de test
• être capable d’automatiser mes actions sur ce système

Par les moyens – passé un temps, j’ai lu beaucoup de normes (ISO, IEEE, …) et de standards (CMMi, TMMi, syllabi ISTQB + IREB)

Par la lecture d’articles scientifiques liés à ce que je voulais transmettre (researchgate, xarchiv, …)

Par la lecture de livres sur mes sujets et leurs connexions

Par une implication sur les communautés de pratiques, webinaires, et échanges informels avec des amis dans mon domaine – j’apprends par le « faire »

J’organise ma connaissance dans une bibliothèque virtuelle qui renferme plus de 10k documents, et je réfléchis à utiliser Obsidian avec un modèle local pour faciliter ma veille.

Quels sont les principaux changements dont tu as été témoin depuis que tu travailles dans le test et la qualité ?

Fondements avant mon orientation dans le test :

• Mes premiers usages d’outils de gestion de version dès 1997 (Visual Age for Java, SVN, CVS, Perforce et finalement git)
• Mes premiers scénarios de test formels (2000)
• Connaissance du paradigme « test first » cher à l’eXtreme Programming (2000)
• Mes premiers tests unitaires automatisés sur le simulateur du NH90 (2005)

Testing :

• En 2015, j’ai suivi une conf d’un personnage du test – James Bach – qui a inventé la pratique du test exploratoire. Son état d’esprit a bouleversé ma vision du test.
• En 2018, j’ai découvert ce conte jaïniste « Les aveugles et l’éléphant » qui m’a fait comprendre la nécessité de faire « le tour de l’éléphant » pour savoir ce qu’il est vraiment ; il en va de même pour la qualité logicielle.

Génie Logiciel :

• Le Software Craftsmanship avec notamment le TDD qui m’a fait comprendre que je croyais être un bon développeur (2018).
• Cycle incrémentaux et itératifs (RUP – 2001) & Patterns organisationnels (depuis 2008 Coplien, CMMi, Lean Management)
• Rupture du paradigme « les fondations avant le toit » visé par le Cycle en V
• Viser des activités à buts multiples (l’essence de Scrum, et non les « cérémonies » qui ne sont que des patterns organisationnels)
• Principes et outils DevOps (2017)

IA :

• En 2025, j’ai pu voir la source d’idées et l’assistance que pouvait générer un prompt sur une liste d’exigences.
• Cette année, j’ai pu voir qu’un LLM était capable de résoudre en quelques secondes un exercice de développement (kata) que j’aurais mis plusieurs heures voire des journées à mettre au point. De là j’ai commencé à développer mes premiers serveurs MCP, RAG, skills pour construire ma plateforme de développement « myAgenticTeam ».

Il y a actuellement énormément de changements dans l’industrie logicielle. Quels sont, selon toi, les 2 qui impacteront le plus le métier d’ici 5 ans ?

Au présent :

• Taper du code est « définitivement terminé » – le code avec ses tests unitaires et intégrations sont générés. Même la migration technologique n’est plus une difficulté : ma plateforme agentique m’a permis de réaliser en 3h une migration sur plus de 130 fichiers, sans aucune régression
• Les spécifications sont clairement formatées et la traçabilité avec le code sont aisément abordables ainsi que la génération de plans de tests d’après une analyse de risques automatisés et en lien avec le code et les spécifications.

Et dans 6 mois ?

Je n’ai pas de boule de cristal. Je vois juste que des géants flirtent avec la notion « d’IA générales » (GAI), et que ces IA ont les moyens (des harnais d’agents) pour voir et interagir avec leur environnement, avec une facilité qui nous dépasse.

Nous sommes un peu comme au moment des premiers compilateurs qui ont mis au rebut les gens qui faisaient avaler les batchs de cartes perforées dans les centres de calculs, et qui livraient le lendemain les traces d’exécution sur l’imprimante. A ce jour, la programmation agentique n’a cependant pas éliminé les codeurs. Elle les a transformés.

Chez Doctolib, ces codeurs sont toujours indispensables car les agents (ils en utilisent près de 600) sont assujettis à ce que j’appelle l’effet « Canada dry » :

« Ça ressemble à de l’alcool ; ça a le goût de l’alcool ; mais ce n’est pas de l’alcool »

(slogan publicitaire qui a ravagé nos esprits dans les années 70).

Ainsi, cette entreprise a besoin de ses « anciens » pour garantir que ce qui est généré reste cohérent. Ils viennent aussi challenger le produit généré par leurs connaissances qui ne sont pas présentes dans le contexte des agents.

Quelles sont, pour toi, les meilleures transformations à venir pour le testeur d’ici 10 ans ?

Principaux changements :

Le testeur ne peut plus seulement tester le code

Le test ne peut plus être seulement l’application d’un processus de test basé sur des scénarios établis à l’avance

La pyramides des tests part en sucette : avec 95 +% de TU et de TI générés par l’IA, la part manuelle du test devient fine comme un bâton de sucette, la taille de la partie haute dépend alors seulement des harnais d’agents possibles et existants. On ne devrait plus parler de la pyramide des tests mais de « la sucette des tests ».

Illustration par l’exemple :

Dans un contexte «« Prompt 2 Production » testing​ », le testeur se doit

• de procéder à un Shift-Left « ultime » : faire du BDD devient simple, sans savoir programmer. Faireaire un « Quat’z’ amis » basé sur un 3 amigos + 1 (l’IA) où les besoins sont consolidés par une revue avant réalisation par l’IA :PO qui vient challenger la compréhension du besoin par l’IA, dev qui vient challenger le design prévu par l’IA et du testeur qui vient challenger les scénarios de l’IA
• de challenger les tests générés – venir chercher le diable dans les détails
• de procéder à du « mutation testing » (code & données)
• de procéder à des Tests Exploratoires + contrôle de la dérive de la valeur
• d’évaluer et améliorer l’outil qui génère le produit
• de distiller la « pensée critique » & « pensée systémique » dans l’équipe

Les effets induits par l’utilisation de l’IA et idée d’adaptation

En effet, même si l’IA agentique est une fantastique béquille cognitive, cela reste un très mauvais cerveau de substitution. Plus l’IA génère vite du code et des tests, plus notre devoir serait de ralentir pour poser les questions dérangeantes telles que :

• Est-ce qu’on résout le bon problème (plutôt que de s’attacher seulement à la conformité) ?
• Quelle est la dérive de valeur ?
• Et que se passe-t-il si on coupe le courant ?

Pour cela, on pourrait imaginer une évolution de l’équipe agentique sur 5 niveaux :

• Niveau 1 : Conformité / « Bien faire les choses »​
• Niveau 2 : Adéquation / « Faire les bonnes choses »​
• Niveau 3 : Résilience / « Construire des systèmes autonomes durables »​
• Niveau 4 : Mise à l’échelle / « Gouverner les systèmes autonomes à l’échelle »​
• Niveau 5 : Systèmes d’entreprises capables d’adapter réciproquement avec d’autres acteurs leurs interfaces autour de standards internationaux tels que l’IATA dans l’aérien, l’EDI dans le transport, ou l’émergence du BIM dans la construction.

Ces 5 niveaux se verraient régulièrement être renforcés pour une plus grande résilience face aux imprévus, avec la difficulté de positionner le testeur comme celui qui « ralentit » face à une organisation qui jubile devant la vitesse de génération de l’IA. Cela demande un courage politique et un soutien managérial fort, sous peine d’être perçu comme un frein au business.

Quelles sont, pour toi, les transformations les plus inquiétantes à venir pour le testeur d’ici 10 ans ?

La transformation liée à la programmation agentique va beaucoup dépendre du niveau d’adoption des entreprises. Notamment face aux problèmes posés par la souveraineté et le coût liés à certains providers et modèles. Cependant la présence de modèles opensource décale désormais ce problème à des questions de coûts liés à l’infrastructure. Cela n’est donc plus qu’une question déjà connue « Cloud public vs cloud privé » pour la souveraineté ; et de budget nécessaire et finalement alloué pour répondre à la rapidité et le niveau de fiabilité de la mise sur le marché de la valeur ajoutée portée par l’entreprise.

La programmation agentique permet désormais de construire rapidement des solutions, sans trop de difficultés. Les contraintes liées aux connaissances techniques s’effacent rapidement devant les agents dotés des bons harnais.

La contre partie de cette facilité est le coût des tokens consommés par les agents, en plus du coût humain que l’on a vu nécessaire. Ainsi, la seule limite semble devenir financière et non temporelle.

Dorénavant, dans un marché concurrentiel, ce sera plus que jamais la roadmap produit et surtout les ENF (Exigences Non Fonctionnelles) qui feront la différence entre un produit fonctionnel et un bon produit.

Les limites de la programmation agentique

Dans la majorité des situations, le pilote automatique est capable de faire voler l’avion du point A au point B, mais s’il n’y a plus de pilote chevronné, une situation imprévue peut faire dérailler le système. Quel pilote automatique aurait fait amerrir un avions sur l’Hudson et sauver tous ses passagers ?

De même, si la dette technique est anticipable par des skills et corrigeable par une plateforme agentique, s’il n’y a personne pour suivre et comprendre les évolutions, l’entreprise va devoir confronter une nouvelle forme de dette : la « dette cognitive ».

Ainsi, le sénior qui aura su continuer de grandir dans tout ce qui gravite autour du test va rester indispensable tant que la GAI restera hors de portée. Après, cela dépendra :

• de ce que fera réellement cette GAI
• de ce que l’humanité, l’entreprise, les gouvernements et notre planète accepteront de sa part

Pour le junior, c’est un petit peu plus délicat et son avenir devrait dépendre de la part de mentoring accordée par l’entreprise pour que le sénior puisse faire monter en compétence ce junior. C’est l’ancrage des bonnes pratiques dans l’entreprise.

Au final, comment vois-tu le métier de testeur d’ici 10 ans ?

A ce jour, c’est un début de tsunami que certains voient venir. Le temps que cela devienne une « commodité » comme cela s’est produit avec l’agile, le temps que la vague reparte pour permettre la construction, de nouveaux profils pourraient émerger.

Si on devait laisser un clivage entre les fonctions de dev et de testeur, on pourrait voir alors de tels rôles arriver (sur la base des 5 niveaux partagés plus haut) :

Cependant, la facilité avec laquelle le développement d’un besoin se réalise sur une plateforme agentique, je ne parierai pas sur la maintenance de ce clivage, mais plutôt une équipe de réalisation constituée de profils T-shape, comme le prône l’agilité, avec des profils plutôt tech et d’autres plutôt métier.

Nous sommes plus que jamais dans ce que Dave Snowden nomme un contexte « complexe », ce que son framework Cynefin traduit par une situation incertaine dans laquelle la complexité des interactions ne permet de concevoir que les premiers mètres à parcourir, comme lorsque nous avançons dans le brouillard.

Quelques références 😉

En plus des liens dans le texte et des autres notions sont déjà référencées dans « le test en mode agile », ou sur wikipedia, voici 3 articles :

1. Sur l’intensification du travail, le « Workload Creep » et la fatigue de vérification

• Titre : AI Doesn’t Reduce Work — It Intensifies It
• Publication : Harvard Business Review
• Auteurs : Aruna Ranganathan and Xingqi Maggie Ye
• Lien / Référence : Article Harvard Business Review – (résumé : https://aifirstfounders.com/blog/ai-intensifies-work-hbr-study-2026.htm)
• Ce qui est documenté : Une étude de terrain montrant comment l’IA générative pousse les non-développeurs à générer du code (prototype, scripts), ce qui transfère une charge colossale de vérification, de correction et de coaching sur les ingénieurs seniors.

2. Sur l’impact organisationnel de l’IA sur le travail d’ingénierie

• Titre : Generative AI and the Nature of Work
• Publication : CESifo Working Papers
• Auteurs : Manuel Hoffmann, Sam Boysel, Frank Nagle (Harvard Business School), Sida Peng, Kevin Xu
• Lien / Référence : Working Paper HBS / SSRN
• Ce qui est documenté : Une analyse sur grande échelle de l’impact des assistants de code (GitHub Copilot) sur la réallocation des tâches, la dynamique d’autonomie des développeurs et les transformations de la hiérarchie dans les équipes informatiques.

3. Sur la crise de la revue de code et la nécessité d’une QA humaine

• Titre : Why AI Makes Code Review More Important, Not Less
• Auteur : Felix Navas
• Lien / Référence : Analyse DesignRush
• Ce qui est documenté : Cette ligne de publication étudie pourquoi l’augmentation exponentielle du volume de code généré automatiquement rend la revue humaine, la vérification des cas limites (edge cases) et le contrôle de la logique métier plus critiques que jamais (l’effet « Canada Dry » du code).

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.