Atlassian , le Pionner : Le voyage en 6 étapes vers la Quality Assistance

Article 3/7 - Série complète sur la Quality Assistance

2009 : Le Jour où Tout a Basculé

Sydney, Australie. Les bureaux d'Atlassian bourdonnent d'une énergie fébrile. JIRA, Confluence, Bitbucket... les produits cartonnent. L'entreprise scale rapidement. Trop rapidement.

Et puis, le mur.

Les équipes de développement sprintent, les features s'empilent, mais tout s'arrête au niveau de la validation. Les cycles de release s'allongent. Les tensions montent.

Face à ce constat, Atlassian prend une décision audacieuse, presque radicale : réinventer complètement le rôle du QA.

: J'ai vu cette même scène se répéter dans des dizaines d'organisations. La différence avec Atlassian ? Ils n'ont pas juste recruté plus de testeurs. Ils ont changé les règles du jeu.

Aujourd'hui, je vais vous révéler leur parcours en 6 phases - un voyage de transformation qui inspirera votre propre révolution qualité. Accrochez-vous, ça va secouer !

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 :

1. Qu'est-ce que la Quality Assistance ?
2. Les différentes organisations de la Quality Assistance
3. Atlassian : les pionniers de la Quality Assistance (vous êtes ici)
4. Netflix : You build it, you run it
5. OpenClassrooms : d'une QA dédiée à une responsabilité commune
6. ManoMano : Une culture décentralisée de la Qualité
7. 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.

Portrait : Qui est Atlassian et pourquoi les écouter ?

En chiffres :

• Valorisation : 93,25 milliards de dollars
• Méthodologie : Agile native
• Spécialité : Outils de collaboration logicielle (JIRA, Confluence, Trello)

Leur défi en 2009 :

• Croissance exponentielle des équipes
• Nécessité de scaler sans sacrifier la qualité
• Pression compétitive intense dans le SaaS

Et si votre plus gros problème qualité était en réalité votre plus belle opportunité de transformation ?

Ce qui rend Atlassian crédible, ce n'est pas qu'ils ont trouvé LA solution parfaite. C'est qu'ils ont osé documenter leur échecs, leurs apprentissages et leur progression pour que d'autres puissent s'en inspirer.

La vision révolutionnaire : "Quality is Everyone's Responsibility"

Le changement de paradigme

En 2009, Atlassian pose les bases d'une révolution : passer de "Quality Assurance" à "Quality Assistance".

La nouvelle mission :

"Quality at Speed : permettre aux développeurs de tester en toute confiance, pendant que les QA Engineers s'attaquent à des défis plus grands, plus difficiles et plus audacieux."

Décortiquons cette phrase puissante :

• "Quality at Speed" = Vitesse ET qualité (pas l'un ou l'autre)
• "Développeurs testent en confiance" = Autonomie, pas dépendance
• "QA s'attaquent à des défis plus grands" = Élévation du rôle, pas suppression

Le concept révolutionnaire : Developer on Test (DoT)

L'idée qui change tout : les développeurs deviennent responsables du test de leur propre code.

Quand j'ai présenté ce concept à mes premiers clients, la réaction était systématique : "Mais les développeurs ne SAVENT pas tester !" Ma réponse : "Pas encore. C'est là qu'intervient le QA Coach."

L'approche top-down : Le sponsorship qui change tout

Contrairement à de nombreuses initiatives qualité qui partent de la base, Atlassian a bénéficié d'un sponsorship managérial fort.

Les 3 principes directeurs posés par le management :

1. Quality + Speed - Pas de compromis entre les deux
2. Independence - Supprimer les goulots d'étranglement QA
3. Experimentation - Adapter les pratiques qualité au contexte, valider avec des données

J'ai accompagné de nombreuses transformations Quality Assistance. Les 3 qui ont échoué avaient un point commun : pas de sponsorship exécutif. Les autres qui ont réussi ? Leadership visible dès le jour 1.

Le voyage en 6 étapes : de Zéro à Héros

Atlassian n'est pas passé de la QA traditionnelle à l'excellence en un claquement de doigts. Ils ont progressé, expérimenté, échoué, appris, ajusté.

Avertissement avant de démarrer : Aucune organisation ne devrait sauter d'étapes. Chaque phase construit les fondations de la suivante.

Allons-y, étape par étape.

Stage 0 : No QA - L'automatisation seule

Le modèle

Flux : Développement → Déploiement (automatisation uniquement)

Focus : Correction fonctionnelle via tests automatisés

Acteurs : Développeurs uniquement

La réalité du terrain

À ce stade, Atlassian comptait uniquement sur l'automatisation : tests unitaires, tests d'intégration, CI/CD basique. Aucun QA dédié dans le processus.

