Après avoir compris comment les flux de communication circulent au sein des organisations, l’étape suivante consiste à examiner comment les équipes elles-mêmes sont structurées. Avant de prendre du recul pour observer comment plusieurs équipes interagissent, un sujet traité dans le prochain article, il est utile de s’intéresser de plus près à l’équipe en tant qu’unité : qu’est-ce qui la rend performante, comment les responsabilités doivent-elles être réparties en son sein, et quels compromis accompagnent chaque choix.
Chaque modèle comporte des compromis, et le bon choix dépend de la mission de l’équipe, de la complexité du produit, des compétences disponibles et du niveau d’autonomie souhaité. Explorons les types d’équipes les plus courants, leurs caractéristiques, avantages et limites.
La question fondamentale : comment répartir le travail ?#
Au cœur de la conception d’une équipe se trouve une question simple : comment répartissons-nous le travail entre les personnes ? La réponse conditionne tout le reste : lignes hiérarchiques, modes de communication, répartition des compétences et normes culturelles.
Historiquement, les organisations ont abordé cette question selon deux perspectives principales :
- Par fonction ou compétence (équipes horizontales)
- Par produit ou résultat (équipes verticales)
Comprendre ces modèles fondamentaux est essentiel avant d’explorer des types d’équipes plus spécialisés.
Équipes horizontales : s’organiser par fonction#
Les équipes horizontales regroupent les personnes par fonction, compétence ou discipline. Dans une entreprise technologique qui développe des produits embarqués, cela se traduit généralement par des équipes distinctes pour le développement firmware, la conception hardware, le logiciel, la validation, l’ingénierie système et la gestion de produit.
Chaque équipe se concentre sur son domaine d’expertise. Le travail circule horizontalement entre les équipes, chaque fonction apportant ses connaissances spécialisées à une initiative commune.
Caractéristiques#
- Les équipes sont organisées autour de disciplines techniques ou de domaines fonctionnels
- Les membres partagent des compétences et une expertise similaires
- Le travail traverse généralement plusieurs équipes pour livrer des fonctionnalités de bout en bout
- La coordination s’effectue par des feuilles de route partagées ou de la gestion de projet
- Spécialisation approfondie au sein de chaque fonction
- Équipe Firmware : Développe le logiciel bas niveau sur toutes les gammes de produits
- Équipe Conception Hardware : Conçoit les PCB, schémas et systèmes électriques
- Équipe Logiciel : Développe les applications, services cloud et applications compagnon
- Équipe Validation : Gère les tests, la certification et l’assurance qualité
- Équipe Ingénierie Système : Définit les exigences, interfaces et l’intégration entre sous-systèmes
- Équipe Ingénierie de Production : Responsable des processus de fabrication, de l’outillage et de l’optimisation des rendements
Modes de communication#
Les équipes horizontales reposent fortement sur la coordination transversale. Une seule fonctionnalité nécessite souvent la collaboration entre les équipes hardware, firmware, logiciel et validation. Les flux de communication incluent :
- Communication horizontale entre équipes homologues
- Communication descendante de la direction pour arbitrer les priorités, car les équipes horizontales servent plusieurs initiatives et ne peuvent pas décider seules de l’allocation des ressources
- Communication en hub via les chefs de projet ou les référents techniques qui coordonnent les fonctions
Forces et limites#
- Expertise approfondie : Les membres développent des compétences spécialisées dans leur domaine
- Allocation efficace des ressources : Les spécialistes peuvent être partagés entre plusieurs initiatives
- Standards et cohérence : Les équipes centralisées imposent des pratiques uniformes (standards de code, règles de conception, procédures de test)
- Développement de carrière : Des parcours de progression clairs au sein d’une discipline technique
- Partage des connaissances : L’expertise concentrée facilite le mentorat et le transfert de savoirs
- Livraison lente : Les fonctionnalités nécessitant plusieurs équipes subissent des surcoûts de coordination et des délais de transfert
- Responsabilité diluée : Aucune équipe ne possède l’expérience client de bout en bout
- Priorités désalignées : Les équipes peuvent optimiser leur fonction plutôt que les résultats métier
- Surcoût de communication : La coordination entre équipes exige un effort de gestion important
- Risque de silos : Les équipes développent des optimisations locales qui peuvent entrer en conflit avec les objectifs organisationnels
- Agilité réduite : Répondre à des priorités changeantes nécessite de réaligner plusieurs équipes
Quand utiliser ce modèle#
Les équipes horizontales fonctionnent bien dans les organisations où :
- La spécialisation est critique : La complexité technique exige une expertise approfondie (ex. : apprentissage automatique, sécurité, conformité)
- Les économies d’échelle comptent : L’infrastructure ou les plateformes partagées bénéficient de la centralisation
- Le travail est prévisible : Les initiatives peuvent être planifiées et séquencées entre les équipes
- L’organisation est petite : Le surcoût de coordination reste gérable
- Plateformes ou services partagés : Des équipes d’infrastructure supportant plusieurs produits
Équipes verticales : s’organiser par produit ou chaîne de valeur#
Les équipes verticales, aussi appelées équipes produit ou équipes transversales, s’organisent autour d’un produit, d’un périmètre fonctionnel ou d’un segment client. Chaque équipe contient toutes les compétences nécessaires pour délivrer de la valeur de manière autonome : ingénieurs hardware, développeurs firmware, ingénieurs logiciel, testeurs, et parfois des responsables produit.
L’équipe possède une tranche spécifique du produit ou du parcours client de bout en bout. Au lieu de faire circuler le travail horizontalement entre les fonctions, l’équipe fait avancer le travail verticalement à travers son propre pipeline de livraison.
Caractéristiques#
- Les équipes sont organisées autour de produits, de fonctionnalités ou de résultats client
- Chaque équipe est transversale, regroupant des compétences variées (hardware, firmware, logiciel, test, etc.)
- Les équipes ont la responsabilité de bout en bout de leur domaine
- Dépendances minimales envers d’autres équipes pour la livraison
- Autonomie de décision dans leur périmètre
- Équipe Connectivité : Responsable de l’ensemble de la pile BLE et Wi-Fi, des drivers firmware aux services cloud d’appairage
- Équipe Module Capteur : Construit et maintient l’acquisition, le calibrage et le traitement des capteurs
- Équipe Gestion d’Énergie : Responsable de l’autonomie de la batterie, des circuits de charge et du firmware d’économie d’énergie
- Équipe Application Compagnon : Développe l’application mobile et son intégration avec l’appareil
- Équipe Mise à Jour OTA : Responsable du pipeline complet de mise à jour over-the-air, de la compilation au déploiement
Modes de communication#
Les équipes verticales minimisent les dépendances inter-équipes, réduisant le besoin de coordination permanente. Les flux de communication incluent :
- Communication horizontale forte au sein de l’équipe
- Communication ascendante pour s’aligner sur la stratégie et les priorités, car l’équipe possède sa feuille de route et propose ce qu’il faut construire plutôt que de recevoir des missions
- Communication en hub via les responsables produit ou les architectes pour de rares coordinations inter-équipes
Forces et limites#
- Livraison rapide : Les équipes avancent vite sans attendre d’autres équipes
- Responsabilité claire : Une seule équipe est redevable de l’expérience client complète dans son domaine
- Intérêts alignés : Les équipes optimisent pour les résultats métier, pas pour des métriques fonctionnelles
- Forte autonomie : Les équipes prennent des décisions de manière indépendante, favorisant l’appropriation et la motivation
- Surcoût de coordination réduit : Moins de dépendances
- Orientation client : Les équipes restent proches des besoins utilisateurs et peuvent itérer rapidement
- Effort dupliqué : Les équipes peuvent reconstruire des solutions similaires indépendamment
- Standards incohérents : Sans fonctions centralisées, la conception, l’architecture ou les processus peuvent diverger
- Lacunes de compétences : Les petites équipes peuvent manquer d’expertise approfondie dans certains domaines
- Utilisation inefficace des ressources : Les spécialistes peuvent être sous-utilisés s’ils ne sont pas pleinement nécessaires au sein d’une seule équipe
- Parcours de carrière difficiles : Les ingénieurs peuvent peiner à progresser dans une discipline spécifique sans communauté de pratique
- Défis d’intégration : S’assurer que les livrables des différentes équipes fonctionnent ensemble demande un effort délibéré
Quand utiliser ce modèle#
Les équipes verticales fonctionnent bien dans les organisations où :
- La rapidité et l’autonomie comptent : Le marché exige une itération rapide et de l’expérimentation
- Des frontières produit claires existent : Les différentes parties du produit peuvent être séparées avec un chevauchement minimal
- L’organisation est suffisamment grande : Vous disposez d’assez de personnes pour former plusieurs équipes transversales
- Les résultats client déterminent le succès : Les métriques métier comptent plus que les métriques techniques
- L’innovation est prioritaire : Les équipes ont besoin de liberté pour expérimenter et s’adapter
Feature teams : livrer des fonctionnalités de bout en bout#
Les feature teams sont un type spécifique d’équipe verticale concentré sur la livraison de fonctionnalités complètes orientées client. Le concept a gagné en notoriété grâce au framework Scrum et insiste sur le fait que les équipes doivent livrer du logiciel fonctionnel apportant une valeur tangible, et non de simples composants.
Caractéristiques#
- Les équipes travaillent sur des fonctionnalités complètes couvrant toute la pile technologique
- Composition transversale (hardware, firmware, logiciel, test, etc.)
- Les fonctionnalités sont définies du point de vue de l’utilisateur, pas de l’architecture technique
- Les équipes possèdent les fonctionnalités de la conception au déploiement et à la maintenance
- Accent sur la livraison d’incréments potentiellement livrables
Si toutes les feature teams sont des équipes verticales, toutes les équipes verticales ne sont pas des feature teams. Les feature teams insistent spécifiquement sur :
- Livraison centrée utilisateur : Les fonctionnalités doivent apporter une valeur visible au client
- Responsabilité full-stack : Les équipes ne peuvent pas livrer uniquement du firmware ou un PCB. Elles livrent la fonctionnalité complète à travers toutes les couches
- Développement itératif : Les fonctionnalités sont découpées en versions incrémentales
La Feature Team Authentification NFC possède tout ce qui concerne l’authentification sans contact :
- Interface hardware pour l’antenne NFC et l’élément sécurisé
- Firmware pour la gestion du protocole NFC et l’échange de clés
- Intégration dans l’application mobile pour l’appairage et le provisionnement
- Service cloud pour la gestion des certificats
- Maintenance et correction de bugs sur toutes les couches
L’équipe comprend un responsable produit, un ingénieur hardware, un développeur firmware, un ingénieur logiciel et un ingénieur test. Elle livre la fonctionnalité de bout en bout sans dépendance envers d’autres équipes.
Forces et limites#
- Mise sur le marché plus rapide : Les fonctionnalités complètes sont livrées sans attendre d’autres équipes
- Valeur livrée clairement : Les équipes se concentrent sur ce qui compte pour les utilisateurs, pas sur l’architecture interne
- Transferts réduits : Une seule équipe gère tous les aspects d’une fonctionnalité
- Meilleure qualité : Les équipes possèdent leurs fonctionnalités sur le long terme, ce qui encourage la maintenabilité
- Motivation accrue : Voir des fonctionnalités complètes livrées stimule le moral de l’équipe
- Dette architecturale : Les équipes peuvent prendre des raccourcis pour livrer rapidement, créant de la dette technique
- Silos de connaissances : L’expertise se concentre dans les périmètres fonctionnels plutôt que d’être partagée
- UX incohérente : Sans coordination, les fonctionnalités peuvent sembler décousues
- Négligence de la plateforme : L’infrastructure centrale peut souffrir si toutes les équipes se concentrent sur les fonctionnalités
Quand utiliser ce modèle#
Les feature teams fonctionnent bien quand :
- La vitesse de livraison produit est critique
- Les fonctionnalités sont relativement indépendantes
- Vous disposez d’une plateforme mature sur laquelle les feature teams peuvent s’appuyer
- Les boucles de retour client sont courtes
Équipes plateforme : gérer les services partagés et les produits internes#
Les équipes plateforme se concentrent sur la construction et la maintenance de plateformes, bibliothèques ou services partagés dont dépendent les autres équipes. Contrairement aux équipes verticales, les équipes plateforme ne livrent pas directement de fonctionnalités orientées client. Elles fournissent des capacités qui permettent aux autres équipes de délivrer de la valeur plus rapidement.
Caractéristiques#
- Les équipes possèdent des composants techniques ou des plateformes (ex. : BSP, abstractions RTOS, pipelines CI/CD, infrastructure de test)
- Leurs clients sont d’autres équipes d’ingénierie, pas les utilisateurs finaux
- Accent sur la réutilisabilité, la stabilité et la performance
- Souvent de nature horizontale mais avec un état d’esprit produit
Si les équipes plateforme partagent le regroupement fonctionnel des équipes horizontales, elles diffèrent sur un point clé : une équipe plateforme possède un produit, ce produit se trouve simplement être interne. Elle maintient un backlog, priorise les demandes des équipes consommatrices, définit sa propre feuille de route et gère le versionnement et les contrats. Une équipe horizontale traditionnelle exécute le travail assigné par d’autres ; une équipe plateforme décide quoi construire et quand, en traitant les autres équipes d’ingénierie comme ses clients.
- Équipe BSP : Maintient le board support package et les couches d’abstraction hardware utilisées par toutes les équipes produit
- Équipe Sécurité : Construit et opère les bibliothèques cryptographiques, le secure boot et l’infrastructure de gestion des clés
- Équipe Infrastructure de Test : Fournit les bancs hardware-in-the-loop, les frameworks de test automatisé et les outils de gestion de parc
- Équipe DevOps : Responsable des pipelines CI/CD et des processus de release firmware
Forces et limites#
- Effet de levier et réutilisation : Le travail d’une équipe bénéficie à de nombreuses autres
- Cohérence : Les composants centralisés garantissent des expériences uniformes
- Efficacité : Les équipes évitent de dupliquer le travail fondamental
- Expertise approfondie : Les équipes plateforme développent des connaissances spécialisées
- Déconnexion des utilisateurs finaux : Les équipes peuvent perdre de vue les besoins clients
- Goulots d’étranglement : Si les équipes plateforme ne suivent pas la demande, elles ralentissent tout le monde
- Priorités concurrentes : Équilibrer les demandes de plusieurs équipes produit est un défi
- Autonomie réduite des feature teams : Les dépendances envers les équipes plateforme limitent la vitesse
Quand utiliser ce modèle#
Les équipes plateforme fonctionnent bien quand :
- L’infrastructure partagée apporte une valeur significative
- La duplication serait coûteuse ou risquée (ex. : sécurité, conformité, infrastructure)
- L’organisation est suffisamment grande pour justifier des équipes plateforme dédiées
- Des interfaces et contrats clairs existent entre les équipes plateforme et leurs consommateurs
Impact teams : optimiser pour les résultats métier#
Les impact teams représentent une évolution des feature teams, explicitement organisées autour de résultats métier mesurables plutôt que de fonctionnalités ou de produits. Ces équipes se voient confier une métrique à faire évoluer (revenu, rétention, engagement, conversion) et une pleine autonomie pour déterminer comment y parvenir.
Caractéristiques#
- Les équipes sont organisées autour de métriques et d’objectifs métier, pas de fonctionnalités
- Orientées résultats : Le succès se mesure par l’impact, pas par la production (fonctionnalités livrées)
- Forte autonomie : Les équipes décident quoi construire en fonction de ce qui fera bouger leur métrique
- Orientées expérimentation : Fort accent sur les tests A/B, l’analyse de données et l’itération
- Transversales, incluant des analystes de données ou des data scientists
Les feature teams se concentrent sur quoi construire (fonctionnalités). Les impact teams se concentrent sur pourquoi construire (résultats). Les impact teams disposent d’une autonomie stratégique encore plus grande : elles peuvent choisir de créer des fonctionnalités, mener des expériences, supprimer des fonctionnalités ou modifier des comportements existants en se basant sur les données.
L’Impact Team Succès de la Première Configuration est responsable de l’amélioration du pourcentage d’utilisateurs qui réussissent l’appairage de leur appareil dès la première tentative.
Leur métrique : taux de succès de configuration à la première tentative
L’équipe comprend un responsable produit, un ingénieur hardware, un développeur firmware, un ingénieur logiciel et un analyste de données. Elle est habilitée à :
- Simplifier le flux d’appairage BLE dans le firmware
- Améliorer le placement ou le blindage de l’antenne pour réduire les interférences
- Repenser l’UX d’accueil dans l’application compagnon
- Ajouter un retour visuel ou haptique sur l’appareil pendant l’appairage
- Pré-provisionner les identifiants en usine pour sauter les étapes manuelles
L’équipe mène des expériences en continu, mesure les points d’abandon dans l’entonnoir de configuration et itère en fonction de ce qui améliore le succès à la première tentative.
Modes de communication#
Les impact teams nécessitent une infrastructure de données solide et un alignement sur les métriques. Les flux de communication incluent :
- Communication ascendante pour s’aligner sur les métriques stratégiques et les OKR
- Communication horizontale avec les autres impact teams pour éviter les conflits ou exploiter les synergies
- Communication en hub via les équipes data ou les plateformes d’analytique
- Reporting fréquent sur l’évolution des métriques et les résultats d’expériences
Forces et limites#
- Focalisation sur la valeur métier : Chaque décision est liée à des résultats mesurables
- Redevabilité : Les équipes possèdent des objectifs clairs et mesurables
- Autonomie stratégique : Les équipes déterminent la meilleure approche pour atteindre l’impact
- Culture orientée données : Les décisions reposent sur des preuves, pas des opinions
- Apprentissage rapide : L’expérimentation continue accélère l’amélioration
- Optimisation court-termiste : Les équipes peuvent privilégier les gains rapides au détriment de la durabilité à long terme
- Manipulation des métriques : Les équipes peuvent optimiser leur métrique au détriment d’objectifs plus larges
- Nécessite une infrastructure de données solide : Sans données fiables, les impact teams ne peuvent pas fonctionner
- Métriques difficiles à définir : Tout travail de valeur ne se traduit pas en un résultat unique et mesurable
- Potentiel de conflit : Les métriques de différentes équipes peuvent entrer en concurrence (ex. : croissance vs. qualité)
- Nécessite une organisation mature : Les équipes doivent avoir les compétences et la rigueur nécessaires pour interpréter correctement les données
Quand utiliser ce modèle#
Les impact teams fonctionnent bien quand :
- Les métriques métier sont bien définies et mesurables
- L’infrastructure de données est mature : suivi fiable, plateformes d’expérimentation et analytique
- L’organisation valorise les résultats plutôt que la production
- Les équipes possèdent de solides compétences analytiques
- La direction fait confiance aux équipes pour prendre des décisions stratégiques
Choisir la bonne structure d’équipe#
Il n’existe pas de réponse universelle. La bonne structure dépend de multiples facteurs :
Éléments de comparaison#
| Facteur | Horizontale | Verticale / Feature / Impact | Plateforme |
|---|---|---|---|
| Taille de l’organisation | Petite à moyenne | Moyenne à grande | Moyenne à grande |
| Complexité du produit | Simple ou modulaire | Complexe, intégré | Complexe |
| Exigences de rapidité | Modérées | Élevées | Modérées |
| Besoins de spécialisation | Élevés | Modérés | Élevés |
| Surcoût de coordination | Élevé | Faible | Modéré |
| Orientation client | Indirecte | Directe | Indirecte |
| Priorité à l’innovation | Modérée | Élevée | Modérée |
Questions directrices#
Avant de choisir une structure d’équipe, posez-vous ces questions :
- Quel est notre objectif principal ? Rapidité ? Qualité ? Innovation ? Cohérence ?
- Quel degré d’autonomie les équipes peuvent-elles réellement avoir ? Disposons-nous d’une infrastructure partagée, ou les équipes doivent-elles se coordonner en permanence ?
- Quelle est notre architecture produit ? Les systèmes monolithiques peuvent imposer plus de coordination ; les microservices permettent plus d’autonomie.
- Quelle est la maturité de notre organisation ? Les équipes verticales exigent de la discipline, une infrastructure de données et de la confiance.
- Quels sont nos goulots d’étranglement aujourd’hui ? Identifiez si la coordination, la spécialisation ou la vitesse d’exécution est le facteur limitant.
Faire évoluer les structures d’équipe dans le temps#
Les structures d’équipe ne sont pas figées. À mesure que les organisations grandissent, que les produits mûrissent et que les marchés évoluent, la structure optimale change. De nombreuses entreprises prospères évoluent à travers des étapes prévisibles :
Étape 1 : Petite startup (horizontale par défaut)#
Tout le monde fait un peu de tout. Il n’y a pas d’équipes formelles, juste des personnes qui travaillent ensemble.
Étape 2 : Startup en croissance (émergence des équipes verticales)#
À mesure que l’équipe grandit, vous formez vos premières équipes produit transversales pour avancer plus vite et réduire les dépendances.
Étape 3 : Organisation en croissance (vertical + plateforme)#
Vous mettez en place des équipes plateforme dédiées pour éviter la duplication et maintenir la cohérence, tandis que les équipes produit restent autonomes.
Étape 4 : Organisation mature (guildes et CoE)#
Vous introduisez des communautés de pratique, une gouvernance architecturale et des mécanismes de coordination plus sophistiqués pour équilibrer rapidité et cohérence à grande échelle.
La structure d’équipe doit évoluer avec votre organisation. Réévaluez régulièrement si votre structure actuelle sert encore vos objectifs, ou si elle est devenue une contrainte.
Les équipes à l’ère des assistants IA#
L’essor des assistants de codage IA et de l’IA générative commence à transformer le fonctionnement des équipes. Bien que les types d’équipes fondamentaux décrits ci-dessus restent pertinents, l’IA introduit de nouvelles dynamiques à prendre en compte.
Capacité individuelle amplifiée#
Les assistants IA permettent à un seul ingénieur de couvrir plus de terrain : écriture de code répétitif, génération de tests, exploration de bases de code inconnues ou rédaction de documentation. Cela déplace le goulot d’étranglement de la production brute vers le jugement, la relecture et la prise de décision. Les équipes qui étaient dimensionnées en fonction du débit de production pourraient constater que moins de personnes peuvent livrer le même périmètre, soulevant des questions sur la taille optimale des équipes.
Frontières de compétences floues#
Quand un assistant IA peut aider un ingénieur firmware à écrire une intégration cloud ou assister un concepteur hardware dans la rédaction d’un pipeline d’automatisation de tests, les frontières de compétences traditionnelles qui définissent les équipes horizontales deviennent moins rigides. Cela n’élimine pas le besoin d’expertise approfondie, mais abaisse la barrière pour la contribution transversale au sein des équipes verticales et feature teams.
Besoin accru de relecture et d’alignement#
Une production individuelle plus élevée signifie plus de code, plus d’artefacts et plus de décisions qui traversent l’équipe. Sans coordination délibérée, les équipes assistées par l’IA risquent de produire plus vite tout en divergeant davantage. Les processus de relecture, les directives architecturales et les standards partagés deviennent encore plus importants pour maintenir la cohérence.
Impact sur les types d’équipes#
- Les équipes horizontales peuvent voir leur surcoût de coordination réduit grâce aux outils IA qui comblent les lacunes de connaissances entre fonctions
- Les équipes verticales et feature teams en bénéficient le plus directement, car l’IA amplifie la capacité de chaque membre à contribuer à travers la stack
- Les équipes plateforme font face à une demande croissante, car les équipes produit assistées par l’IA avancent plus vite et consomment les services partagés plus intensément
- Les impact teams gagnent de nouvelles capacités d’expérimentation grâce à l’analyse, au prototypage et à l’itération assistés par l’IA
L’IA ne change pas pourquoi les équipes existent. Les équipes existent toujours pour détenir les décisions, assurer la redevabilité et livrer des résultats. Ce qui change, c’est l’enveloppe de capacité de chaque membre et la vitesse à laquelle le désalignement peut s’amplifier. Les organisations qui adoptent des outils IA devraient revoir les périmètres d’équipe, les pratiques de relecture et les mécanismes de coordination en conséquence.
Conclusion#
Il n’existe pas de structure d’équipe universellement « meilleure ». Les équipes horizontales offrent spécialisation et cohérence mais peinent en rapidité et autonomie. Les équipes verticales, feature et impact livrent plus vite et se concentrent sur les résultats, mais risquent la duplication et l’incohérence. Les équipes plateforme apportent un effet de levier mais peuvent devenir des goulots d’étranglement.
La bonne structure d’équipe est celle qui s’aligne avec la taille de votre organisation, ses objectifs, son architecture produit et ses valeurs culturelles. Plutôt que de copier ce qui fonctionne ailleurs, observez vos goulots d’étranglement, expérimentez délibérément et faites évoluer votre structure à mesure que votre organisation grandit.
Dans le prochain article, nous explorerons les topologies d’équipes : comment plusieurs équipes interagissent, se coordonnent et évoluent ensemble pour former un système organisationnel cohérent.
