Features Teams vs Components Teams

Pivoter d'une organisation par compétence à une organisation par valeur : retour d'expérience

Dans la tech, on parle beaucoup de stack, de méthodologie, de tooling. On parle peu de la chose qui pèse le plus sur la vélocité d'une équipe : sa structure. J'ai vu des organisations doubler ou tripler leur productivité sans changer de développeurs, sans changer d'outils, sans embaucher. En changeant juste comment les gens étaient regroupés.

Le contexte : une startup logistique panafricaine

Je vais m'appuyer sur un cas concret. Une startup franco-africaine de logistique sur laquelle j'ai travaillé. Sans la nommer, voici son ADN. L'entreprise opérait un service de livraison de colis du bout du monde jusqu'au fond d'un village d'Abidjan. Le pari était simple sur le papier, complexe dans la réalité : utiliser un réseau de points relais et de nœuds physiques en partenariat avec les compagnies de bus inter-urbains comme infrastructure de transport. Pas de flotte propre, pas d'entrepôts géants. Un modèle léger, asset-light, calibré pour la réalité africaine : routes difficiles, adresses imprécises, connectivité intermittente, paiement majoritairement cash.

Le système reposait sur trois produits techniques distincts :

Produit	Utilisateur	Contrainte
App mobile agent (Android)	Agents au point relais qui créent les colis	Doit fonctionner offline, en mode dégradé, et faire un bulk sync vers le cloud dès que la connexion revient
3 App web manager	Responsables et managers qui supervisent les colis, les flux, les relais	Accès complet, dashboards, traçabilité
Backend / cloud	Toute l'infrastructure	Doit gérer la synchronisation des appareils intermittents, les états de colis, les notifications

L'app Android était volontairement ultra-légère, conforme aux contraintes africaines : smartphones d'entrée de gamme, 2-3 Go de RAM, réseaux 2G/3G fluctuants. Pas de stack moderne lourde, pas de Flutter ou React Native — du natif Android optimisé. L'équipe tech, à mon arrivée, était composée d'une quinzaine de personnes réparties en cinq équipes distinctes : une équipe Android, une équipe Frontend web, une équipe Backend, une équipe QA (Quality Assurance), une équipe UX/Design, et l'équipe Produit qui les coordonnait. Chaque équipe avait son lead, son backlog, ses rituels.

Le problème : des équipes brillantes, une livraison paralysée Sur le papier, l'organisation était logique. Les Android entre eux partageaient les bonnes pratiques. Les backends optimisaient leur architecture. Les QA standardisaient les protocoles de test. Les designers itéraient sur leur design system. En pratique, chaque feature qui touchait à plusieurs surfaces — c'est-à-dire la quasi-totalité des features stratégiques — devenait un cauchemar de coordination. Prenons un exemple réel. Un manager devait pouvoir voir en temps réel les colis enregistrés par les agents au point relais. Feature « dashboard temps réel des colis enregistrés ». Estimation initiale : 3 semaines. Délai réel : 3 mois. Voici pourquoi.

Étape	Équipe	Délai
Spécification produit	Équipe Produit	2 semaines
Mise en backlog Android	Équipe Android	3 semaines d'attente
Mise en backlog Backend (API de sync)	Équipe Backend	2 semaines d'attente
Mise en backlog Frontend (dashboard)	Équipe Frontend	2 semaines d'attente
Synchronisation entre les trois équipes	Réunions de coordination	2 semaines
Mise en backlog QA (préparation des jeux de tests bout en bout)	Équipe QA	2 semaines d'attente
Tests bout en bout (offline, sync, dashboard)	Équipe QA	1 semaine
Allers-retours sur incohérences (le payload Android ne matchait pas le schéma backend)	Re-spécification	2 semaines
Recette UX (le manager web ne voyait pas les bonnes infos)	Re-design	1 semaine
TOTAL		17 semaines

Pour une feature dont le code utile représentait environ 8 jours-homme cumulés. Le pire : pendant ces 3 mois, chaque équipe avait travaillé. Les Android avaient livré leur partie en 2 semaines. Les backends en 2 semaines aussi. Mais ils n'avaient pas livré en même temps, ni avec les mêmes contrats d'API, ni avec les mêmes attentes UX. La QA recevait des morceaux à tester à des moments différents, sans vision d'ensemble, et trouvait inévitablement des incohérences qu'il fallait renvoyer à chaque équipe séparément. C'est le drame des components teams : chaque équipe livre, mais le produit n'avance pas.

Le pivot : ce qu'on a changé Nous avons réorganisé les mêmes 15 personnes en 3 feature teams :

Squad	Mission	Composition
Squad Agent	Tout ce qui touche au parcours agent au point relais : création de colis, scan, sync offline, paiement cash	1 PM, 2 Android, 1 Backend, 1 QA
Squad Web	Tout ce qui touche au parcours manager : dashboard, supervision, reporting, gestion des relais	1 PM, 4 Frontend, 1 Backend, 1 QA
Squad Réseau	Tout ce qui touche à la logique colis : routage, états, notifications, intégration partenaires bus	1 PM, 4 Backend, 1 QA