Ce qui s'est passé : Ça a marché... pour les bugs évidents. Mais :

• Les edge cases passaient à travers
• L'expérience utilisateur n'était pas validée
• Les bugs subtils d'intégration explosaient en production

Retour terrain : J'ai vu cette approche échouer dans 80% des cas. Pourquoi ? Parce que l'automatisation teste ce que vous lui dites de tester, pas ce que vous avez oublié de penser.

💡 Ce qu'on en retient : L'automatisation est nécessaire, mais pas suffisante. Elle teste la correction, pas la qualité.

Stage 1 : QA Testing - Le test Exploratoire arrive

Le modèle

Flux : Développement → Testing (QA) → Déploiement

Nouveauté : Ajout du rôle QA pour validation après développement

Acteurs : Développeurs + QA (test exploratoire)

L'évolution

Face aux limites du Stage 0, Atlassian introduit des QA Engineers qui pratiquent le test exploratoire après le développement.

Résultat positif : Davantage de bugs détectés avant production, notamment :

• Les scénarios non prévus
• Les problèmes d'UX
• Les bugs d'intégration subtils

Problème découvert : Trop de bugs remontés en fin de cycle. Le coût de correction explose. Le cycle s'allonge.

💡 Ce qu'on en retient : Détecter tard coûte cher. Il faut remonter plus tôt dans le cycle.

Stage 2 : DoTing - Les développeurs testent

Le modèle

Flux : Développement + DoTing (Dev teste) → Release Testing (QA) → Déploiement

Nouveauté : Introduction du "Developer on Testing"

Acteurs : Développeurs (test exploratoire) + QA (release testing)

La transformation

Les développeurs commencent à faire du test exploratoire sur leurs propres stories. Les QA se concentrent sur le Release Testing (validation globale avant production).

Résultat positif :

• Bugs détectés plus tôt dans le cycle
• Feedback immédiat pour les développeurs
• QA peuvent se concentrer sur la vue d'ensemble

Problème persistant : Encore beaucoup de bugs découverts lors du Release Testing.

Retour terrain : Dans ma première implémentation du DoT, les développeurs étaient sceptiques : "Je n'ai pas le temps de tester en plus de coder." Trois mois plus tard, ils avaient divisé leur temps de correction de bugs par 3. Le ROI était évident.

L'insight clé : Les développeurs testent avec les mêmes biais que leur développement. Il manque une étape de partage de perspective avant le code.

💡 Ce qu'on en retient : Faire tester les développeurs, c'est bien. Les former à COMMENT tester, c'est mieux.

Stage 3 : Demos & Notes - Le facteur clé de succès

Le modèle

Flux : Développement + DoTing → QA Demo → Déploiement

Nouveauté : QA Demos (15-30 min de pairing) + Testing Notes collaboratives

Acteurs : Développeurs (DoT) + QA (Demo & guidance)

La pratique révolutionnaire

Atlassian introduit les QA Demos : des sessions de 15-30 minutes où le développeur montre son implémentation au QA une fois le code terminé.

Déroulé d'une QA Demo :

1. Le développeur présente son implémentation
2. Le QA pose des questions, identifie les risques
3. Ensemble, ils co-créent les Testing Notes
4. Le développeur teste avec cette nouvelle perspective

Les Testing Notes = Documentation collaborative des :

• Scénarios de test clés
• Risques identifiés
• Edge cases à vérifier
• Stratégies de test recommandées

Impact mesurable :

• Réduction de 50% des rejets de stories
• Feedback immédiat quand le code est encore frais
• Montée en compétence continue des développeurs

Retour terrain : C'est LA pratique qui a tout changé pour mes clients. Dans une squad retail, nous avons introduit les QA Demos. En 6 semaines, le cycle de validation est passé de 8 jours à 3 jours. Pourquoi ? Parce qu'on détecte les malentendus AVANT qu'ils ne deviennent des bugs.

💡 Ce qu'on en retient : Prévention > Détection. Les Testing Notes sont le facteur clé de succès. C'est simple, rapide, et l'impact est immédiat.

Stage 4 : QA Kickoffs - Anticiper plutôt que éparer

Le modèle

Flux : QA Kickoff → Développement + DoTing → QA Demo → Déploiement

Nouveauté : QA Kickoff AVANT le développement

Acteurs : QA + Dev + PO (3 Amigos) puis Dev (DoT) puis QA (Demo)

La transformation majeure

Le QA intervient AVANT que la première ligne de code soit écrite.

Déroulé d'un QA Kickoff :

1. 3 Amigos (PO + Dev + QA) se réunissent avant le dev
2. Le PO explique le besoin métier
3. Le Dev expose son approche technique
4. Le QA pose les questions "what if" et identifie les risques
5. Ensemble, ils créent les Testing Notes préventives

