Casser les silos : comment s'y prendre ?

« Il faut casser les silos » : voici une expression que vous avez certainement entendu maintes et maintes fois dans votre entreprise. Casser les silos, c’est souvent l’objectif affiché lorsque les entreprises envisagent la migration de leurs vieux serveurs de fichiers vers des outils plus modernes, comme SharePoint ou de plus en plus souvent Teams. Si tant est que SharePoint - qui vient de fêter ses 25 ans, ou Teams - qui fêtera l’an prochain ses 10 ans, puissent être qualifiés d’outils modernes. Mais "casser les silos", ça veut dire quoi exactement, et comment peut on le faire avec SharePoint et Teams ?

C'est quoi un silo ?

Avant de casser du silo, mieux savoir exactement ce que c’est.

J’ai posé la question à Copilot qui m’a répondu ceci : « Un silo dans une entreprise désigne un service ou une équipe qui fonctionne de manière isolée, sans partager suffisamment l’information, les objectifs ou les pratiques avec les autres. Ce cloisonnement crée des barrières organisationnelles : chacun optimise son propre périmètre, au détriment de la coordination, de la fluidité et de la vision collective. On parle de silos lorsque la collaboration transversale devient difficile et que l’entreprise perd en efficacité globale. ».

Pour le dire autrement, les silos c’est la logique du « chacun chez soi » et surtout du « chacun pour soi ». On s'occupe de l’organisation interne de sa propre structure, sans penser à la manière de collaborer avec les autres structures: c’est une solution de facilité mais ça plombe l'efficacité de l’entreprise. C’est un phénomène qui touche à la fois le documentaire et la communication.

Les silos documentaires

Pour comprendre ce que sont les silos documentaires, il faut faire un peu d’histoire.

A la fin des années 1980, quand les premiers serveurs de fichiers ont été déployés dans les entreprises la logique de structuration la plus commune était très simple et logique pour l’époque : chaque grande direction disposait d'un espace de stockage bien à elle qu'elle pouvait gérer à sa guise. L’espace était souvent structuré en dossiers et sous dossiers : l’arborescence des dossiers respectait très précisément l’organisation de la direction en divisions, domaines, pôles, … selon le vocabulaire propre à chaque entreprise.

Notez que je parle au passé, comme s'il s'agissait d'un temps révolu, mais c'est encore de cette manière très souvent que sont structurés les espaces de stockage.

Cette architecture présente plusieurs avantages :

1. Les responsabilités sont claires: chaque direction est responsable de SON espace, à la fois pour le structurer, le gérer, maîtriser le quota de stockage et les droits d'accès.

2. Le "narratif" est clair : "tous les documents de chaque direction est dans son propre espace".

3. Enfin, et c’est le corollaire du précédent : tous les documents d'une direction sont centralisés au même endroit, ce qui facilite (en théorie seulement) la recherche des documents. Bref c’est le « chacun chez soi » et le « chacun pour soi » dans toute sa puissance.

Sur le papier tout cela semble logique mais dans la réalité tout n'est pas si simple. Tout d’abord au sein d’une même direction, des personnes de pôles différents collaborent ensemble : si tous les fichiers sont rangés dans des dossiers qui collent exactement à l'organisation de la direction, trouver les documents nécessite de savoir qui se charge de ces sujets, car dans la logique du "chacun chez soi" les documents sont « chez eux ». Et quand la collaboration se fait avec des personnes externes à la direction, ça se complique encore plus.

Car si l’entreprise est un peu sérieuse, des "droits" et "autorisations" sont positionnés sur les dossiers et dossiers car on ne laisse pas tous les employés de l’entreprise mettre leur nez dans les fichiers des directions Finances, DSI, ressources humaines, avec la possibilité de les lire et de les modifier. Enfin, espérons.

Pour ces sujets transverses (au sein d’une même direction ou entre plusieurs directions), très souvent l’équipe « propriétaire du sujet » (autrement dit le « porteur ») va créer dans SON DOSSIER de pôle un dossier de partage sur ce sujet (projet, groupe de travail, autre).

Et c’est ici que se met en place ce que j'appelle "le plat de spaghetti" en termes de droits. Car la logique informatique, c’est l’héritage des droits d’un dossier vers son contenu :fichiers et sous dossiers. Or quand on créé un dossier pour stocker des fichiers d’un sujet transverse (projet, autre), on doit « inviter chez soi » des personnes qui n’ont théoriquement pas le droit d’accès : pour cela, on « casse l’héritage » pour « laisser passer » les invités : c’est ce que j’appelle de la gestion de droit au chausse pied et ce n’est pas sans conséquence.

