Guardians of Trust : ce que j'en retiens du Swiss Testing Day 2026

Catégorie : Méthodologie QA | Automatisation & IA
Date : Avril 2026
Temps de lecture : 8 minutes

Le 26 mars 2026, j'étais à Zurich pour le Swiss Testing Day.

Édition "Guardians of Trust". Sous-titre : "Defining Quality in a Dangerous Decade". Plus de 400 professionnels QA réunis au StageOne pour une journée entière. Des keynotes, des sessions, des débats. Et surtout, une question centrale qui revenait dans chaque salle, chaque conversation de couloir :

Qu'est-ce que l'I.A. change vraiment pour nous ?

Voici ce que j'en retiens. Pas un résumé exhaustif. Mes prises de conscience, mes réflexions, ce qui a changé dans ma façon de voir les choses.

Le coding, c'est 10 à 20% du boulot

La keynote d'ouverture était donnée par Bertrand Meyer. Pour ceux qui ne le connaissent pas : c'est le créateur du langage Eiffel, un pionnier du Design by Contract, et un chercheur qui travaille sur la vérification logicielle depuis des décennies.

Son point de départ était simple et percutant.

Si l'I.A. peut coder à notre place... et alors ? Le coding ne représente que 10 à 20% du software engineering. Le reste, c'est du requirements engineering, de l'architecture, du design, de la validation, de la vérification, du testing, du debugging, de la maintenance, du project management.

Dit autrement : même si l'I.A. écrit tout le code du monde, il reste 80% du travail à faire.

Et c'est là que les choses deviennent intéressantes.

Deux types de révolution technologique

Meyer a introduit une distinction que je n'avais jamais formulée aussi clairement.

Il y a les technologies skill-leveling : elles rendent une compétence accessible à plus de monde. L'autofocus en photographie, l'AutoCAD en architecture. Avant, il fallait des années pour maîtriser la mise au point manuelle. Aujourd'hui, n'importe qui peut prendre une photo nette.

Et il y a les technologies skill-enhancing : elles rendent les experts encore meilleurs. La programmation orientée objet, les GPU pour le calcul, l'autocomplétion intelligente. Ces outils ne remplacent pas le savoir-faire. Ils l'amplifient.

L'I.A. générative est les deux à la fois.

Pour un junior, c'est du skill-leveling. Elle permet de produire du code fonctionnel sans maîtriser tous les fondamentaux. Pour un senior, c'est du skill-enhancing. Elle accélère les tâches répétitives et libère du temps pour les décisions d'architecture et de design.

Mais cette dualité crée aussi un piège.

Le fantasme de se débarrasser des développeurs

Ce n'est pas la première fois qu'on annonce la fin des développeurs.

Le low-code. Le no-code. Les générateurs de sites web. À chaque vague technologique, la même promesse revient : on n'aura plus besoin de gens qui codent.

Et à chaque fois, la réalité rattrape le fantasme.

Pourquoi ? Parce que dire à une machine ce que l'on veut ne suffit pas. Dans la vraie vie, les requirements sont flous, contradictoires, incomplets. Les définir, les structurer, les prioriser, c'est un métier à part entière. Celui de chef de projet, de product owner, de business analyst.

Même avec une I.A. capable d'écrire du code parfait, il reste la question fondamentale : code parfait... pour faire quoi exactement ?

C'est la différence entre l'avancement tactique et l'avancement stratégique. L'I.A. excelle dans le tactique. Elle génère, elle complète, elle accélère. Mais le stratégique -- comprendre le problème, définir la direction, arbitrer les compromis -- ça reste humain.

Méphisto dans votre IDE

Un des moments les plus marquants de la keynote : la référence à Faust.

Meyer a affiché une illustration de Méphistophélès avec une citation du Faust de Goethe. Le message était clair : l'I.A. est un assistant séduisant qui vous dit toujours oui.

Et c'est exactement le problème.

L'I.A. ne sait pas dire "stop". Elle ne se rend pas compte qu'elle fait une erreur. Si vous lui demandez de corriger un bug, elle va ajouter du code par-dessus le code existant. Si la correction crée un nouveau problème, elle va ajouter encore du code. Couche après couche, correction après correction, elle construit du spaghetti code sans jamais prendre de recul.

Pire : elle finit par halluciner sur ses propres hallucinations. Elle invente des solutions à des problèmes qu'elle a elle-même créés, avec une assurance totale dans sa réponse.

Le pacte faustien version 2026 : plus de vitesse, moins de contrôle.

Quand l'I.A. est le système sous test

