Quality Assistance : 4 Modèles organisationnels pour transformer votre approche
Article 2/7 - Série complète sur la Quality Assistance
La découverte qui a tout changé
J’ai accompagné quatre organisations différentes dans leur transformation qualité. Même objectif, même ambition : implémenter la Quality Assistance. Et pourtant... chacune a emprunté un chemin radicalement différent.
L'une a supprimé tous ses postes de QA dédiés. L'autre a au contraire créé une cellule d'excellence transverse. La troisième a embarqué des coachs qualité dans chaque équipe. La dernière a opté pour un mix des trois approches.
Résultat ? Les quatre ont réussi. Mais pas de la même manière.
Retour terrain : Ce qui m'a fasciné, c'est que chaque organisation avait raison... pour son contexte. Il n'y a pas UNE mais DES Quality Assistance. Et aujourd'hui, je vais vous révéler ces quatre modèles pour que vous puissiez choisir le vôtre en toute conscience.
Ce qui vous attend dans cette série
Cet article est le premier d'une série de 7 publications qui vont vous guider dans cette transformation :
- Qu'est-ce que la Quality Assistance ?
- Les différentes organisations de la Quality Assistance (vous êtes ici)
- Atlassian : les pionniers de la Quality Assistance
- Netflix : You build it, you run it
- OpenClassrooms : d'une QA dédiée à une responsabilité commune
- ManoMano : Une culture décentralisée de la Qualité
- Modèle de maturité de la Quality Assistance
Chaque article explorera un aspect spécifique pour vous donner une vision complète et opérationnelle de cette approche révolutionnaire.
Pourquoi il n'existe pas de recette universelle
Avant de plonger dans les modèles, soyons clairs : copier-coller l'organisation d'Atlassian ou de Netflix sans comprendre votre propre contexte, c'est la garantie de l'échec.
Trois facteurs déterminent le modèle qui vous correspond :
Votre maturité technique - Vos équipes maîtrisent-elles déjà le TDD, l'automatisation, les pratiques DevOps ?
Votre culture organisationnelle - Êtes-vous dans une logique de projets ou de produits ? Autonomie ou contrôle ?
Votre écosystème - Mono-produit ou multi-produits ? Équipes colocalisées ou distribuées ?
Et si votre plus gros frein n'était pas technique mais organisationnel ?
Modèle 1 : No QA - L'Autonomie Totale
Le principe
Composition d'équipe : Product Owner + Développeurs/Craftsmen
Particularité : Aucun rôle QA dédié dans l'équipe
Les équipes produit gèrent la qualité de bout en bout. Le test n'est plus un rôle mais une compétence distribuée que tout le monde maîtrise.
Retour terrain : Quand j'ai vu ça pour la première fois...
Je me souviens de cette scale-up fintech où j'ai découvert ce modèle. Première réaction : "Vous plaisantez ? Sans QA ?"
Six mois plus tard, leur taux de défauts en production était inférieur à celui d'équipes avec 2-3 testeurs dédiés. Le secret ? Une culture qualité tellement ancrée que chaque développeur testait naturellement, pair-programmait systématiquement, et appliquait le TDD comme une seconde nature.
Les conditions de succès
✅ Maturité technique très élevée - Clean code, TDD, pair programming, CI/CD avancé
✅ Culture forte du craftsmanship - Les développeurs sont des craftsmen, pas juste des codeurs
✅ Taille d'équipe réduite - Généralement 5-7 personnes maximum
✅ Domaine métier stable - Pas de réglementation complexe ou changeante
Les avantages
- Vélocité maximale - Aucun goulot d'étranglement, flux continu
- Ownership fort - Les équipes portent vraiment leurs décisions
- Coût optimisé - Pas de doublon de compétences
Les limites à connaître
⚠️ Risque de régression - Si la culture qualité faiblit, tout s'effondre
⚠️ Pas scalable facilement - Difficile à reproduire sur 10 équipes simultanément
⚠️ Formation intensive requise - Montée en compétence longue et coûteuse
💡 Mon conseil : Ce modèle est l'aboutissement d'une maturité, pas le point de départ. Ne brûlez pas les étapes ! Ce n’est pas forcément votre objectif à atteindre.
Modèle 2 : QA Intégrée - L'Expert Embarqué
Le principe
Composition d'équipe : Product Owner + Développeurs/Craftsmen + QA Coach
Particularité : Le QA est un membre permanent de l'équipe produit
Le professionnel qualité devient le coach qualité de l'équipe. Il ne teste plus à la place des autres, il élève le niveau de tous.
Retour terrain : La transformation de Sophie
Sophie (Ce n’est pas son vrai nom) était testeuse depuis 8 ans. "Je suis là pour trouver les bugs", me disait-elle. Six mois après sa transition en QA Coach intégrée, son discours avait changé : "Je suis là pour qu'on n'en crée plus."
Elle animait désormais les sessions d'example mapping, coachait les développeurs sur l'automatisation, et organisait des sessions de tests exploratoires et de pair testing.
Les conditions de succès
✅ Équipes produit stables - Composition d'équipe pérenne dans le temps
✅ Volonté de collaboration - Culture d'équipe orientée learning
✅ QA avec soft skills forts - Communication, pédagogie, leadership sans autorité
✅ Ratio adapté - 1 QA pour 5-8 développeurs maximum
Les avantages
- Connaissance métier profonde - Le QA devient expert du domaine
- Réactivité optimale - Présent à tous les rituels, toutes les décisions
- Cohérence d'équipe - Vision qualité partagée et incarnée
- Coaching sur mesure - Adapté aux besoins spécifiques de l'équipe
Les limites à connaître
⚠️ Risque de silotage - Pratiques différentes entre équipes
⚠️ Manque de transversalité - Difficultés à partager les innovations
⚠️ Dépendance à la personne - Si le QA part, l'équipe peut perdre pied
💡 Mon conseil : Créez des communautés de pratiques entre QA intégrés pour partager et harmoniser !
Modèle 3 : QA Transverse - Le Service Partagé 🎪
Le principe
Composition : Équipe QA centralisée ↔ Multiples Product Teams (PO + DEV/CRAFT)
Particularité : Une task force qualité au service de plusieurs équipes
Les QA forment une équipe dédiée qui intervient auprès de plusieurs équipes produit selon les besoins, les phases projet, ou les expertises requises.
Retour terrain : Le modèle de la "brigade volante"
Dans cette entreprise de e-commerce, j'ai observé une équipe de 4 QA seniors gérant 8 équipes produit. Leur secret ? Une allocation dynamique basée sur les risques.
Une nouvelle feature critique sur le parcours achat ? Deux QA débarquent pour une semaine intensive de coaching. Une période calme sur un produit mature ? L'équipe est autonome, les QA se concentrent ailleurs.
Les conditions de succès
✅ Forte expertise QA - Des seniors capables d'intervenir sur tout type de sujet
✅ Bonne coordination - Allocation claire, priorisation assumée
✅ Product teams déjà sensibilisées - Autonomie de base sur la qualité
✅ Rituels transverses - Sessions de partage, documentation centralisée
Les avantages
- Mutualisation des compétences - Expertise partagée entre toutes les équipes
- Flexibilité d'allocation - Concentration des forces où c'est nécessaire
- Économie d'échelle - Moins de QA au total pour plus d'équipes
- Innovation centralisée - Nouvelles pratiques testées puis diffusées
Les limites à connaître
⚠️ Risque de goulot - Les QA peuvent devenir submergés
⚠️ Moins de proximité - Connaissance métier plus superficielle
⚠️ Priorisation délicate - "Pourquoi eux et pas nous ?"
⚠️ Dépendance organisationnelle - Sans les QA, les équipes sont parfois perdues
💡 Mon conseil : Formalisez vos critères d'intervention et communiquez-les clairement pour éviter les frustrations !
Modèle 4 : Hybride - Le Meilleur des Deux Mondes 🎭
Le principe
Composition : Product Teams (PO + DEV/CRAFT + QA) + Experts Qualité Transverses (Coaches/Quality Experts)
Particularité : Double casquette - QA embarqués ET centre d'expertise
Ce modèle combine l'expertise de proximité (QA intégrés) avec la vision stratégique et l'innovation (experts transverses).
Retour terrain : La transformation progressive d’un QA
Théo dirigeait une équipe QA traditionnelle de 12 personnes. Il a opté pour une transformation en deux temps :
Phase 1 (6 mois) - Intégration de 8 QA dans les équipes produit comme coaches
Phase 2 (6 mois) - Création d'un pôle de 4 experts transverses (automatisation, observabilité, test data management, …)
Résultat ? Les équipes sont autonomes au quotidien, mais bénéficient de l'expertise pointue quand nécessaire. Le meilleur des deux mondes.
Les conditions de succès
✅ Taille d'organisation suffisante - Au moins 5-6 équipes produit
✅ Maturité moyenne à forte - Équipes déjà sensibilisées à la qualité
✅ QA avec des profils variés - Certains orientés coaching, d'autres expertise technique
✅ Gouvernance claire - Rôles et responsabilités bien définies
Les avantages
- Autonomie + Expertise - Le meilleur de chaque modèle
- Scalabilité forte - Fonctionne de 5 à 50 équipes
- Innovation continue - Les experts font de la R&D qualité
- Résilience élevée - Pas de single point of failure
Les limites à connaître
⚠️ Complexité organisationnelle - Plus de rôles, plus de coordination
⚠️ Coût plus élevé - Plus de personnes au total
⚠️ Risque de confusion - "Je m'adresse à qui pour quoi ?"
⚠️ Management plus exigeant - Équilibrage délicat entre proximité et transversalité
💡 Mon conseil : Définissez clairement le "contrat de service" entre les QA intégrés et les experts transverses dès le départ !
Quel Modèle pour Vous ?
Comment Choisir VOTRE Modèle ? 🤔
Et si le meilleur modèle n'était pas celui que vous imaginez ?
Les 5 questions à vous poser
1. Où en êtes-vous en maturité technique ?
- Vos devs pratiquent-ils le TDD ou l’architecture hexagonale naturellement ?
- L'automatisation est-elle déjà bien ancrée ?
- La culture DevOps est-elle vivante ?
2. Quelle est votre culture organisationnelle ?
- Plutôt autonomie ou contrôle ?
- Logique projet ou produit ?
- Collaboration ou hiérarchie ?
3. Combien d'équipes devez-vous couvrir ?
- 1-3 équipes → QA Intégrée ou No QA
- 4-10 équipes → QA Transverse ou Hybride
- 10+ équipes → Hybride obligatoire
4. Quel est votre niveau de risque acceptable ?
- Domaine régulé (finance, santé) → QA Intégrée minimum
- Innovation rapide (startup) → No QA ou QA Transverse
- Mix des deux → Hybride
5. Quelles sont vos ressources disponibles ?
- Budget limité → QA Transverse
- Budget confortable → QA Intégrée ou Hybride
- Accès à des talents seniors → Tous les modèles possibles
Le piège à éviter absolument
❌ Ne copiez JAMAIS un modèle par effet de mode
J'ai vu une PME tenter d'implémenter le modèle Netflix (No QA) parce que "c'est ce que font les GAFAM". Résultat : 6 mois de chaos, explosion des défauts en production, démotivation des équipes.
✅ Partez de VOTRE réalité, pas de celle des autres
Appel à l'action : Faites un audit honnête de votre situation actuelle avant de choisir !
Les 3 Erreurs Courantes (et Comment les Éviter) ⚠️
Erreur 1 : Choisir par mimétisme
Symptôme : "Atlassian fait comme ça, on va faire pareil"
Danger : Contextes différents = résultats différents
Solution : Analysez POURQUOI Atlassian a fait ce choix, pas seulement QUOI ils ont fait
Erreur 2 : Négliger le facteur humain
Symptôme : "On change l'organigramme lundi prochain"
Danger : Résistance au changement, perte de talents, sabotage inconscient
Solution : Accompagnez, formez, co-construisez la transformation avec les équipes
Erreur 3 : Vouloir tout changer d'un coup
Symptôme : "On bascule les 15 équipes en mode QA Intégrée le mois prochain"
Danger : Surcharge cognitive, échecs visibles, retour en arrière brutal
Solution : Expérimentez sur 1-2 équipes pilotes, apprenez, ajustez, puis scalez progressivement. Le changement ce n’est pas que des processus mais aussi s’assurer d’avoir les bonnes compétences pour y arriver.
La Vérité Qui Dérange
Aucun de ces modèles n'est "le meilleur". Chacun est un compromis adapté à un contexte.
Ce qui compte, ce n'est pas le modèle que vous choisissez, mais :
- La clarté avec laquelle vous le définissez
- La conviction avec laquelle vous le portez
- L'agilité avec laquelle vous l'adaptez
J'ai vu des modèles "parfaits sur le papier" échouer faute de sponsorship. Et des modèles "bancals théoriquement" réussir grâce à l'engagement des équipes.
Retour terrain : La meilleure organisation n'est pas celle du livre, c'est celle que vos équipes s'approprient et font évoluer.
Et Maintenant ? Votre Plan d'Action
Étape 1 : Évaluez honnêtement votre contexte (les 5 questions ci-dessus)
Étape 2 : Identifiez 1-2 équipes pilotes qui VEULENT expérimenter
Étape 3 : Choisissez le modèle le plus adapté à CES équipes (pas forcément à toute l'organisation)
Étape 4 : Lancez l'expérimentation sur 3-6 mois avec des points de contrôle réguliers
Étape 5 : Apprenez, ajustez, puis décidez de la suite
Combien de temps allez-vous attendre avant de prendre la décision ?
Dans le dernier article, un modèle de maturité vous sera présenter pour vous aider à savoir d’ou vous partez.
Il n'y a pas de destination finale
Ces quatre modèles ne sont pas des cases dans lesquelles vous devez rentrer. Ce sont des points de repère pour construire VOTRE organisation qualité.
L'organisation idéale, c'est celle qui :
- Correspond à votre maturité actuelle
- S'adapte à votre culture
- Peut évoluer avec vous
Dans le prochain article, nous plongerons dans le cas concret d'Atlassian, les pionniers qui ont popularisé la Quality Assistance en 2009. Vous découvrirez leur parcours en 6 phases, et les pratiques clés qui ont fait leur succès.
Et vous, dans quel modèle vous reconnaissez-vous ? Partagez votre expérience en commentaire, enrichissons la discussion !
FAQ - Vos Questions, Nos Réponses
Peut-on passer d'un modèle à un autre au fil du temps ?
Absolument, et c'est même recommandé ! Votre organisation qualité doit évoluer avec votre maturité. Beaucoup d'entreprises commencent par la QA Transverse (faible investissement, bons résultats), puis évoluent vers l'Hybride quand elles scalent, et parfois vers le No QA pour certaines équipes très matures. L'essentiel est de faire évoluer progressivement, pas brutalement.
Quel modèle pour une petite équipe de 5-10 personnes ?
Pour une équipe unique de cette taille, la QA Intégrée est souvent le meilleur choix. Un QA coach qui accompagne 4-5 développeurs permet de monter en compétence l'équipe tout en gardant un œil expert. Si votre équipe est déjà très mature techniquement (TDD, pair programming, forte culture qualité), vous pouvez envisager le No QA.
Le modèle No QA n'est-il pas trop risqué ?
Oui, SI vous n'avez pas les prérequis. Non, SI vous les avez. Le risque ne vient pas du modèle mais du gap entre vos capacités réelles et les exigences du modèle. Une équipe qui pratique le TDD religieusement, fait du pair programming, a une couverture de test élevée et une culture qualité forte prendra MOINS de risques en No QA qu'une équipe immature avec 3 testeurs dédiés. La question n'est pas "est-ce risqué ?" mais "sommes-nous prêts ?".
Combien de d’équipes un QA transverse peut-il supporter efficacement ?
En moyenne, un QA transverse peut accompagner 2-3 équipes produit de manière soutenue. Au-delà, il devient un goulot d'étranglement. Cependant, si les équipes sont déjà autonomes sur les bases et que le QA intervient principalement pour de l'expertise pointue ou des moments clés (lancements, audits), il peut en supporter jusqu'à 4-5. L'important est de mesurer le taux de sollicitation et d'ajuster.
Le modèle hybride n'est-il pas trop complexe à gérer ?
Il est effectivement plus complexe que les autres, mais c'est aussi le plus scalable et le plus résilient. La complexité vient de la nécessité de coordonner deux niveaux (proximité + transverse) et de clarifier les rôles. Mon conseil : créez un "contrat de service" clair qui définit qui fait quoi, quand, et comment les deux niveaux collaborent. Avec cette clarté, la complexité devient un avantage, pas un frein.
Faut-il réorganiser toute l'entreprise si on change de modèle ?
Non ! C'est même déconseillé. Procédez par expérimentation progressive : choisissez 1-2 équipes pilotes volontaires, testez le nouveau modèle sur 3-6 mois, mesurez les résultats, ajustez, puis décidez de l'étendre ou non. Certaines entreprises fonctionnent même avec plusieurs modèles coexistants selon la maturité des équipes. L'uniformité n'est pas toujours souhaitable.
Quel modèle privilégier pour commencer une transformation Quality Assistance ?
Si vous partez d'une QA traditionnelle, la QA Transverse peut être le meilleur point de départ. Pourquoi ? Investissement limité (vous transformez vos QA actuels), impact visible rapidement, et possibilité d'expérimenter sur plusieurs équipes en parallèle. Une fois la culture installée, vous pouvez faire évoluer vers l'Intégrée ou l'Hybride selon vos besoins. Bien sur cela depend de votre ambition et de votre culture.
Un QA intégré doit-il obligatoirement connaître le domaine métier au départ ?
Non, mais il doit avoir la capacité et la volonté de l'apprendre rapidement. Un bon QA coach avec de solides soft skills et une curiosité naturelle montera en compétence métier en 3-6 mois. En revanche, un expert métier sans compétences de coaching ou de facilitation aura du mal à jouer le rôle d'enabler. Priorisez les soft skills et la posture coach, le métier viendra.
Cet article est le 2ème d'une série de 7 publications sur la Quality Assistance. Dans le prochain épisode : plongée dans le cas Atlassian, les pionniers qui ont révolutionné le test logiciel.
📌 Article précédent : Qu'est-ce que la Quality Assistance ?
📌 Article suivant : Atlassian : Les Pionniers de la Quality Assistance (à paraître)