La première conséquence et la plus grave, c’est ce fameux « plat de spaghetti » des droits & autorisations, quand on invite des personnes étrangères au coeur d’un espace de partage qui leur est normalement interdit. Généralement au bout d’un temps relativement court, plus personne ne sait réellement qui-accède-à-quoi et avec quel pouvoir (lecture, ajout, modification, suppression). Vous l’avez certainement vécu : des personnes légitimes n’ont pas accès aux documents alors que des personnes qui ne devraient pas y accéder, y accèdent. Bref, c’est le « bazar », comme je l’évoque dans cet article : Gestion des droits : le grand bazar !

La seconde conséquence, c’est qu’il est très compliqué de savoir où sont les documents d’un sujet transverse, comme un projet par exemple, puisque ces sujets transverses sont « éparpillés » dans tous les sous dossiers des directions / Divisions / Domaines / Pôles. Pour savoir où sont physiquement stockés ces documents, il faut savoir QUI est le porteur car ces documents sont « chez lui », même si dix autres entités complètement différentes travaillent sur le sujet. Autant dire que l'onboarding des nouveaux employés est assez folklorique.

Casser les silos avec SharePoint & Teams : la grande illusion

Beaucoup attribuent aux seuls vieux serveurs de fichiers la responsabilité de l'existence de ces "silos". C'est ainsi que de nombreuses migrations dans SharePoint (ou Teams) se font avec l'objectif de "casser les silos". Mais ce n'est pas l'outil qui fait les silos : c'est la manière de structurer les contenus et de penser les scénarios de collaboration.

Ainsi, dans une très grande majorité des cas, les migrations de serveurs de fichiers dans des sites SharePoint se font quasiment à l'identique : on copie l'arborescence du serveur de fichiers dans une liste documentaire d'un site SharePoint. J'évoque ce sujet dans cet article : Focus sur la migration des serveurs de fichiers vers Microsoft 365.

Ce choix se comprend : c'est plus simple à faire (pas de réflexion à mener), plus rapide à accompagner (pas d'explication à donner - ou très peu) et surtout, c'est plus rapide. On retrouve donc dans SharePoint la même logique d'arborescence de dossiers / sous dossiers calquée sur l'organisation de l'entreprise, et donc la même logique de partage des fichiers des sujets transverses... et donc les mêmes problèmes.

Cette reproduction à l'identique est une mauvaise idée pour deux raisons. La première c'est que SharePoint n'est PAS un serveurs de fichiers : il ne faut donc pas chercher à reproduire l'expérience utilisateur des serveurs de fichiers avec SharePoint (notamment avec la synchro pour "imiter" les serveurs de fichiers) comme je l'explique plus en détail dans cet article : Serveurs de fichier versus Microsoft 365 : quelle expérience utilisateur ?. SharePoint est un excellent outil de gestion documentaire, mais pas sous l'angle d'un vulgaire serveur de fichiers : il faut adapter le scénario d'usage.

La seconde raison, c'est que si vous conservez la même logique d'arborescence, vous ne réglerez pas du tout le problème de silo : vous ne ferez que le reproduire le problème dans un autre outil. Pour que ça fonctionne, comme avec le serveur de fichiers, vous serez obligés de "tordre le bras" aux droits positionnés sur les dossiers, en cassant les héritages : dans quelques semaines, vous ne saurez plus qui-accède-à-quoi, tout comme sur votre vieux serveur de fichiers.

D'autres choisissent Teams pour casser les silos. Mais là aussi, ce n'est pas toujours une réussite, car deux erreurs sont souvent commises.

La première erreur est de confondre Microsoft Teams avec un serveurs de fichiers : les équipes et les canaux sont créés comme des dossiers de stockage, en oubliant que le principal usage de Teams est avant tout de canaliser le dialogue, à la place des mails. Les fichiers sont dans des canaux Teams, mais les équipes continuent de dialoguer avec les mails : bref, ça n'a aucun intérêt et c'est même contre productif. Dans ce cas, mieux vaut carrément ne PAS utiliser Teams et n'utiliser que des sites SharePoint correctement structurés.

