Atlassian , le Pionner : Les pratiques et facteurs de succès

Article 3B/8 - Série complète sur la Quality Assistance - Partie 2/2

Bienvenue dans la Partie 2 !

Dans la partie 1, nous avons exploré le voyage d'Atlassian en 6 étapes, du Stage 0 (automatisation seule) au Stage 6 (excellence totale).

Maintenant, place à l'action !

Dans cette partie 2, vous allez découvrir :

• Les 5 pratiques concrètes qui font le succès d'Atlassian
• Les facteurs critiques de réussite (pourquoi ça a marché chez eux)
• Les limites du modèle (ce qu'on ne vous dit pas)
• Les quick wins à appliquer dès demain chez vous

Si vous n'avez pas lu la partie 1, je vous recommande de commencer par là pour comprendre le contexte des 6 stages. Mais si vous êtes pressé d'actionner, allons-y directement !

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.

Rappel Éclair : Les 6 stages en 30 secondes ⚡

Pour ceux qui arrivent directement ici, voici l'essentiel du parcours Atlassian :

Stage 0 : Automatisation seule (limites découvertes)

Stage 1 : Ajout QA avec test exploratoire (bugs détectés trop tard)

Stage 2 : Developers on Test / DoT (manque de perspective)

Stage 3 : QA Demos + Testing Notes (prévention commence) ✨

Stage 4 : QA Kickoffs avant code (prévention >> détection) 🎯

Stage 5 : Kickoffs autonomes des devs (quality mindset)

Stage 6 : Blitz Testing + Dogfooding (excellence atteinte)

Maintenant, plongeons dans les pratiques qui font que ça marche !

Les 5 pratiques clés qui font le Succès d'Atlassian

Au-delà des 6 stages, Atlassian a développé 5 pratiques concrètes qui constituent leur ADN qualité.

1. QA Coaches - L'évolution du rôle

Ancien rôle : Testeur, valideur, gatekeeper

Nouveau rôle : Coach, enabler, facilitateur

Les 6 compétences clés développées :

a) Influence - Convaincre l'équipe d'embracer la responsabilité qualité partagée (avec des faits, pas des opinions)

b) Expertise test - Identifier rapidement les risques, proposer des stratégies de test adaptées

c) Éducation - Former les développeurs aux techniques de test, cultiver le "QA mindset"

d) Inspiration - Rendre le test fun, challengeant, valorisant (pas une corvée)

e) Facilitation - Organiser les rituels qualité, définir les quality bars, créer les environnements de test

f) Identification de problèmes - Détecter les problèmes systémiques, proposer des améliorations

Retour terrain : Quand j'ai formé mes premiers QA Coaches, la difficulté n'était pas technique. C'était d'accepter de lâcher le contrôle. Un excellent testeur n'est pas automatiquement un bon coach. Il faut développer les soft skills.

2. QA Demos - Le rituel qui change tout

Format : 15-30 minutes, après implémentation

Participants : Développeur + QA (minimum)

Déroulé :

1. Le dev démontre l'implémentation
2. Le QA pose des questions de clarification
3. Discussion sur les risques identifiés
4. Co-création ou mise à jour des Testing Notes

Pourquoi ça marche :

• Feedback immédiat (code encore frais)
• Détection des malentendus avant qu'ils ne coûtent cher
• Montée en compétence continue du dev
• Création d'un langage commun qualité

3. Testing Notes - La mémoire collective

Nature : Documentation collaborative vivante

Contenu :

• Scénarios de test identifiés ( sans rentrer dans les détails)
• Risques et edge cases
• Stratégies de test recommandées
• Résultats des tests effectués

Bénéfices :

• Transparence totale sur la couverture de test
• Base de connaissance pour l'équipe
• Outil d'onboarding pour nouveaux arrivants
• Traçabilité des décisions qualité

Retour terrain : Les Testing Notes sont souvent sous-estimées. Dans une équipe distribuée que j'accompagnais, elles sont devenues l'outil de communication asynchrone #1 sur la qualité. Même les PO les consultaient pour comprendre la complexité technique.

4. Blitz Testing - L'intelligence collective

Format : Session time-boxée (généralement 1h)

