Encore un pic de trafic
à croiser les doigts ?

Pour que l'IA soit pertinente sur ta stratégie de test, il faut un travail préalable très solide : une architecture documentée, un historique d'incidents structuré, des SLO posés, des parcours critiques identifiés. Souvent, ce travail de fond n'a pas été fait.

L'atelier contourne cette étape. Avec le recul d'un spécialiste et les bonnes personnes dans la pièce, on prend en 4 heures les décisions stratégiques qui auraient demandé des mois de documentation. L'IA, c'est ce qui te fera passer à l'échelle sur l'exécution ensuite. Mais poser la stratégie, c'est rarement l'étape qu'elle franchit bien toute seule.

Tu repars avec une stratégie documentée, un plan d'exécution avec owners et deadlines, une analyse de risques, l'enregistrement complet de la séance, et une restitution aux équipes. C'est le travail qu'un consultant facture 5 à 8 jours pour produire, compressé en une après-midi parce que les décideurs sont dans la pièce.

Et c'est moins que ta prochaine journée d'indisponibilité.

Surtout, tu repars avec un groupe qui a décidé ensemble et qui portera le plan. Pas juste un slide deck.

4 heures d'atelier + une heure de préparation. 5 heures au total.

Tu sors avec une stratégie, des priorités et un plan d'action auquel le groupe adhère et qu'il porte. Le format est conçu pour tenir dans une demi-journée, même sur un planning chargé.

Ton CTO a 40 sujets sur le feu. La performance, c'est le truc qu'on reporte jusqu'à ce que ça pète.

L'atelier force la décision collective en une session : on sort avec un plan porté par tout le groupe, pas avec un ticket Jira que personne ne priorise.

C'est exactement pour ça que l'atelier existe.

Si tes tests n'ont rien donné, c'est un problème de stratégie, pas un problème d'outils. On repart de zéro sur ce qui compte : quel risque business tu couvres, et comment tu le mesures.

J'ai travaillé avec la SNCF comme avec des équipes de 3 devs. La méthode est la même : on identifie le parcours critique, on pose des objectifs réalistes, on priorise.

Moins tu as de moyens, plus tu as besoin de viser juste.

Tu repars avec un plan d'action détaillé, avec owners et deadlines. Pas une liste de bonnes intentions.

Si tu es bloqué sur l'exécution, on peut en parler : un accompagnement à la suite est possible. Mais l'objectif est que tu sois autonome.

5 personnes max de ton entreprise. Tu as besoin de l'architecte qui connaît les limites du système, du lead dev qui sait où le code a été bâclé par manque de temps, du QA ou SRE qui voit les incidents passer, et du représentant métier qui sait quel parcours rapporte le cash.

Le CTO ou Engineering Manager qui porte le budget ferme le groupe. Chaque profil apporte une pièce que les autres n'ont pas.

Le point clé : le groupe sort avec une décision collective, pas une recommandation qu'il faut encore faire valider.

Tu commences par ce qui te coûte cher quand ça tombe, pas par ce qui est facile à scripter. Dans l'ordre : les parcours critiques, une volumétrie cible et un SLO par parcours, puis un MoSCoW sur les types de tests. Ce qui n'est pas en « Must » attend.

Et une question que la plupart des équipes n'ont jamais tranchée à voix haute : qu'est-ce qu'on décide de ne pas tester. C'est celle qui fait gagner le plus de temps.

2 500 € HT, quel que soit le nombre de participants, jusqu'à 5 personnes d'une même entreprise. 4 heures, en présentiel ou en visio. Le prix couvre la préparation, la session et les livrables formalisés sous 15 jours : stratégie, plan d'exécution, analyse des risques, plan d'action, enregistrement complet. Les décisions sont actionnables dès la fin de l'atelier.

L'appel préparatoire (jusqu'à 60 minutes) qui précède est offert. Je ne prends que deux ateliers par mois.