Le réflexe anti-silo et ses limites

Dans les organisations qui grandissent, un même diagnostic revient avec régularité: “nous avons un problème de silos”. Le remède prescrit suit presque toujours la même logique, à savoir multiplier les réunions transverses, créer des comités inter-équipes, encourager la collaboration tous azimuts. Or cette approche traite le symptôme sans comprendre le mécanisme. Les silos ne sont pas un accident organisationnel: ils résultent de contraintes fondamentales sur la façon dont les groupes humains fonctionnent.

Toute organisation d’une certaine taille finit par se structurer en équipes spécialisées. C’est une nécessité cognitive avant d’être un choix managérial. Chaque personne ne peut maintenir qu’un nombre limité de relations de travail productives, et chaque équipe ne peut absorber qu’un volume fini d’information. Les frontières entre équipes ne sont donc pas des murs à abattre: ce sont des structures qui permettent à chacun de se concentrer sur sa mission.

Ce que “casser les silos” produit réellement

Jade Rubick, qui a dirigé des équipes d’ingénierie chez New Relic, décrit un schéma qu’il a observé de l’intérieur. L’entreprise valorisait et récompensait la collaboration inter-équipes. Pendant les premières années, cette culture semblait fonctionner. Puis, à mesure que l’organisation grandissait, les dépendances entre équipes se sont multipliées de façon exponentielle. Le résultat: une incapacité croissante à mener les projets d’envergure à leur terme, chaque initiative nécessitant l’alignement d’un nombre toujours plus grand d’interlocuteurs.

Ce paradoxe s’explique par la nature des dépendances. Quand on encourage la collaboration sans structurer les interfaces, chaque équipe devient tributaire de plusieurs autres pour avancer. Les priorités entrent en conflit, les délais s’allongent, et la capacité de décision se dilue. Le problème n’était pas le manque de collaboration: c’était son excès, combiné à l’absence de frontières claires.

Trois mots que les managers confondent

Une part importante du malentendu vient d’une confusion terminologique entre coordination, communication et collaboration.

La coordination consiste à harmoniser les efforts de plusieurs parties vers un résultat commun. Elle ne requiert pas que les équipes travaillent ensemble au quotidien: elle exige un mécanisme centralisé qui aligne les objectifs, les échéances et les priorités. Le modèle militaire, souvent cité en design organisationnel, repose sur ce principe: centraliser la coordination, décentraliser l’exécution.

La communication concerne le transfert d’information entre groupes. Quand un chef de projet constate que deux équipes ne se parlent pas assez, le problème est souvent un flux d’information mal conçu plutôt qu’un manque de proximité. La solution passe par l’identification de ce que chaque équipe a besoin de savoir et la mise en place du canal le plus léger possible pour y répondre.

La collaboration implique que des équipes travaillent ensemble sur un même livrable. C’est la forme d’interaction la plus coûteuse, et Rubick soutient qu’elle devrait être l’exception plutôt que la norme. Quand deux équipes doivent collaborer étroitement pour atteindre leurs objectifs respectifs, c’est souvent le signal d’une mauvaise structuration organisationnelle plutôt qu’un idéal à poursuivre.

Le silo bien conçu: une question d’interfaces

Si le silo n’est pas le problème, que faut-il concevoir à la place? La réponse tient en un mot: les interfaces. En génie logiciel, un principe fondamental de conception est l’encapsulation: on masque les détails internes d’un composant derrière une interface publique, un contrat qui spécifie ce que le composant fournit sans exposer son fonctionnement interne. Ce principe s’applique directement aux organisations. Quand une équipe a besoin de ce que produit une autre, la solution n’est pas d’ouvrir les portes pour que tout le monde accède librement au travail en cours: c’est de définir clairement ce qui est fourni, sous quelle forme et à quel rythme.

Jeff Bezos a appliqué ce principe à grande échelle chez Amazon dès 2002 avec son célèbre mandat API. Chaque équipe devait exposer ses données et fonctionnalités via des interfaces standardisées, sans exception. Le résultat a été une organisation où les équipes pouvaient avancer de façon autonome tout en restant connectées au système global.

Pour un chef de projet qui gère plusieurs équipes, le principe se traduit en questions concrètes. De quoi mon équipe a-t-elle besoin des autres pour avancer? Sous quelle forme et à quelle fréquence? Ces besoins peuvent-ils être satisfaits par un artefact (un document, un tableau de bord, un registre partagé) plutôt que par une réunion? Si deux équipes doivent se synchroniser constamment pour livrer, c’est le découpage des responsabilités qu’il faut revoir, pas la fréquence des échanges.

Comment diagnostiquer le vrai problème

Quand un projet multi-équipes ralentit, le réflexe de “casser les silos” empêche souvent d’identifier la cause réelle. Un diagnostic plus utile consiste à poser trois questions distinctes.

Premièrement, est-ce un problème de coordination? Les équipes comprennent-elles comment leur travail s’articule avec celui des autres? Ont-elles une vision claire des priorités globales? Si ce n’est pas le cas, la réponse est un mécanisme de coordination, qu’il s’agisse d’un comité de pilotage, d’une feuille de route partagée ou d’un rôle de coordination dédié.

Deuxièmement, est-ce un problème de communication? Une équipe manque-t-elle d’informations détenues par une autre? La solution est alors de concevoir le flux d’information nécessaire, pas de rapprocher physiquement les équipes ou de multiplier les points de contact.

Troisièmement, est-ce un vrai problème de collaboration? Deux équipes doivent-elles réellement produire un livrable commun? Si oui, la question devient: peut-on restructurer le travail pour éliminer cette dépendance? Rubick observe que dans la majorité des cas, ce qui ressemble à un besoin de collaboration est en réalité un problème de coordination ou de communication déguisé.

Concevoir l’autonomie plutôt que forcer la proximité

Matthew Skelton et Manuel Pais, dans leur ouvrage Team Topologies (2019), formalisent cette approche en identifiant quatre types d’équipes et trois modes d’interaction entre elles. Leur travail rejoint celui de Rubick sur un point central: la performance organisationnelle dépend davantage de la clarté des frontières que de leur absence. Les recherches du programme DORA confirment cette intuition en établissant un lien fort entre le couplage lâche (c’est-à-dire des équipes peu dépendantes les unes des autres dans leur fonctionnement quotidien) et la performance globale de l’organisation.

Pour le chef de projet, l’implication pratique est significative. Plutôt que de chercher à multiplier les interactions entre équipes, l’objectif devrait être de les réduire au strict nécessaire en concevant des frontières qui protègent l’autonomie de chaque équipe. Cela suppose d’investir du temps dans la définition des interfaces, c’est-à-dire dans ce que chaque équipe fournit aux autres, sous quelle forme et selon quel calendrier. C’est un travail moins visible que l’organisation d’ateliers transverses, mais dont l’impact sur la capacité de livraison est autrement plus durable.