Scaler l'Agile Sans SAFe : Approches Légères pour les Organisations d'Ingénierie en Croissance
Voici un pattern que j'ai vu se jouer au moins une douzaine de fois. Une startup passe d'une équipe à trois ou quatre. La coordination devient chaotique. Quelqu'un propose SAFe (Scaled Agile Framework) comme solution. Six mois plus tard, l'organisation d'ingénierie se noie dans les cérémonies de PI Planning, les Agile Release Trains et des définitions de rôles que personne ne peut retenir. Les ingénieurs passent plus de temps en réunions d'alignement qu'à écrire du code.
SAFe résout un vrai problème. Mais pour la plupart des organisations d'ingénierie entre 20 et 50 ingénieurs, c'est la mauvaise solution — un framework conçu pour des entreprises avec des centaines d'ingénieurs, entassé dans une organisation à moyenne échelle.
Le Vrai Problème que SAFe Essaie de Résoudre
Soyons justes envers SAFe en nommant ce qu'il adresse. Quand vous passez d'une équipe à plusieurs équipes, vous rencontrez des problèmes de coordination qui n'existaient pas avant :
- Des dépendances entre équipes. L'Équipe A ne peut pas livrer sa fonctionnalité avant que l'Équipe B termine l'API dont elle a besoin. Personne ne le découvre avant le dernier jour du sprint.
- Des priorités conflictuelles. L'équipe produit dit au Squad 1 que la fonctionnalité X est urgente, tandis que le Squad 2 travaille sur l'infrastructure dont dépend la fonctionnalité X — mais personne n'a fait le lien.
- Des codebases et services partagés. Plusieurs équipes déployant vers les mêmes services, parfois en écrasant les changements de l'autre ou en causant des régressions inattendues.
- L'alignement stratégique. Chaque équipe optimise pour son propre backlog sans comprendre comment leur travail se connecte aux objectifs trimestriels de l'entreprise.
Ce sont de vrais problèmes. Je les ai tous vécus. La question n'est pas de savoir si vous devez les adresser. C'est de savoir combien de surcharge processus est justifiée pour la taille de votre organisation.
Pourquoi SAFe Dépasse la Cible à Moyenne Échelle
SAFe introduit une structure massive : les Program Increments, les Agile Release Trains, les Release Train Engineers, les System Demos, les Solution Trains et toute une taxonomie de rôles et de cérémonies. Pour une organisation de 200 ingénieurs dans la santé ou la finance, peut-être justifié. Pour une startup de 30 ingénieurs avec quatre squads ? Voici pourquoi c'est absurde :
La surcharge cérémoniale est brutale. Le PI Planning seul est un événement de deux jours tous les 8-12 semaines. Ajoutez la préparation, le suivi et les cérémonies continues, et vous avez ajouté des jours de réunions par trimestre dans le calendrier de chaque ingénieur.
La prolifération des rôles ajoute des coûts sans valeur. Release Train Engineer, Solution Architect, Epic Owners — dans une organisation de 30 personnes, ces rôles n'existent pas ou sont occupés par des personnes déjà surchargées.
Ça optimise la prévisibilité plutôt que la vitesse. S'engager dans des PI de 10 semaines nuit activement à votre capacité à répondre aux retours du marché.
Ça décourage la communication informelle. "C'est un sujet du Scrum of Scrums" devient une excuse pour ne pas envoyer un message Slack à la personne qui peut vous débloquer maintenant.
L'Alternative Légère : Ce qui Fonctionne Vraiment
J'ai vu les approches suivantes bien fonctionner pour les organisations dans la tranche 20-50 ingénieurs. Elles résolvent les mêmes problèmes de coordination avec une fraction de la surcharge.
Sync Inter-Équipes Hebdomadaire (30 minutes)
Un représentant de chaque équipe rejoint une réunion hebdomadaire. L'agenda est simple :
- Qu'est-ce que vous livrez cette semaine ? (2 minutes par équipe)
- Qu'est-ce qui vous bloque de la part d'une autre équipe ? (faire remonter les dépendances)
- Qu'est-ce qui change et que les autres devraient savoir ? (services partagés, changements d'API, mises à jour d'infrastructure)
C'est tout. Pas de rapports d'avancement. Pas de pourcentages de progression. Si quelque chose nécessite une discussion plus approfondie, planifiez un suivi. Le sync sert à faire remonter, pas à résoudre.
Atelier Trimestriel de Cartographie des Dépendances (demi-journée)
Une fois par trimestre, les tech leads et les product managers cartographient le travail prévu du prochain trimestre sur un tableau partagé. Pas un plan détaillé — une carte approximative des dépendances. Vous cherchez : deux équipes modifiant le même service, des fonctionnalités dépendant de travaux non priorisés, une infrastructure partagée que personne ne possède.
C'est le noyau utile du PI Planning, dépouillé de la cérémonie. Une demi-journée au lieu de deux jours. Notez les dépendances sur un tableau Miro, assignez des propriétaires, passez à autre chose.
Reviews de Sprint Conjointes
Au lieu que chaque équipe fasse sa sprint review en isolation, faites une session de démo partagée toutes les deux semaines (ou mensuellement, selon votre cadence). Chaque équipe montre ce qu'elle a livré. L'audience, ce sont les autres équipes.
Ça fait trois choses :
- Construit une compréhension partagée. Les ingénieurs voient sur quoi travaillent les autres équipes et comment le produit se connecte.
- Crée une coordination informelle. "Oh, vous construisez ça ? Nous avons un besoin similaire — parlons-en après."
- Élève la qualité. Quand vous savez que d'autres ingénieurs verront votre travail, vous êtes plus intentionnel sur ce que vous livrez.
Gardez ça serré. 10 minutes par équipe, maximum. Si les démos s'allongent, elles cessent d'être utiles.
Backlogs Partagés pour le Travail de Plateforme
Si plusieurs équipes dépendent d'une infrastructure partagée, créez un backlog de plateforme auquel n'importe quelle équipe peut contribuer. Vous n'avez pas encore besoin d'une équipe de plateforme dédiée. Mais vous avez besoin d'une liste visible et priorisée du travail de plateforme pour qu'il ne se perde pas dans le backlog de fonctionnalités de chaque équipe. Assignez un propriétaire — généralement un ingénieur senior ou un tech lead — pour prioriser et s'assurer que le travail est pris en charge.
Rituels Inter-Squads
Deux pratiques légères qui rapportent des dividendes disproportionnés :
Tech talks. Toutes les deux semaines, un ingénieur présente quelque chose pendant 20-30 minutes. Un nouvel outil, une décision architecturale, un incident de production. Diffuse la connaissance et construit des relations inter-équipes.
Partenaires de review rotatifs. Assignez des reviewers inter-équipes pour les PRs qui touchent les services partagés. Ça détecte les problèmes d'intégration tôt et construit une familiarité inter-équipes.
Quand SAFe a Réellement du Sens
Je ne suis pas contre SAFe de manière catégorique. Il y a des contextes où la surcharge est justifiée :
- Très grandes organisations (100+ ingénieurs) où la coordination informelle ne peut physiquement pas passer à l'échelle
- Industries réglementées où les pistes d'audit, la traçabilité et la planification documentée sont des exigences de conformité
- Entreprises multi-produits où différentes unités commerciales ont besoin de coordonner leurs releases
- Organisations avec une faible maturité d'ingénierie où les équipes ont besoin de plus de structure, pas moins (bien que j'arguerais qu'il y a de meilleurs points de départ que SAFe)
Mais si vous êtes une startup ou scale-up avec 20-50 ingénieurs et 3-6 équipes, vous n'en avez presque certainement pas besoin.
Le Principe Derrière Tout Ça
Le principe sous-jacent est simple : la coordination devrait être aussi légère que la complexité l'exige et pas plus lourde. Commencez avec le processus minimum viable. S'il se casse, ajoutez de la structure. S'il tient, laissez-le tranquille.
La bonne question n'est pas "quel processus devrions-nous adopter ?" C'est "quelle est la quantité minimale de coordination qui nous permet de livrer sans casser le travail de chacun ?"
Chez Conectia, les équipes que nous construisons pour les startups européennes et américaines rejoignent souvent exactement ce stade de croissance — trois à cinq squads qui essaient de comprendre comment se coordonner. Nos ingénieurs seniors LATAM ont l'expérience de travailler dans des configurations distribuées multi-équipes, et ils apportent des patterns pratiques de coordination qui ne nécessitent pas d'adopter un framework d'entreprise pour fonctionner.
Vous faites évoluer votre organisation d'ingénierie et avez besoin d'ingénieurs qui savent travailler entre équipes ? Parlez à un CTO — nos ingénieurs seniors s'intègrent dans des configurations multi-squads et apportent l'expérience de coordination dès le premier jour.