Trois squads autonomes, chacune avec un objectif business clair :

Squad Agent : maximiser le nombre de colis créés avec succès en mode offline
Squad Manager : réduire le temps moyen de résolution d'un incident colis
Squad Réseau : maximiser le taux de colis livrés dans les délais annoncés

L'UX/Design fonctionnait en support transverse sur les trois squads, avec un designer rattaché à 50% Agent / 50% Manager selon les priorités. À côté, nous avons gardé des chapters :

Chapter Android (tous les devs Android, 1 réunion / semaine)
Chapter Backend (idem)
Chapter QA (idem — critique pour aligner les protocoles de test)
Chapter Frontend (idem)

L'expertise transverse était préservée. La livraison était isolée par squad.

Ce qui a changé concrètement, en 6 mois

1. La vélocité a triplé

Nous sommes passés de 4-6 features livrées par trimestre à 15-18 features par trimestre. Pas parce que les gens travaillaient plus longtemps. Parce qu'ils n'attendaient plus les autres équipes. La fameuse feature « dashboard temps réel des colis », qui avait pris 3 mois en components teams, a été refaite (avec des évolutions) en 9 jours dans le nouveau modèle. La squad Manager possédait le frontend, l'API exposée par le backend, le scénario de test QA, et la spec UX. Pas besoin de négocier avec qui que ce soit.

2. Le rôle du QA a été transformé

C'est l'un des changements les plus sous-estimés du pivot. Avant, les QA recevaient des tickets en bout de chaîne. Ils découvraient les features quand elles étaient « prêtes ». Ils trouvaient des bugs, les renvoyaient aux développeurs, qui les corrigeaient parfois 2 sprints plus tard quand ils avaient le temps. Le QA était une équipe en aval, perçue comme un goulot d'étranglement. Après, le QA était embarqué dans la squad dès le refinement. Il participait à la spécification de chaque story, contribuait à définir les critères d'acceptation, préparait ses jeux de tests en parallèle du développement (et non après). Quand le code arrivait en test, les scénarios étaient déjà prêts. Quand un bug était trouvé, le développeur était à 2 mètres, contexte chargé, capable de corriger dans la journée. Résultat mesuré : le temps moyen entre la détection d'un bug et sa correction est passé de 5 jours à 4 heures. Et un effet secondaire que je n'avais pas anticipé : les développeurs ont commencé à mieux écrire leur code, parce qu'ils savaient que le QA allait poser des questions précises sur les cas limites avant même qu'ils ne commencent à coder. La qualité est montée en amont, pas en aval.

3. Les daily standups sont devenus utiles

Avant, le daily de l'équipe Android ressemblait à ça :

« Hier j'ai bossé sur la sync offline. Aujourd'hui je continue. Pas de blocage. » « Hier j'ai bossé sur le scan QR code. Aujourd'hui je continue. Pas de blocage. » « Hier j'ai bossé sur les notifications push. Aujourd'hui je continue. Pas de blocage. »

Chacun travaillait sur des features différentes, pour des PM différents, avec des QA différents qui testeraient peut-être plus tard. Le daily durait plus de 30 minutes pour produire zéro coordination. Après le pivot, le daily de la Squad Agent ressemblait à ça :

« Hier j'ai terminé la logique de bulk sync côté Android. Le payload est conforme à la spec. » « Top, l'endpoint backend est prêt depuis hier soir, on peut tester ce matin. » « Mes jeux de tests offline sont prêts, je lance la validation cet après-midi. Si tout passe, on ferme la story ce soir. »

12 minutes. Coordination réelle. Décisions prises. Blocages levés. C'est le même rituel. Mais avec une équipe qui partage un objectif commun, il devient un outil de travail. Avec une équipe en silo, c'est un rituel vide.

4. Les sprint plannings se sont divisés par deux

Un sprint planning en components teams, c'était :

L'équipe Android qui essayait de comprendre quelle priorité venait de quel PM
Des arbitrages entre 4-5 sujets sans rapport
Des estimations approximatives parce que personne ne connaissait vraiment le contexte produit
Le QA absent du planning car « il viendra à la fin »
Durée moyenne : 3h30

Un sprint planning de feature team, c'était :

Le PM présente la roadmap de la squad (1 seule mission) Les devs et le QA estiment ensemble, alignés sur un objectif unique Les dépendances externes sont identifiées dès le début de sprint Durée moyenne : 1h30

Gain net : 2h par planning × 3 squads × 2 par mois = 12h par mois récupérées en livraison.

5. Les rétrospectives sont devenues productives

Une rétrospective en components teams, c'était :

« On a manqué de specs claires de l'équipe Produit. » « L'équipe QA a mis trop de temps à valider. » « Le backend a livré l'API en retard. »

C'est-à-dire : on se plaint des autres équipes qu'on ne contrôle pas. Une rétrospective de squad, c'était :