Impact mesurable :

• Vitesse + haute qualité enfin atteintes
• Réduction supplémentaire de 50% des rejets de stories
• Malentendus détectés avant le code (coût quasi nul)

Le principe enfin appliqué : Prevention >>> Detection

Retour terrain : J'ai accompagné une équipe qui a voulu sauter cette étape : "On connaît déjà le sujet, pas besoin de kickoff." Résultat : 3 stories sur 5 retournées en développement pour malentendu sur les critères d'acceptation. Coût : 2 semaines de retard. Ils n'ont plus jamais sauté un kickoff.

💡 Ce qu'on en retient : 30 minutes de QA Kickoff évitent des heures de rework. C'est mathématique.

Stage 5 : Private Kickoffs - L'autonomie se construit

Le modèle

Flux : Kickoff (Dev seuls) → Review (QA) → Développement + DoTing → QA Demo → Déploiement

Nouveauté : Les développeurs font leurs propres kickoffs, QA review

Acteurs : Dev (kickoff autonome) + QA (review & coaching)

L'évolution vers l'autonomie

Les développeurs ont désormais internalisé la démarche qualité. Ils commencent à faire leurs propres kickoffs, créer leurs propres Testing Notes.

Le rôle du QA évolue :

• Review des Testing Notes créées par les devs
• Ajouter les éléments manqués
• Coacher pour améliorer la qualité des analyses

Ce qui se passe : Développement progressif d'un "Quality Mindset" chez les développeurs.

Retour terrain : C'est le moment magique où les développeurs ne sont plus juste des "codeurs". J'ai observé cette transformation chez un client : les développeurs se sont mis spontanément à animer des sessions de partage sur les techniques de test. La culture qualité était devenue virale.

Signal d'un Stage 5 réussi :

• Les développeurs posent spontanément les questions "what if"
• Ils anticipent les edge cases sans prompting
• Ils challengent les critères d'acceptation pour la qualité

💡 Ce qu'on en retient : L'autonomie ne se décrète pas, elle se construit par étapes progressives.

Stage 6 : No More DoTing - L'axcellence atteinte

Le modèle

Flux : Kickoff (Dev) → Review → Coding/Testing (Dev) → Blitz Testing + Dogfooding → Déploiement

Nouveauté : Tous les tests par les développeurs, QA en pure facilitation

Acteurs : Dev (tout le cycle) + QA (coaching, blitz, innovation)

L'aboutissement

Les développeurs gèrent désormais tout le cycle de test de leurs features. Le "filet de sécurité" QA disparaît.

Nouvelles pratiques introduites :

1. Blitz Testing

• Sessions de 1h time-boxées
• Toute l'équipe (devs, PO, QA, designers, tech writers) teste ensemble
• Objectif : trouver un maximum de bugs en peu de temps
• Esprit : collaboratif, pas inquisiteur

2. Dogfooding

• Utilisation interne des nouvelles features avant production
• Feedback réel des employés Atlassian
• Détection des problèmes d'UX et d'usage réel

Le rôle du QA devient :

• Coach et mentor qualité
• Facilitateur de Blitz Testing
• Innovateur sur les pratiques et outils
• Stratège qualité (métriques, vision long terme)

Résultat : Très peu de défauts ouverts en production.

Retour terrain : J'ai accompagné UNE SEULE équipe jusqu'à ce stage en France. Pourquoi si peu ? Parce que les prérequis sont immenses :

• Culture craftsmanship ultra mature
• Investissement massif en formation (2+ ans)
• Leadership qualité exceptionnel
• Confiance totale dans l'équipe

Avertissement critique : Ce stage n'est PAS obligatoire. Ce n'est PAS un objectif pour toutes les organisations. C'est l'aboutissement pour des contextes très spécifiques.

💡 Ce qu'on en retient : Le Stage 6 est une possibilité, pas une obligation. Beaucoup d'organisations excellentes stagnent au Stage 4 ou 5, et c'est parfait.

Le voyage, pas la destination

Le parcours d'Atlassian en 6 étapes n'est pas un dogme. C'est une feuille de route inspirante qui montre qu'on peut transformer radicalement son approche qualité.

Les 3 leçons essentielles de ce parcours :

1. La transformation est progressive, pas brutale Atlassian a pris plusieurs années. Chaque étape construit sur la précédente. Respectez votre rythme.
2. Chaque étape résout un problème spécifique Stage 0 → problème de couverture → Stage 1 Stage 1 → détection tardive → Stage 2 Stage 2 → manque de perspective → Stage 3 Et ainsi de suite. Avancez quand le problème actuel est résolu.
3. Le Stage 6 n'est pas "mieux" que le Stage 4 C'est juste différent, adapté à un contexte différent. Visez le stage qui correspond à VOTRE réalité, pas à l'idéal théorique.

