Beaucoup de DSI ont une stratégie IT. Peu en ont une qui guide réellement les décisions du quotidien, qui parle business, et qui engage autant les équipes IT que les directions métiers. La différence entre les deux tient moins à la qualité du document qu’à la façon dont il est construit, animé et prolongé dans les modalités concrètes de collaboration.
De « je rends possible » à « je contribue à définir »
Pendant longtemps, le positionnement implicite de beaucoup de DSI a été celui-ci : vous définissez la stratégie business, je me charge de la rendre techniquement possible. Un rôle de support, légitime dans sa forme, mais qui place la DSI en aval des décisions, là où elle peut difficilement peser sur ce qui est décidé.
Ce positionnement évolue. La dimension technologique a pris une place trop importante dans la compétitivité des entreprises pour que la DSI reste en dehors du débat stratégique. Les directions générales sont aujourd’hui à l’écoute, parfois en demande, d’une lecture IT sur les orientations à prendre.
Mais faire ce saut n’est pas naturel. Certains DSI se voient encore eux-mêmes comme en support du positionnement stratégique. Et même quand la volonté est là, la principale difficulté reste la même : comment traduire les enjeux technologiques en langage business, de façon à ce que le COMEX puisse s’en saisir pour décider et non pas subir une présentation technique de plus.
Le techno push : proposer, pas évangéliser
Un DSI qui contribue vraiment à la stratégie ne répond plus seulement aux questions qu’on lui pose. Il en pose. Il arrive avec une lecture de ce que la technologie rend possible une plateforme bien construite, des données fiables et structurées, une capacité d’automatisation et il crée les conditions pour que les métiers puissent se projeter à partir de là.
Ce n’est pas de l’évangélisation technologique. C’est une façon d’ouvrir le champ des possibles stratégiques : « voilà ce que nous pourrions faire que nous ne faisions pas avantqu’ est-ce que ça change pour vous ? » Le techno push bien utilisé ne vend pas une technologie. Il révèle des opportunités que les métiers n’avaient pas envisagées parce qu’ils ne savaient pas qu’elles étaient accessibles.
C’est là que la vulgarisation devient un vrai levier stratégique pas pour simplifier la technique, mais pour caractériser en quoi un choix technologique se traduit en avantage compétitif, en performance opérationnelle, en nouvelle relation client.
Mais proposer, révéler des opportunités, ouvrir le champ des possibles tout cela reste un registre d’influence. Le DSI qui devient Business Hacker va un cran plus loin : sur certaines convictions stratégiques fortes, il n’attend pas que le COMEX se saisisse de l’opportunité qu’il vient de révéler. Il engage déjà les premiers travaux, construit un premier socle, avance la preuve avant même d’avoir le mandat explicite parce qu’il sait que demander la permission en amont, c’est s’exposer à perdre des mois dans un cycle de validation qui tuera l’élan avant qu’il n’existe. Ce n’est pas contourner la gouvernance par principe. C’est accepter d’avancer le risque à sa charge quand la conviction est suffisamment forte pour le justifier, et présenter ensuite un résultat plutôt qu’une demande d’arbitrage.
Les fondations d’abord et c’est maintenant qu’on l’entend
Il y a un argument que les DSI portent depuis des années et qui commence seulement à être vraiment entendu : les transformations les plus ambitieuses butent toujours sur les mêmes écueils. Des systèmes en place mais mal utilisés. Des données incomplètes parce que les pratiques opérationnelles n’ont jamais vraiment été industrialisées. Des processus théoriques qui s’écartent de ce que vivent les équipes terrain souvent parce que l’accompagnement au changement a été insuffisant, parfois parce qu’on a préféré « vivre avec » plutôt que traiter le fond du problème.
Ce n’est pas l’IA qui a révélé ces fragilités. C’est la répétition des déceptions. Des POC prometteurs qui n’industrialisent pas. Des projets de personnalisation client qui achoppent sur la qualité des données. Des automatisations qui ne tiennent pas parce que les gestes opérationnels ne sont pas cohérents. À force de buter sur les mêmes écueils, les COMEX commencent à entendre autrement les diagnostics que les DSI portaient depuis longtemps.
C’est une fenêtre. Le DSI qui sait la lire n’est plus en train de défendre un budget de remise en ordre technique. Il est en train de montrer le chemin qui rend les promesses atteignables, celles de l’IA comme celles de toutes les transformations qui attendent depuis trop longtemps.
Mais attendre patiemment cette fenêtre, des années s’il le faut, a un coût que cette série a déjà nommé ailleurs : celui de tout le temps perdu avant qu’elle ne s’ouvre. Un DSI qui hacke ne se contente pas de guetter le moment où le COMEX sera enfin prêt à entendre l’argument des fondations. Sur les sujets qu’il juge structurants, il commence à les traiter avant d’avoir obtenu l’assentiment explicite, en mobilisant une marge de manœuvre déjà existante, en démontrant par un résultat tangible plutôt qu’en répétant un diagnostic que personne ne veut encore entendre. La fenêtre s’ouvre parfois plus vite quand on a déjà commencé à construire ce qu’elle rendra possible.
Une stratégie qui parle business et qui sert à arbitrer
Une stratégie IT qui ne parle qu’aux équipes IT n’est pas une stratégie d’entreprise, c’est un plan de charge. Pour qu’elle joue son rôle, elle doit être lisible par les métiers, construite avec eux, et suffisamment ancrée dans les enjeux business pour que chacun comprenne pourquoi les choix ont été faits.
Son utilité première n’est pas de planifier. C’est de servir de point de focalisation dans les moments d’arbitrage. Quand une urgence surgit, quand un projet séduisant arrive, quand deux priorités s’affrontent, la stratégie doit permettre de décider vite et bien, sans repartir de zéro à chaque fois. Elle autorise les chemins détournés, les entorses ponctuelles aux principes, à condition qu’on maintienne le cap vers la vision cible et qu’on gère consciemment l’écart.
Et parce que l’ambition dépasse presque toujours les moyens, elle doit aussi poser clairement les priorités, ce qu’on fait en premier, ce qu’on reporte, ce à quoi on renonce pour l’instant. C’est souvent là que la construction collective est la plus difficile et la plus nécessaire.
Définir comment on travaille ensemble : la stratégie prolongée en modalités de collaboration
Une stratégie IT est incomplète si elle ne dit pas comment DSI et métiers vont collaborer concrètement pour la mettre en œuvre. Ce n’est pas une question de mode opératoire c’est une question de cohérence : les modalités de collaboration doivent être le prolongement naturel de l’ambition stratégique, pas des décisions techniques prises séparément.
Trois niveaux sont à clarifier. Le premier : comment on décide d’engager les initiatives, gestion de portefeuille projet, choix d’une logique produit sur certains périmètres, critères de priorisation partagés entre métiers et IT. Le deuxième : comment on s’organise pour les mettre en œuvre, mode projet ou produit, répartition des responsabilités entre équipes métiers et IT, clarté sur qui porte quoi à chaque étape. Le troisième : qui décide de quoi, et dans quel cadre , les rituels de décision, leur périmètre, les acteurs qui y participent.
Ces trois niveaux forment un tout. Sans eux, la stratégie reste une intention bien formulée. Avec eux, elle devient un cadre dans lequel chacun sait comment contribuer et comment arbitrer quand les situations ne sont pas prévues.
Pas un exercice ponctuel un engagement collectif qui s’anime
Une stratégie IT se construit en un moment, mais elle vit dans la durée. Et c’est dans cette durée qu’elle prend ou perd son sens pour les équipes qui la font vivre au quotidien.
L’animer, c’est faire vivre les rituels de décision qui permettent d’arbitrer en cohérence avec la cible. C’est aussi se doter des moyens de suivre non pas l’écart à la lettre, mais la trajectoire réelle : en quoi s’écarte-t-on de la ligne directrice ? Quels principes ne jouent plus ? Faut-il adapter la cible, ou traiter concrètement ce qui dérive ?
Mais au-delà du pilotage, la stratégie est un engagement. Elle dit aux équipes : voilà pourquoi on fait ce qu’on fait, voilà où on va, voilà ce qui compte vraiment. Cet engagement mérite d’être regardé régulièrement avec un peu de recul, pour montrer ce qui progresse, expliquer ce qui s’adapte, et maintenir la confiance de ceux qui portent la transformation au quotidien. Une stratégie qu’on ne regarde que pour constater les écarts finit par ne plus inspirer personne.
Ce que cela implique concrètement.
Pour le DSI : prendre sa place dans le débat stratégique en caractérisant ce que la technologie rend possible pour le business, oser engager certains travaux avant d’avoir un mandat explicite quand la conviction le justifie, et construire la stratégie IT comme un outil de navigation partagé, prolongé dans des modalités de collaboration claires.
Pour le CODIR IT : porter la stratégie dans les arbitrages quotidiens, s’y référer, l’expliquer, l’adapter et faire vivre les rituels de décision qui donnent corps aux choix collectifs.
Pour les managers IT : participer activement aux rituels de décision à leur niveau, y faire vivre les éléments de la stratégie, en expliquant les choix faits, en remontant ce qui ne tient plus, et en aidant leurs interlocuteurs métiers à comprendre pourquoi les priorités sont ce qu’elles sont.
Pour les métiers : s’engager dans la construction de cette stratégie, assumer les priorités choisies collectivement, et jouer leur rôle dans les modalités de collaboration définies ensemble.
Dans votre DSI, votre stratégie IT guide-t-elle vraiment les décisions du quotidien et vos managers savent-ils s’y référer dans leurs échanges avec les métiers ? C’est l’une des tensions que nous explorons dans notre enquête sur le positionnement des directions SI. Participez et comparez-vous à vos pairs → cliquez ici
