Tests en entreprise : comment ne pas rester coincé dans « l'esclavage manuel » et devenir architecte

Des années de service sur un petit bateau de pêche m'ont appris à connaître chaque fissure sur le pont, à réparer le moteur moi-même et à sentir intuitivement où le poisson mord. Mais cette expérience demande aujourd'hui une remise en question totale : je suis à la passerelle d'un porte-conteneurs géant avec des centaines de membres d'équipage, des systèmes de navigation automatisés ultra-complexes et un calendrier rythmé par les ports de différents fuseaux horaires.

C'est à peu près ainsi que se ressent le passage d'une petite agence à une grande entreprise.

Ici, le principe « j'ai trouvé un bug — je l'ai corrigé — je passe à autre chose » ne fonctionne pas. Dans une entreprise, tu gères la qualité d'un produit utilisé par des millions de personnes. Et ton principal outil n'est pas tant les compétences techniques que la pensée systémique.

Ce qui se passe réellement dans l'entreprise

Dans les petits projets, tu vois l'ensemble du tableau. Tu peux parcourir toutes les couches de l'application en une journée, soulever les mocks, injecter des données de test et dire : « Ici, c'est cassé, réparez. »

En entreprise, le tableau est différent. Ta tâche n'est pas seulement de trouver un défaut, mais de prouver qu'il existe, de le reproduire dans l'environnement approprié, de le classer correctement et de convaincre l'équipe de développement que c'est une priorité supérieure à la moyenne.

La différence réside dans l'ampleur des responsabilités. La précision avec laquelle tu identifies la cause racine influence le délai de publication et la réputation du produit.

Trois niveaux du testeur en entreprise

Le parcours, du débutant à l'architecte des solutions de test dans une grande entreprise, ressemble à la progression dans un RPG complexe. À chaque niveau, il y a ses propres monstres et ses propres bonus.

Niveau 1 : Exécuteur de tests manuels

À ce stade, tu rédiges des listes de contrôle et exécutes des tests de régression. Tu es les yeux de l'équipe. Ta tâche est de repérer une anomalie et de rédiger correctement un rapport de bug.

Mais il y a un piège ici. Tu peux travailler comme ça pendant trois ans et rester au même niveau, en cliquant mécaniquement sur l'application. C'est avantageux pour l'entreprise — tu fais le travail de manière stable. Pour toi, non.

💡 Conseil: Si tu es à ce niveau depuis plus d'un an, commence d'urgence à apprendre l'automatisation. Pas pour écrire des frameworks complexes, mais pour automatiser ta propre routine. Prends n'importe quel contrôle répétitif et écris un script Python pour celui-ci. Cela changera ta façon de penser.

Niveau 2 : Ingénieur en automatisation

Ici, tu ne cherches plus les bugs manuellement — tu construis l'infrastructure qui le fait pour toi. Tu écris des tests pour l'API, tu configures le CI/CD, tu travailles avec les environnements de test.

L'erreur la plus courante à ce niveau est de vouloir tout automatiser. « Nous avons 1000 tests manuels — automatisons-les tous ! » c'est une voie sans issue. L'automatisation pour l'automatisation tue le temps et les ressources.

Niveau 3 : Architecte des solutions de test

Il ne s'agit plus d'écrire du code, mais de concevoir le système de test dans son ensemble. Tu décides quels outils utiliser, comment organiser les données de test, quelles métriques collecter pour évaluer objectivement la qualité du produit.

L'architecte n'a pas pour mission de « trouver un bug ». Sa mission est de faire en sorte que les bugs ne puissent pas passer inaperçus. Il construit le système de sécurité qualité.

Pourquoi la communication est plus importante que le code

La demande la plus fréquente des RH dans les entreprises est « un candidat avec des soft skills développés ». Et ce n'est pas un caprice. Dans l'entreprise, tu ne travailles pas dans le vide.

Ton rapport de bug sera lu par : le développeur (qui peut être dans un autre fuseau horaire), le chef de produit (qui ne comprend pas les détails techniques), le responsable d'équipe (qui évalue les risques de la version).

Si tu écris « L'authentification ne fonctionne pas », tu ne seras pas compris. Si tu écris « Lors de la saisie d'un numéro de téléphone invalide sous iOS 17.2, l'application plante avec le code d'erreur EXC_BAD_ACCESS, cela ne se produit que sur un appareil réel iPhone 15 Pro Max », tu seras entendu, compris et des mesures seront prises.

Le secret ici est que les développeurs sont aussi surchargés. Ils ont leur propre backlog, leurs propres tâches. Ton travail est de faciliter leur travail : fournir des informations prêtes à l'emploi pour qu'ils n'aient pas à revérifier.

La peur de l'infrastructure complexe et comment la surmonter