À quelle étape vous situez-vous aujourd'hui ? Quel est le problème que vous devez résoudre pour passer à la suivante ?

Dans la partie 2 de cet article, nous explorerons les 5 pratiques clés qui font le succès d'Atlassian, les facteurs de succès, et surtout : ce que VOUS pouvez appliquer dès demain dans votre contexte.

FAQ - Vos questions sur les 6 stages

À quelle étape devrais-je commencer si je pars de zéro ?

Ne partez jamais du Stage 0. Même si vous n'avez aucune pratique QA aujourd'hui, commencez directement au Stage 1 (introduction d'un rôle QA avec test exploratoire). Le Stage 0 est un état observé chez Atlassian à un moment T, pas un point de départ recommandé.

Si vous avez déjà une QA traditionnelle, vous êtes probablement au Stage 1. Votre prochain objectif : Stage 2 (DoT).

Peut-on sauter des étapes pour aller plus vite ?

Non. Absolument pas.

Chaque stage construit les compétences et la culture nécessaires au suivant. Sauter une étape, c'est comme construire le 3ème étage sans avoir posé les fondations du 2ème.

J'ai vu 5 organisations tenter de sauter des étapes. Les 5 ont échoué et dû revenir en arrière, perdant 6-12 mois dans le processus.

La seule exception : Si vous avez déjà certaines pratiques en place (ex: vous faites déjà du pairing dev/QA), vous pouvez être "entre deux stages". C'est normal.

Combien de temps rester à chaque étape avant de passer à la suivante ?

Il n'y a pas de durée fixe. Passez à l'étape suivante quand :

✅ Le problème du stage actuel est résolu

✅ Les pratiques sont adoptées naturellement (pas forcées)

✅ Les métriques montrent une amélioration stable

✅ L'équipe est confortable et demande "la suite"

Signes qu'il faut rester plus longtemps : ❌ Résistance de l'équipe aux pratiques ❌ Métriques qui stagnent ou régressent ❌ Pratiques faites "pour faire", sans conviction

Mieux vaut 6 mois au Stage 3 bien maîtrisé que de rusher au Stage 4 bancal.

Les 6 stages sont-ils applicables à tous les types de produits ?

Pas nécessairement.

Fonctionnent bien pour :

• ✅ Produits SaaS avec itérations fréquentes
• ✅ Applications web/mobile
• ✅ Produits internes d'entreprise
• ✅ Contextes agiles/DevOps

Moins adaptés pour :

• ⚠️ Logiciels embarqués critiques (aéronautique, médical)
• ⚠️ Systèmes hautement régulés avec validation externe obligatoire
• ⚠️ Produits avec cycles de release très longs (>6 mois)

Dans ces contextes, adaptez les principes plutôt que copier les stages.

Mon équipe est au Stage 3, mais certains développeurs refusent de tester. Que faire ?

C'est normal. Voici la stratégie en 4 temps :

1. Identifiez la cause de la résistance

• Manque de compétence ? → Formation
• Manque de temps ? → Ajuster les estimations
• Manque de confiance ? → Pairing intensif avec QA
• Résistance culturelle ? → Discussion avec le manager

2. Commencez petit Ne forcez pas tout le monde en même temps. Trouvez 1-2 développeurs volontaires, montrez les résultats.

3. Mesurez et communiquez "Depuis que Paul teste ses stories, il passe 60% moins de temps en correction de bugs." Les données convaincent.

4. Donnez du temps Le changement de mindset prend 3-6 mois minimum. Soyez patient.

Si après 6 mois un développeur refuse toujours, posez la question du fit culturel avec le manager.

Faut-il atteindre le Stage 6 pour être considéré comme "mature" ?

Absolument pas !

Le Stage 6 est l'aboutissement pour des contextes très spécifiques (culture qualité extrême, investissement formation massif, produits itératifs).

Beaucoup d'organisations excellentes se stabilisent au Stage 4 ou 5, et c'est parfait. Voici comment choisir votre "

Références et Sources

Sources principales

• Shift Op Solutions - Quality Assistance
• QE Unit - Atlassian - From Quality Assurance to Quality Assistance
• Atlassian - The Top Quality Assistance Skills and How To Develop Them

Cet article est le 3ème d'une série de 7 publications sur la Quality Assistance. Dans le prochain épisode : découvrez comment Netflix a poussé le concept encore plus loin avec "You build it, you run it" et le Chaos Engineering.

Plus d’articles comme celui-ci