Participants : Toute l'équipe (devs, QA, PO, designers, tech writers, etc.)

Objectif : Tester intensivement une feature de manière collaborative

Déroulé :

1. Briefing rapide (5 min) : contexte, focus, objectifs
2. Test collaboratif (45 min) : chacun explore librement
3. Débrief (10 min) : partage des découvertes, priorisation

Pourquoi c'est puissant :

• Multiplicité de perspectives (un designer voit des choses qu'un dev ne voit pas)
• Détection rapide de problèmes variés
• Renforcement de la culture qualité partagée
• C'est ludique et engageant

Retour terrain : La première fois que j'ai organisé un Blitz Testing, l'équipe était sceptique : "On n'a pas le temps." Une heure plus tard : 17 bugs trouvés, dont 3 bloquants. Ils n'ont plus jamais remis en question l'utilité.

5. Dogfooding - La validation ultime

Principe : "Eat your own dog food" = Utiliser vos propres produits avant de les livrer

Chez Atlassian :

• Les employés utilisent les nouvelles features en interne avant release
• Feedback réel sur l'usage quotidien
• Détection des problèmes d'UX et d'adoption

Bénéfices :

• Tests en conditions réelles (pas en lab)
• Feedback qualitatif sur l'expérience utilisateur
• Détection des problèmes d'intégration avec l'écosystème
• Culture produit renforcée

💡 Ce qu'on en retient : Ces 5 pratiques sont indépendantes des 6 stages. Vous pouvez les implémenter dès maintenant, quel que soit votre niveau de maturité.

Les facteurs de succès : pourquoi ça a marché chez Atlassian ?

Atlassian n'a pas réussi par hasard. Plusieurs facteurs critiques ont permis cette transformation.

1. Standards qualité clairs

Définition explicite de ce qu'est la qualité pour Atlassian : "Quality at Speed"

Principes communiqués à toute l'organisation, pas juste à la QA

Pourquoi c'est critique : Sans définition commune de la qualité, chacun a sa propre interprétation. Le PO veut de la rapidité, le dev veut du code propre, le QA veut zéro bug. Conflit assuré.

Retour terrain : Dans une mission, j'ai passé 2 jours à faire définir par l'équipe "C'est quoi la qualité pour nous ?" Une fois d'accord, 90% des conflits qualité/vélocité ont disparu.

2. Programmes de formation extensifs

Investissement massif dans la formation continue :

• Formation technique (Techniques de tests, automatisation, architecture de test)
• Formation soft skills (communication, influence, facilitation)
• Coaching individuel et collectif

Pourquoi c'est critique : On ne devient pas QA Coach du jour au lendemain. On ne devient pas développeur-testeur sans formation. La transformation nécessite un investissement massif en compétences.

Retour terrain : C'est ce qui manque dans 90% des transformations que j'observe. On annonce le changement, on crée de nouveaux rôles, mais on ne forme pas. Résultat : échec programmé.

L'erreur classique : "Ils sont intelligents, ils vont comprendre tout seuls."

La réalité : Sans formation, ils vont recréer l'ancien modèle avec de nouveaux noms.

3. Sponsorship exécutif fort

Leadership visible du management sur la transformation qualité

Budget alloué pour la formation, les outils, l'expérimentation

Communication régulière sur les progrès et les ajustements

Pourquoi c'est critique : Sans sponsorship, la transformation qualité sera sacrifiée à la première deadline serrée. "On fera la QA Demo plus tard, là il faut livrer."

Votre CEO/CTO peut-il expliquer en 2 minutes votre vision qualité ? Si non, vous n'avez pas de sponsorship réel.

4. Culture du dogfooding

Usage systématique des produits en interne

Feedback loop court entre les équipes et les utilisateurs

Pourquoi c'est critique :

Cela crée une empathie naturelle avec l'utilisateur final. Les équipes ne développent plus "pour les autres", mais "pour nous".

5. Mesures et outcomes clairs

QE NPS (Net Promoter Score) : Mesure de satisfaction des équipes sur le support qualité

Quality Health Monitor (QHM) : Atelier collaboratif pour évaluer la santé qualité des équipes

Lequel de ces 5 facteurs manque chez vous aujourd'hui ? C'est peut-être votre point de blocage.

Pourquoi c'est critique : "Ce qui ne se mesure pas ne s'améliore pas." Sans métriques, impossible de savoir si la transformation fonctionne.

Retour terrain : Un client a implémenté un mini-NPS qualité. Premier score : 4/10. Ils ont identifié les problèmes, ajusté, et 6 mois plus tard : 8/10. Les données ont guidé toute leur amélioration.

💡 Ce qu'on en retient : Ces 5 facteurs ne sont pas optionnels. Ce sont les fondations sur lesquelles les 5 pratiques peuvent s'épanouir.

Les limites et le contexte : ce qu'on ne vous dit pas

Soyons honnêtes : Atlassian n'est pas une PME française. Leur contexte est spécifique, et copier-coller leur modèle serait une erreur.

Les avantages contextuels d'Atlassian

1. Culture remote-first mature

• Collaboration asynchrone maîtrisée
• Outils de communication avancés
• Documentation extensive

Chez vous ? Si vous êtes en mode bureau obligatoire avec des réunions à tout-va, le modèle Atlassian nécessitera des ajustements.

2. Budget conséquent

• Investissement massif en formation
• Temps alloué pour l'expérimentation
• Recrutement de talents seniors.

Chez vous ? Si votre budget formation est de 2 jours/an, vous devrez être plus créatif (pair learning, communautés de pratiques, etc.).

3. Produits SaaS avec forte itération

• Feedback loops courts
• Possibilité de rollback rapide
• Culture d'expérimentation assumée

Chez vous ? Si vous livrez un logiciel on-premise tous les 6 mois, le modèle devra être adapté.

4. Taille d'organisation

• Ressources pour créer des rôles spécialisés
• Communautés de pratiques viables
• Effet réseau sur l'apprentissage

Chez vous ? Si vous avez 2 QA pour 20 développeurs, le modèle QA Coach transverse sera plus adapté que le QA intégré.

Ce que ça signifie pour vous

❌ Ne copiez pas aveuglément le modèle Atlassian

✅ Inspirez-vous de leurs principes et adaptez à votre contexte

❌ Ne visez pas le Stage 6 si votre contexte ne le permet pas

✅ Progressez étape par étape, célébrez chaque victoire

❌ Ne vous comparez pas à Atlassian sur la vitesse de transformation ✅ Comparez-vous à vous-même il y a 3 mois

Retour terrain : J'ai vu une scale-up française tenter d'implémenter le Stage 6 directement. Résultat : chaos, démotivation, retour en arrière brutal. Ils ont repris au Stage 2, avancé progressivement, et aujourd'hui ils excellent au Stage 4. C'était le bon niveau pour eux.

Ce que vous pouvez appliquer dès demain

Assez de théorie. Passons à l'action. Voici les 3 quick wins à implémenter immédiatement.

Quick Win #1 : Introduire les QA Demos (Difficulté : Facile | Impact : Élevé)

Action concrète :

1. Choisissez 1-2 stories de votre prochain sprint
2. Planifiez une QA Demo de 20 minutes après implémentation
3. Format : Dev démontre, QA questionne, co-création des Testing Notes
4. Mesurez : nombre de bugs évités, temps de cycle

Résultat attendu en 2 semaines :

• Réduction de 20-30% des allers-retours dev/QA
• Meilleure compréhension mutuelle

Quick Win #2 : Créer des Testing Notes Collaboratives (Difficulté : Facile | Impact : Moyen)

Action concrète :

1. Créez un template simple (Confluence, Notion, Wiki)
2. Sections : Risques identifiés | Scénarios de test | Résultats
3. Remplissez collaborativement lors des QA Demos
4. Rendez visible et accessible à toute l'équipe

Résultat attendu en 1 mois :

• Documentation vivante de la couverture de test
• Onboarding facilité pour nouveaux arrivants
• Base de connaissance qualité émergente

Quick Win #3 : Lancer un Premier Blitz Testing (Difficulté : Moyenne | Impact : Élevé)

Action concrète :

1. Identifiez une feature récemment déployée (ou sur le point de l'être)
2. Bloquez 1h dans l'agenda de toute l'équipe
3. Briefing 5 min → Test libre 45 min → Débrief 10 min
4. Documentez les bugs trouvés, priorisez

Résultat attendu immédiat :

• Détection de 10-20 bugs en 1h
• Effet "waouh" sur l'équipe (adhésion au concept)
• Culture qualité collaborative renforcée

L'inspiration, pas l'imitation 🌟

Le parcours d'Atlassian est fascinant. En 15 ans, ils ont complètement réinventé le métier du test logiciel et prouvé qu'on peut allier vitesse et qualité.

Les 3 leçons essentielles :

1. La transformation qualité est un voyage, pas une destination Atlassian a mis des années à progresser. Respectez votre rythme.
2. Chaque organisation doit adapter le modèle à son contexte Votre Stage 3 n'est pas le Stage 3 d'Atlassian. Et c'est OK.
3. Les pratiques valent plus que les structures QA Demos, Testing Notes, Blitz Testing = applicable partout, dès maintenant.

À quelle étape vous situez-vous aujourd'hui ? Où voulez-vous être dans 6 mois ?

Dans le prochain article, nous découvrirons une approche encore plus radicale : celle de Netflix avec leur philosophie "You build it, you run it". Préparez-vous à explorer un monde sans équipe QA centralisée, où le Chaos Engineering devient la norme.

FAQ - Vos questions, Nos réponses

Les 5 pratiques sont-elles obligatoires ou peut-on en choisir certaines seulement ?

Vous pouvez absolument les implémenter de manière sélective !

Recommandation minimale pour un impact :

• ✅ QA Demos (indispensable, le plus gros ROI)
• ✅ Testing Notes (complète naturellement les Demos)

Ajoutez ensuite selon votre contexte :

• QA Coaches → Si vous avez des QA à faire évoluer
• Blitz Testing → Si vous avez des features complexes et une équipe engagée
• Dogfooding → Si votre produit peut être utilisé en interne

Aucune pratique n'est "obligatoire". Choisissez celles qui résolvent VOS problèmes.

Combien de temps pour voir des résultats concrets avec les QA Demos ?

Résultats visibles dès 2-3 semaines :

• Réduction des allers-retours dev/QA
• Moins de malentendus sur les stories
• Meilleure ambiance dev/QA

Résultats mesurables à 1-2 mois :

• Réduction de 20-30% des bugs en review
• Cycle time amélioré
• Satisfaction équipe en hausse

Transformation culturelle à 3-6 mois :

• Pratique naturelle, pas forcée
• Développeurs qui demandent spontanément les demos
• Qualité du dialogue dev/QA transformée

La clé : consistance. Faites-le sur TOUTES les stories pendant 2 mois avant de juger.

Le Blitz Testing ne va-t-il pas ralentir l'équipe en mobilisant tout le monde pendant 1h ?

C'est un investissement, pas un coût.

Calcul simple :

• 1h de Blitz Testing avec 6 personnes = 6h investies
• Bugs trouvés : 15 en moyenne (dont 3 critiques)
• Si 1 seul bug critique atteint la prod : 10-20h de correction + urgence + stress

ROI = largement positif

De plus :

• ✅ Team building (effet secondaire positif)
• ✅ Montée en compétence collective
• ✅ Culture qualité renforcée

Retour terrain : Aucune équipe n'a jamais abandonné le Blitz Testing après l'avoir testé. C'est la preuve que ça apporte de la valeur.

Peut-on faire des QA Demos en asynchrone pour une équipe distribuée ?

Oui, mais avec des ajustements.

Version asynchrone :

1. Le dev enregistre une vidéo de démo (5-10 min)
2. Le QA la regarde, note ses questions
3. Session synchrone courte (10-15 min) pour discussion
4. Co-création des Testing Notes en async

Avantages :

• ✅ Fonctionne avec décalage horaire important
• ✅ La vidéo devient documentation
• ✅ Le QA peut la regarder plusieurs fois

Inconvénients :

• ❌ Moins de spontanéité
• ❌ Nécessite discipline (faire vraiment la vidéo)
• ❌ Feedback légèrement différé

Ma recommandation : Privilégiez le synchrone quand possible (même en visio), passez en asynchrone seulement si vraiment nécessaire.

Les Testing Notes ne vont-elles pas devenir de la bureaucratie inutile ?

Elles le deviennent SI vous les transformez en contrainte administrative.

Signes de bureaucratie :

• ❌ Template de 3 pages avec 20 champs obligatoires
• ❌ Validation formelle par un comité qualité
• ❌ Remplissage "pour faire plaisir au process"
• ❌ Personne ne les relit jamais

Comment éviter ça :

• ✅ Template ultra-simple (1 page, 5 sections max)
• ✅ Remplissage collaboratif (pas solo par le QA)
• ✅ Utiles immédiatement (pas juste archivage)
• ✅ Évolutives (on peut les améliorer)

Test de viabilité : Si un développeur dit "Les Testing Notes m'ont aidé à comprendre comment tester", c'est gagné. Si il dit "Encore de la paperasse...", c'est raté.

Comment convaincre les développeurs de participer au Blitz Testing s'ils disent "pas le temps" ?

Stratégie en 3 temps :

1. Rendez le premier obligatoire (avec sponsorship manager) "On teste pendant 1h, puis on décide si on continue"

2. Rendez-le fun et ludique

• 🎮 Gamification : "Qui trouve le bug le plus original ?"
• 🍕 Snacks et ambiance détendue
• 🏆 Célébration des découvertes

3. Montrez les résultats immédiatement "On a trouvé 3 bugs bloquants en 1h. Imaginez si ça avait explosé en prod..."

Retour terrain : Après le 1er Blitz, 90% des développeurs sceptiques deviennent fans. L'expérience convaincra mieux que les arguments.

Le Dogfooding fonctionne-t-il pour des produits B2B très spécialisés ?

Ça dépend, mais il y a toujours une forme de dogfooding possible.

Si votre produit peut être utilisé en interne :

• ✅ Utilisez-le pour vos propres besoins (ex: outil de gestion de projet pour gérer vos projets)
• ✅ Impact maximal

Si votre produit est trop spécialisé :

• ⚙️ Internal demo program : Présentez les features à des équipes non-tech, récoltez feedback
• ⚙️ Shadow users : Observez vos clients (avec permission) utiliser le produit
• ⚙️ Beta clients internes : Si vous avez plusieurs entités, l'une peut tester pour l'autre

Si vraiment impossible :

• Focus sur les autres pratiques (Blitz Testing compense bien)

L'esprit du dogfooding, c'est "valider en usage réel". Trouvez la forme adaptée à votre contexte.

Faut-il des outils spécifiques pour mettre en place ces pratiques ?

Non ! Commencez avec ce que vous avez.

Pour les QA Demos :

• Outil : Aucun (juste se parler)
• Optionnel : Visio si remote

Pour les Testing Notes :

• Minimum : Google Doc, Wiki, Confluence, Notion
• Idéal : Intégration dans votre outil de ticketing (JIRA, etc.)

Pour le Blitz Testing :

• Minimum : Google Doc partagé pour noter les bugs
• Mieux : Miro/Mural pour collaboration visuelle
• Idéal : Outil de bug tracking rapide

Pour mesurer (QE NPS, métriques) :

• Minimum : Google Forms + spreadsheet
• Mieux : Outil de sondage (Typeform, SurveyMonkey)

La règle d'or : Les outils suivent les pratiques, pas l'inverse. Ne perdez pas 3 mois à chercher l'outil parfait. Commencez avec ce que vous avez, améliorez ensuite.

Cet article est le 3B/8 de la série sur la Quality Assistance (Partie 2/2). Dans le prochain article, nous explorerons Netflix et leur philosophie "You build it, you run it" - une approche encore plus radicale où les développeurs gèrent absolument tout !

📌 Lire la Partie 1 : Atlassian : Le Voyage en 6 Étapes vers la Quality Assistance

📌 Article précédent : Les 4 Modèles Organisationnels de la Quality Assistance

📌 Article suivant : Netflix : You Build It, You Run It (à paraître)

📌 Article 1 : Qu'est-ce que la Quality Assistance ?

Plus d’articles comme celui-ci