La seconde erreur, c'est de reproduire sans le vouloir le même phénomène de silo, mais dans Teams. Je m'explique : souvent, des équipes Teams sont créées pour une direction, une division, un domaine, un pôle. Jusque là, pas de problème. Mais pour chaque entité porteuse de sujets transverses (projets, etc), le réflexe est de reprendre les vieilles habitudes en créant des canaux privés ou des canaux partagés pour faire entrer "chez soi" des collègues externes qui travaillent sur "nos sujets", via des canaux privés (très mauvaise idée) ou partagés (moins mauvaise idée).

Pour couronner le tout, les canaux reprennent très souvent la même arborescence des dossiers du serveur de fichiers (puisque Teams est vu comme un serveur de fichiers et les canaux comme des dossiers). Pour reprendre l'exemple donné ci-dessus, on se retrouve avec ce type d'équipe Teams :

Exemple d'une équipe Teams pour le pôle 02, avec des canaux de projet transverses

Bref, on reproduit la même erreur qui consiste à faire entrer "chez soi" des personnes étrangères à l'environnement de travail pour travailler sur des sujets transverses. On retrouve les mêmes problèmes que ceux que j'ai décrits pour les serveurs de fichiers, mais avec Teams. Bref, les silos ne sont pas cassés : ils sont reproduits sous une autre forme, plus moderne.

Casser les silos, ce n'est pas donner accès à tout et à tout le monde

Ceux qui ont connu les premiers pas des Réseaux Sociaux d'Entreprise (RSE) il y a 15 ans ont connu cette utopie à l'époque : "on n'a rien à cacher, tout doit être public, tout le monde doit pouvoir accéder à tout" : il fallait que toutes les communautés du RSE soient ouvertes à tout le monde, même les communautés d'animation de pôles ou de projet.

On voit maintenant cette mauvaise idée avec Teams.

Mais casser les silos, ce n'est pas donner accès à tout, et à tout le monde, en particulier avec Teams.

La principale raison c'est que les entités ont besoin de ce que j'appelle "leur espace d'intimité" : si je suis manager, je vais parler (dans mon équipe Teams) à mes équipiers de manière libre, sur des sujets qui nous regardent, sur un ton libre parce que nous sommes "entre nous". Si je sais que n'importe qui peut venir voir ce qu'on dit entre nous, mes équipiers utiliseront le mail pour éviter que d'autres lisent nos échanges, plutôt que de dialoguer dans les canaux. Microsoft Teams perdra ainsi tout intérêt.

L'autre raison, c'est que donner accès à toutes les équipes Teams, à tout le monde, va multiplier le nombre d'équipes visibles dans Microsoft Teams (le bandeau de gauche). Les collaborateurs se plaignent déjà d'avoir trop d'équipes : vous allez les polluer avec des équipes qui ne les concernent pas pour la plupart. Non seulement ça va les polluer mais surtout, ça va les agacer et ça risque de "couler Teams" dans votre entreprise : j'en parle dans cet article Comment éviter de couler Teams dans votre entreprise ?

Autre raison encore, vous allez complètement paumer vos collaborateurs : plutôt que d'avoir quelques équipes Teams dont le narratif et les objectifs sont clairs, vous allez leur servir une bouillie d'équipe Teams sans explication : à eux de se démerder avec. Bien entendu, le partage d'un canal peut se faire dans une autre équipe (voir cette vidéo) pour simplifier les accès, mais cette maîtrise est très rare et ça ne règle pas tous les problèmes.

La bonne approche pour casser les silos...

Mauvaise nouvelle : il n'existe pas de recette miracle. Quand j'interviens dans les entreprises pour "casser les silos", chaque approche est personnalisée en fonction de l'entreprise, de sa taille, de son métier, de ses enjeux, de son ambition, de ses contraintes, de la nature de la collaboration, des questions de confidentialité et de sécurité de la donnée, et j'en passe.

J'ai cependant quelques conseils que je peux donner...

Le premier grand conseil est de ne pas mélanger les choux et les carottes. Par exemple, si vous construisez une équipe Teams pour animer votre propre direction ou votre propre pôle (voyez un exemple en cliquant ici), réservez cette équipe aux seuls membres de votre entité, sans y intégrer des externes pour cause de sujets transverses : ces sujets transverses seront traités ailleurs. Votre équipe Teams de pôle doit être réservée à l'animation de votre pôle et à rien d'autre : déjà, en termes de narratif, ce sera beaucoup plus clair pour tout le monde.

Exemple d'une équipe Teams d'animation d'équipe

En fait, casser les silos, c'est surtout construire des dispositifs 100% orientés collaboratifs.