« On a sous-estimé l'effort sur la story de sync conflictuelle. La prochaine fois, on découpe en sous-tâches dès le refinement. » « Les tests bout en bout offline / online sont fragiles. On dédie une demi-journée par sprint à les renforcer. » « Notre PR review prend trop de temps. On instaure un créneau dédié de 16h à 17h. »

C'est-à-dire : l'équipe résout des problèmes qu'elle peut effectivement résoudre. C'est ça, l'agilité réelle. Pas la cérémonie agile.

6. La qualité a augmenté, pas baissé

Le contre-argument classique : « Si vous éclatez les équipes par métier, vous perdez l'expertise transverse. » Vrai en partie. Mais voici ce qui s'est réellement passé :

Indicateur	Avant (components)	Après (features
Bugs critiques en production / sprint	8-12	3-5
Time to fix d'un bug critique	48h	6h
Couverture de tests automatisés	35%	70%
Satisfaction développeurs (NPS interne)	-10	+35

Le bond de couverture de tests automatisés s'explique simplement : avec un QA embarqué dans la squad et impliqué dès le refinement, les tests automatisés étaient pensés dès la conception, pas après. Le QA passait moins de temps à tester manuellement et plus à automatiser, parce qu'il n'était plus pris dans la course aux pompiers. Et dans une feature team, chaque dev a un contexte business clair .Un développeur Android dans la Squad Agent comprenait que sa feature servait à un agent dans un village ivoirien, avec un téléphone Android d'entrée de gamme, sans connexion stable, qui devait pouvoir enregistrer un colis et continuer à travailler même si le réseau lâchait pendant 30 minutes. Il codait mieux parce qu'il savait à quoi ça servait.

7. Le produit lui-même a gagné en cohérence

L'effet le plus subtil mais le plus puissant. En components teams, on avait des incohérences invisibles : un colis créé sur l'app Android avait un format légèrement différent du colis affiché dans le dashboard web, parce que les deux équipes n'avaient pas exactement la même compréhension du modèle de données. En feature teams, chaque squad possédait son modèle de données de bout en bout. La Squad Agent et la Squad Manager partageaient les contrats d'API via la Squad Réseau, qui jouait le rôle de gardien de la cohérence métier. Moins d'allers-retours, moins de duplications, moins d'incohérences.

Comment garder l'expertise technique transverse

C'est la vraie question. Et la réponse est dans le modèle Spotify, qui combine feature teams (squads) et chapters / guilds :

Élément	Rôle
Squad (= feature team)	Livre de la valeur, autonome, bout en bout
Tribe	Regroupement de squads sur un domaine global
Chapter	Communauté inter-squads par métier (ex : tous les Android, tous les QA)
Guild	Communauté volontaire transverse par centre d'intérêt

Les squads livrent. Les chapters et guilds partagent l'expertise sans empêcher la livraison. Chez nous, un QA passait 100% de son temps dans sa squad, mais participait à un chapter QA d'1h par semaine — pour aligner les protocoles de test, partager les outils d'automatisation, discuter des stratégies de tests offline (un sujet critique vu notre contexte africain). C'est ce qui permet de garder vitesse de livraison + cohérence technique.

Les conditions pour que ça marche

Sans ces 6 conditions, le pivot ne donne pas les résultats attendus. J'ai vu des organisations garder le mot « squad » mais maintenir des silos managériaux par-dessus, ou garder le QA en équipe séparée « centralisée ». Le résultat est pire qu'avant : les rituels existent mais l'autonomie est fictive.

Quand passer aux feature teams ?

Pas tout de suite, dans tous les cas.

Taille de l'équipe	Recommandation
< 10 personnes	Garder simple, une seule équipe pluridisciplinaire
10-25 personnes	Idéal pour pivoter en 2-3 feature teams
25-100 personnes	Modèle Spotify complet (tribes + squads + chapters)
> 100 personnes	Scaled agile (SAFe, LeSS) ou Spotify étendu

Une feature team a besoin d'1 PM + 4 à 8 personnes max (devs + QA inclus). En dessous, c'est trop petit. Au-dessus, on retombe dans les problèmes de coordination interne.

Le mot de la fin

L'organisation n'est pas un détail. Ce n'est pas ce qui « habille » l'équipe technique. C'est ce qui ** détermine sa vitesse de livraison.** J'ai vu des équipes brillantes paralysées par un mauvais découpage. J'ai vu des équipes moyennes décupler leur impact en changeant simplement comment elles étaient regroupées. Le pivot des components teams vers les feature teams n'est ni nouveau, ni révolutionnaire. C'est juste le seul levier qui, en quelques semaines, peut tripler votre vélocité — sans coût additionnel, sans embauche, sans changement de stack. Et c'est le levier le plus sous-utilisé dans les organisations que je rencontre — particulièrement dans les startups africaines, où les contraintes opérationnelles (offline, low-end devices, partenaires hors-tech) rendent encore plus critique la cohérence bout-en-bout que seule une feature team peut garantir.

Une équipe organisée par compétence optimise la compétence. Une équipe organisée par mission optimise la livraison. Vous voulez quoi, vraiment ?