Lorsque tu vois pour la première fois l'architecture d'un grand produit — des dizaines de microservices, des files de messages, plusieurs bases de données déployées dans différentes régions, des pipelines CI/CD avec des centaines de jobs — une envie naturelle de fermer l'ordinateur portable et d'aller travailler dans un taxi surgit.

Mais il y a une bonne nouvelle : personne ne connaît ce système dans son ensemble.

L'architecte qui a écrit ce système le connaît à 70 %. L'équipe de développement — à 30 %. Toi, le testeur — tu n'as pas besoin de tout savoir. Tu as besoin de savoir comment trouver n'importe quelle information.

💡 Conseil: Crée un « mémo » personnel. Dans Notion ou Confluence, crée une page où tu collectionnes : - les liens vers la documentation de chaque microservice ; - les contacts des responsables de chaque sous-système ; - les schémas d'interaction ; - les problèmes typiques et leurs solutions. Ce document grandit avec toi et, après un an, devient l'artefact le plus précieux de l'entreprise.

Lutter contre l'épuisement professionnel : pourquoi les entreprises ne sont pas pour les « marathoniennes »

L'épuisement ne vient pas des heures supplémentaires, mais de l'absurdité de tourner en rond.

Dans une entreprise, il est facile de tomber dans le piège : tu publies des versions, tu fermes des tickets, tu participes à des réunions — et tu n'as pas l'impression de progresser. Parce que le produit est gros et que ta contribution se « dilue » dans la masse.

La seule façon d'éviter cela est de se lancer dans des projets de longue durée que tu mènes en parallèle de tes tâches courantes.

Comment progresser : un plan concret du testeur à l'architecte

Supposons que tu sois actuellement testeur manuel avec 1 à 2 ans d'expérience. Par où commencer ?

Étape 1. Apprends Python ou Java

Pas besoin de devenir un programmeur pro. Il suffit de savoir :

• écrire des scripts pour automatiser la routine ;
• lire le code des autres ;
• comprendre comment fonctionnent les frameworks de test (pytest, JUnit).

Étape 2. Maîtrise les outils de requêtes

Tu dois pouvoir voir où l'application va. Charles, Fiddler, Postman — choisis-en un et connais-le au niveau « je peux intercepter une requête, modifier une réponse, vérifier les en-têtes ».

Étape 3. Apprends à travailler avec la base de données

SQL, c'est un super-pouvoir. Quand le développeur dit « tout fonctionne », tu écris un SELECT et tu vois que l'enregistrement n'a pas été sauvegardé. Cela met fin à 80 % des disputes.

Étape 4. Comprends comment fonctionne le CI/CD

Jenkins, GitLab CI, GitHub Actions — tout testeur avec plus de 3 ans d'expérience doit savoir configurer un pipeline simple avec l'exécution des tests et l'envoi du rapport.

Que faire si tu es déjà en entreprise et que tu as l'impression de stagner

Le plus terrible est de rester dans ta zone de confort, où tu connais chaque bouton de l'application testée, mais où tu ne progresses pas. Comment vérifier que tu évolues ?

Pose-toi trois questions :

1. Le mois dernier, ai-je appris quelque chose de nouveau sur le fonctionnement du système ?
2. Ai-je cessé de faire manuellement des tâches que je faisais auparavant ?
3. Quelqu'un de l'équipe m'a-t-il demandé conseil sur les tests ?

Si la réponse à au moins une question est « non », tu es en stagnation.

💡 Conseil: Le moyen le plus rapide de sortir de la stagnation est de prendre une tâche que personne ne veut faire. « Ce module legacy n'a pas été testé depuis trois ans », « Ces tests échouent à chaque exécution, mais personne n'a enquêté », « Une nouvelle fonctionnalité sort — besoin de documentation ». Prends-la. Débrouille-toi. Va jusqu'au bout. Dans trois mois, tu deviendras un expert incontournable de cette zone.

Conclusion : l'entreprise donne plus qu'elle ne prend

Travailler dans une grande entreprise, ce n'est pas seulement de la bureaucratie et des versions longues. C'est aussi l'accès à une immense expertise technique, la possibilité de travailler avec des systèmes évolutifs et — le plus important — des collègues qui en savent plus que toi.

Ta tâche est de ne pas avoir peur de prendre des initiatives. Ne pas attendre qu'on te donne une tâche intéressante. Va voir l'architecte et demande : « Puis-je aider avec les tests du nouveau module ? ». Va voir le DevOps et demande l'accès aux logs. Va voir l'analyste et précise les exigences.

L'entreprise est un écosystème. On peut y travailler dix ans sans se faire remarquer, en effectuant les mêmes tests manuels. Ou on peut, en deux ans, devenir un spécialiste qui définit la stratégie qualité du produit.

Le choix t'appartient.