Par exemple, si vous êtes porteur d'un projet, construisez une équipe Teams qui sera 100% dédiée à ce projet, avec différents canaux pour les différentes phases de votre projet. Invitez dans cette équipe tous les intervenants du projet : vos propres collègues et tous les acteurs des autres directions qui participent à ce projet. Cette équipe Teams sera avant tout "l'équipe du projet" et chacun aura l'impression d'être "dans l'espace projet" et non chez vous". Découvrez un exemple en cliquant ici.

Exemple d'équipe projet

Peut être travaillez-vous sur de "petits projets" qui ne nécessitent pas forcément une équipe complète. Dans ce cas, je créé volontiers une équipe Teams "PROJETS" dédiée, avec un canal partagé par projet, pour y inviter les participants de chaque projet. Mais cette équipe est 100% dédiée aux projets : elle est 100% transverse. Là aussi, en termes de narratif et d'explication, c'est très clair.

Autre recommandation, et non des moindres :

Utilisez les équipes Teams pour dialoguer, pas uniquement pour partager les fichiers. Car casser les silos, c'est aussi et avant tout partager l'information, communiquer, informer.

Teams est ici un grand avantage car l'usage de la messagerie n'encourage pas la communication: envoyer des mails, surtout à des équipes de plusieurs dizaines ou centaines de personnes, c'est une action très intrusive et du coup, on y réfléchit toujours à deux fois. En plus si vos interlocuteurs répondent à vos mails cela peut générer des échanges de dizaines de mails qui vont engorger les messageries et bloquer la collaboration : vos interlocuteurs pourraient vous le reprocher.

A l'inverse, poster un message dans le canal d'un projet pour donner une information (même mineure) ne gêne en rien : tout le monde peut y répondre, faire un "like" sans que cela ne bloque pas votre outil de travail. N'oubliez pas qu'en premier lieu, Teams est un outil de dialogue au travers des canaux des équipes Teams.

Lorsque je recommande ce type d'architecture, on me reproche souvent d'éparpiller les documents des projets, plutôt que de les rassembler.

Mais en fait, travailler en silo avec le serveur de fichiers ou SharePoint est aussi un éparpillement : les docs du projet TRUC porté par le pôle X de la direction Z se trouve dans leur arborescence tandis que les docs du projet MACHIN porté par le pôle W de la direction Y est dans une autre arborescence, et ainsi de suite. Ca ne semble centralisé qu'aux yeux des porteurs des projets, pour leurs seuls projets : pour tous les autres, tout est dispersé.

A l'inverse, créer des dispositifs dédiés 100% aux sujets transverses, que ce soient des projets, des groupes de travail ou des processus, cela clarifie beaucoup l'architecture de l'information et les scénarios d'usage.

En plus, positionner les acteurs en membres d'équipe Teams projet permet d'afficher ces équipes Projets directement dans "leur Teams". Plus besoin de partir à la pêche dans une obscure arborescence de serveurs de fichiers : tout est clairement visible.

L'ingénierie de la collaboration

Cliquez pour accéder

En 2021, je publiais un livre blanc intitulé "L'ingénierie de la collaboration" dans lequel j'évoquais la nécessaire réflexion que toute entreprise doit mener pour définir une architecture pertinente avec Teams et SharePoint, afin de gérer correctement la collaboration, le dialogue et le partage documentaire.

Au cours de ces 5 dernières années, je mesure à quel point cette réflexion est rare dans les entreprises par manque de compétence interne, par manque de connaissance des enjeux, des risques et des opportunités, ou tout simplement par manque d'intérêt. C'est un gâchis phénoménal en efficacité et en opportunités.

La raison est souvent aussi le manque d'ambition, car casser les silos, au delà de cette formule bateau qui reste un voeux pieux, cela nécessite un changement de scénarios de travail car si vous ne changez rien, rien ne changera.

Casser les silos, c'est comme faire pivoter votre mode de pensée d'un quart de tour : il faut penser collectif au lieu de penser uniquement pour sa propre entité. Il faut penser transversalité, sans tomber dans l'excès qui consisterait à ouvrir toutes grandes les portes des fonds documentaires et des équipes Teams, pour un résultat contre productif.

C'est une démarche d'entreprise, car un tel virage ne se prendra jamais sans un sponsoring fort, sans une démarche bien réfléchie et sans un accompagnement ambitieux.

Bref, si vous voulez casser du silo, n'hésitez pas à me contacter pour que nous en parlions.

cliquez pour découvrir le livre