Dans une entreprise traditionnelle, dont le métier ne prend pas sa source dans la Tech’ (c’est à dire, l’informatique et tout ce qui s’appuie dessus), il est habituel d’avoir une DSI, ou autre département “Tech”, dédié à ces expertises.
Cela arrive naturellement, soit parce que ces compétences sont vues comme alien, nécessitant des profils spécifiques, avec des modes de fonctionnement bien à eux, ou parce que des éléments de gouvernance s’en mêlent — le premier étant bien entendu la cybersécurité.
Pour autant, tous les signaux ne pointent pas dans cette direction. C’est pourquoi il est normal de voir diverses initiatives qui prennent forme au sein des départements métiers ; des initiatives historiques, qui datent d’avant cette DSI, comme des initatives récentes, où l’on pourrait presque avoir l’impression que la DSI est ignorée.
Bien sûr, quand cela arrive, les explications sont multiples :
La DSI est considérée comme inefficace, trop lourde, trop coûteuse… Ou tout simplement on n’a pas confiance dans la qualité de ses livrables. Logique, dans ces conditions, que les métiers cherchent des alternatives.
Il peut aussi y avoir des dynamiques très humaines : on aime encadrer directement les personnes qui font le travail.
Parfois, ce sont pour de mauvaises raisons : un besoin de contrôle.
D’autres fois, ce sont pour de bonnes : il n’y a en effet pas plus agile que des développeurs directement intégrés dans le quotidien des métiers, dans le même bureau et en échange direct.
Une perception que la DSI est là pour des sujets techniques que l’on ne comprend pas. On veut bien envisager que ce soient des choses nécessaires et pour lesquelles il faille donc payer, mais on ne les comprend pas pour autant. Donc, quand il est question d’adresser un sujet dont l’impact sur le business est direct et clairement compris, on ne se dit pas que c’est à la DSI de s’en charger, car, “c’est un sujet métier”. (sous-entendu : contrairement à ce que fait la DSI)
Pour couronner le tout, l’IA amplifie ça ! Il est désormais possible d’enclencher des chantiers d’envergure pour bien moins cher, rendant la DSI comme une alternative encore plus coûteuse et inefficace en comparaison. On voit aussi de plus en plus de métiers s’emparer eux-mêmes du sujet, que cela soit via des applications Low Code / No Code ou même via du Vibe Coding.
Se pose donc naturellement la question :
Quel positionnement devrait prendre une DSI ?
En soi, il n’y a pas de mauvaise option.
Il y a des bénéfices ainsi que des problèmes à gérer, autant dans une démarche de centralisation que dans une démarche de décentralisation.
Dans les faits, il est même habituel, et en réalité normal et désirable, de suivre un cheminement un peu chaotique entre ces deux extrêmes :
Pour explorer, expérimenter et trouver ce qui fonctionne le mieux
Parce que le contexte change au fil du temps, et ce qui correspondait aux enjeux métiers ainsi qu’à son organisation à un moment donné n’est plus le même quand ces enjeux et cette organisation évoluent
(et d’ailleurs, les deux aspects s’influent mutuellement : on va chercher un mode de fonctionnement adapté aux enjeux et à l’organisation, mais l’organisation ainsi que les enjeux dont on peut se saisir vont évoluer en fonction du mode de fonctionnement expérimenté…)
Enfin, car tout est en nuances ! Rien ne marche parfaitement bien, on est rarement uniquement dans les extrêmes, c’est un chemin de crête qui nécessite d’alterner
Pourquoi décentraliser ?
La décentralisation, cela va être la cible idéale dans l’esprit des agilistes. Un monde merveilleux où l’on découpe les problématiques métiers en plus petits morceaux pour pouvoir les adresser par des petites équipes indépendantes, autonomes et en capacité de prise de décision. On aime bien utiliser le terme anglais d’empowered teams pour passer ce sens. 1
On désigne souvent cette approche par “passer en mode produit” ou de faire une “organisation produit”. On l’oppose également souvent à un fonctionnement à l’échelle, on évoquant une organisation qui cherche à unscale les problèmes à résoudre, plutôt qu’à scale l’organisation. 2
Spoiler : c’est très beau sur le papier, mais ça ne marche pas vraiment en pratique — ou plutôt, ça ne marche pas avec la simplicité avec laquelle on l’énonce.
Tout d’abord parce que le fond du sujet, la vraie difficulté, ce n’est pas tant la manière de s’organiser que les niveaux de délégation. Ce type de changement est une modification fondamentale de philosophie et de contrats sociaux au sein de la société. Possible, oui — des organisations le font !3 — mais cela nécessite une véritable volonté, profonde et authentique. Si la majorité des organisations sont en transformation ou en nécessité de se transformer, celles prêtes à passer ce cap se font bien plus rares.
Ensuite parce qu’en pratique, on reste dans un contexte à l’échelle. On veut garder une forme de contrôle sur les équipes. On veut construire tout un écosystème autour de ces équipes pour les aider, mais également pour les garder alignées avec les enjeux collectifs.
Pour conclure cette section :
Décentraliser, en théorie c’est bien.
En pratique, on commence rarement par là.
Pourquoi centraliser ?
À l’inverse, on peut plutôt chercher à centraliser. Les raisons de passer par là ne manquent pas :
Des enjeux collectifs qu’il est très difficile de porter à l’échelle sans aucune centralisation — un des meilleurs exemples restant, à nouveau, la cybersécurité
Optimiser les coûts, par exemple en s’assurant que l’on ne se saisit pas de la même initiative en double, ou en mutualisant les coûts d’hébergement et autres licences
Mettre en place une gouvernance pour garantir un niveau de qualité élevé, ou pour s’assurer d’une bonne utilisation de la capacité disponible (priorisation)
Reprendre le contrôle sur l’existant et couper court au shadow IT où il n’y a aucune garantie de qualité, de maintien en conditions opérationnelles, de cybersécurité, de coûts de fonctionnement…
Un turn-over élevé, potentiellement lié à un recours massif aux externes, et qui nécessite une forme de centralisation pour garantir la pérennité de la connaissance et un niveau satisfaisant de maintien en conditions opérationnelles
Cette liste n’est pas exhaustive, mais elle couvre probablement les raisons les plus courantes.
Dans une organisation qui grandit, on voit généralement une dynamique de mise en place d’une DSI avec une posture de centralisation. C’est normal.
La centralisation est souvent inévitable
Même avec l’ambition de décentraliser, on doit souvent passer par une étape de centralisation.
Décentraliser, cela ne veut pas dire le Far West.
Décentraliser, c’est beau sur le papier.
Pour que cela marche bien, il faut réussir à mettre en place de nombreux éléments techniques et organisationnels — en plus des enjeux culturels évoqués plus haut autour des niveaux de délégation.
L’excellence technique : sans filet de non-régression automatisée et sans architectures visant à réduire les adhérences, l’autonomie des équipes ne fera pas long feu. La gestion des dépendances entre équipes prendra le pas sur la volonté d’autonomie.
Plus largement, la rationalisation et l’industrialisation des modes de fonctionnement.
Au-delà des processus et outils, il est aussi simplement question de faire monter en compétence le collectif sur ces aspects, et à développer le leadership nécessaire à tout les niveaux.
Et également avoir une vision globale suffisamment forte, un alignement suffisamment clair pour permettre l’autonomie. Par extension, le style managérial dans la société va également être un ingrédient clé.
Ces éléments, et d’autres, sont des prérequis à une décentralisation qui ne rime pas avec anarchie.
Sans ces prérequis, tout reste possible, mais le chemin à parcourir devient alors bien plus difficile ! La sagesse suggère plutôt de limiter les challenges et de les adresser par étapes.
La dimension transformationnelle
Un autre aspect, c’est la dimension transformationnelle que porte la DSI.
Souvent, la DSI se retrouve également en charge de la transformation des métiers. Parfois en soutien, d’autres fois à donner l’impulsion et à embarquer les métiers. Tout dépend du contexte : mécaniquement, plus la transformation est liée à la digitalisation des manières de travailler, plus la DSI va se retrouver au cœur du réacteur.
La manière dont la DSI se transforme elle-même va poser des bases essentielles par rapport aux métiers, comme par exemple la mise en place d’une gestion capacitaire avec un plan au trimestre forçant à prioriser les initiatives.
Une phase de centralisation aide à insuffler, porter et supporter cette dynamique de transformation. On pose les règles du jeu, ce que la centralisation permet ou facilite.
Le plus important : ne rien figer dans le marbre
Je ne suis pas en train de promouvoir la centralisation comme la réponse absolue à tous les problèmes. Je reste persuadé que la décentralisation permet d’atteindre des niveaux de performances bien supérieurs.
Néanmoins, la mise en place de la décentralisation nécessite généralement d’y aller progressivement. À court et moyen terme, la centralisation apporte de nombreux bénéfices par lesquels il faut passer avant d’espérer embrasser la décentralisation.
Quoi qu’il arrive, le plus important reste donc d’avoir une posture claire d’expérimentation, ainsi que de travailler le biais des coûts irrécupérables.
Bref, il faut se réinventer en permanence !
Nous avions mis en scène ce type de situation et ses enjeux sur Scrum Life dans une vidéo de la série “La gestion de produit en pratique” :
Nous évoquions ce concept de “unscale the problem” dans ce Scrum Life qui présentait à haut niveau les approches principales d’agilité à l’échelle :
Et je me sens obligé de citer Rachel Dubois qui s’est faite une spécialité d’accompagner des organisations dans ce cheminement !