Un point qui m'a particulièrement interpellé en tant que QA : comment tester un système dont le comportement est non-déterministe ?

Avec un logiciel classique, je peux définir des inputs et vérifier des outputs attendus. Avec une I.A. générative, le même prompt peut produire des résultats différents à chaque exécution. Les oracles de test traditionnels ne fonctionnent plus.

La réponse évoquée par Meyer : le metamorphic testing. Au lieu de vérifier un résultat précis, on vérifie des relations entre les résultats. Si je double la quantité de données d'entrée, est-ce que la tendance dans la sortie reste cohérente ? Si je reformule ma question, est-ce que la réponse reste sémantiquement équivalente ?

C'est un changement de paradigme pour le testing. On passe de "est-ce que la réponse est correcte ?" à "est-ce que le comportement est cohérent ?".

Contrats, preuves et tests : le trio gagnant

Meyer a consacré une partie de sa keynote aux contrats logiciels -- préconditions, postconditions, invariants. Son domaine d'expertise historique avec Eiffel.

Son argument : les preuves formelles et les tests ne sont pas en opposition. Ils se renforcent mutuellement. On peut utiliser un prouveur pour générer des suites de tests avec une couverture de 100%. Les contrats servent de spécification vivante qui guide à la fois le développement et la vérification.

Il a cité un papier de Li Huang, Manuel Oriol et lui-même sur la combinaison de tests et preuves pour une meilleure vérification logicielle. Le message sous-jacent est fort : dans un monde où l'I.A. génère du code, les preuves doivent accompagner les tests à chaque instant. On ne peut plus se permettre de faire confiance au code sans vérification formelle.

Le "Barbell Hiring" : un danger pour les profils intermédiaires

La partie sur les stratégies individuelles m'a parlé directement.

Meyer a décrit un phénomène qu'il appelle le "Barbell Hiring". Les entreprises, face à l'I.A., risquent d'adopter une stratégie d'embauche en haltère : beaucoup de profils très juniors (pas chers, assistés par l'I.A.) et quelques profils très seniors (experts, architectes). Le milieu de la barre ? Vide. Les profils intermédiaires, ceux avec 3 à 7 ans d'expérience, seraient les plus menacés.

C'est un signal d'alarme.

Si tu es dans cette tranche, ta stratégie ne peut pas être "faire la même chose qu'avant mais avec ChatGPT". Il faut monter en compétence sur ce que l'I.A. ne fait pas : la vision système, la stratégie de test, la culture qualité, la capacité à définir le "quoi" et le "pourquoi" avant le "comment".

On reste responsable de notre code

La slide de conclusion de Meyer tenait en une phrase. Et c'est peut-être la plus importante de toute la conférence.

You are still responsible for the code.

Que le code soit écrit par nous, par un junior, par un prestataire ou par une I.A., la responsabilité reste la même. La qualité, la robustesse, la maintenabilité, l'extensibilité : tout ça, c'est notre problème.

Et c'est précisément pour ça que la QA n'a jamais été aussi importante. Pas comme une étape en fin de pipeline. Comme une culture. Un système de pensée. Une discipline qui traverse tout le cycle de développement.

Ce que ça change pour moi

J'avais un prof d'informatique qui répétait une phrase qui m'est restée. Il disait que ça ne servait à rien de se lancer dans l'informatique sans passion. Parce que quand les autres rentrent chez eux et vont au sport ou regardent la télé, ceux qui ont la passion créent, construisent, codent. Et que l'expérience battra toujours le scolaire.

Il avait raison. Et avec l'I.A. dans l'équation, c'est encore plus vrai.

L'I.A. ne va pas remplacer les QA. Elle va remplacer ceux qui se contentent d'exécuter des cas de test sans comprendre pourquoi ils existent. Ceux qui n'ont jamais eu la curiosité de regarder comment le système fonctionne en dehors de leur périmètre.

Les testeurs manuels sans intérêt pour la tech, ceux qui ne veulent pas entendre parler d'automatisation ou de code, ce sont eux qui sont menacés. Et soyons honnêtes : travailler dans l'informatique sans vouloir apprendre les bases de son propre domaine, c'est être mauvais dans son métier. Le problème existait bien avant l'I.A. Elle ne fait que le rendre visible.

Le Swiss Testing Day est la conférence de référence en Suisse pour le software testing et la QA. L'édition 2026 "Guardians of Trust" s'est tenue le 26 mars à Zurich.

Je partage régulièrement mes retours d'expérience et réflexions sur ce blog et sur LinkedIn. N'hésitez pas à me contacter si ces sujets vous parlent.