L’innovation n’est pas un sujet sur lequel la DSI doit conquérir sa place, elle y est déjà incontournable. La vraie question est de savoir si elle se contente d’accompagner ce qu’on lui demande, ou si elle ose, parfois, prendre la place et imposer une transformation que personne n’avait encore formulée.
L’innovation n’est pas un sujet sur lequel la DSI doit conquérir sa place. Contrairement à d’autres dimensions où elle peine à se faire entendre, l’innovation métier passe aujourd’hui presque systématiquement par une traduction technologique, une application digitale, une évolution de process qui s’appuie sur le système d’information, un nouveau service porté par une plateforme. Il n’y a quasiment plus d’innovation significative dans une entreprise sans implication réelle de la DSI. La question n’est donc pas de savoir si elle doit être à la table. Elle est d’apprendre à y jouer le bon rôle.
Un projet de plus, ou un rythme adapté ?
Le piège le plus fréquent commence dès l’intégration de l’innovation dans le flux de travail de la DSI. Un projet né d’une idéation métier devient, mécaniquement, un projet de plus dans un portefeuille déjà sous tension, traité avec les mêmes rituels de cadrage qu’un projet classique. Or l’innovation, par définition, porte des incertitudes que les autres projets n’ont pas : des process nouveaux pour l’entreprise, des cas d’usage sans retour d’expérience préalable, des choix techniques pas encore éprouvés.
Imposer un cadrage traditionnel à ce type d’initiative est souvent contre-productif : on peut y passer un temps considérable, pour une valeur nulle, alors qu’un POC rapide aurait démontré la valeur réelle, ou révélé les contraintes et opportunités, en quelques semaines. C’est à la DSI de mettre en place des dispositifs de delivery adaptés à ce rythme plus court et plus réactif : un alignement rapide sur ce qu’on cherche à apprendre et sur les critères de succès, plutôt qu’un cadrage exhaustif avant tout test.
Mais ces dispositifs, souvent désignés sous les termes d’agilité ou de mode produit, ne suffisent pas s’ils ne sont pas accompagnés d’une évolution de la posture managériale. Exiger un ROI démontré sur chaque initiative d’innovation revient à nier la nature même de l’exercice : une partie des tests ne donnera rien, et c’est précisément ce qui permet d’apprendre rapidement où investir vraiment. Sans cette double détente, dispositif de delivery adapté et tolérance managériale au résultat incertain, l’innovation reste un concept évoqué, jamais réellement incarné.
Reste un défi opérationnel rarement anticipé : ce modèle de delivery adapté suppose de mobiliser des compétences et des savoir-faire qui sont, par nature, diffus dans l’organisation. Un sujet d’innovation touche presque toujours un process métier précis, ce qui implique de réquisitionner les acteurs qui détiennent cette connaissance applicative et métier spécifique, souvent déjà engagés sur d’autres priorités, ce qui percute directement la gestion des ressources classique. S’y ajoute une difficulté humaine : certains profils, à l’aise dans des modes de delivery plus traditionnels, s’adaptent difficilement à des contraintes et des rythmes différents. Ce défi d’animation des compétences et des personnes n’est pas un détail d’exécution, c’est l’un des points sur lesquels les DSI échouent le plus souvent à transformer l’intention en pratique réelle.
Des cellules d’innovation transverses, pas des labs isolés
La façon dont l’innovation est organisée dans l’entreprise change radicalement son efficacité. Ce qui fonctionne bien, ce sont des cellules d’innovation transverses, pluridisciplinaires, qui intègrent largement des acteurs IT, pas comme observateurs, mais comme contributeurs à part entière, capables de ramener à la fois des contraintes et des opportunités dans la réflexion.
La condition de réussite, souvent négligée, est que ces équipes IT au sein de la cellule restent connectées au reste du cadre technique et technologique porté par la DSI. Un lab d’innovation isolé, qui fonctionne en vase clos avec ses propres règles, produit des prototypes séduisants mais déconnectés des contraintes réelles de l’entreprise et c’est précisément ce qui rend leur généralisation impossible une fois le test terminé. L’innovation qui se transforme vraiment est celle qui a été pensée, dès le départ, avec une vision de ce qui est possible de faire à l’échelle, et des contraintes qu’il faudra intégrer pour y arriver.
La DSI comme Business Hacker : prendre la place, pas attendre l’invitation
Au-delà de sa participation aux cellules d’innovation, il y a un rôle plus radical que la DSI peut choisir d’endosser et que la plupart évitent par prudence ou par habitude hiérarchique : ne pas attendre que le métier formule une demande, mais imposer une transformation dont elle est convaincue, parce qu’elle a identifié une valeur et un impact que personne d’autre n’a encore vus.
C’est précisément ce que le terme « Business Hacker » porte de provocateur. Hacker, ici, ce n’est pas transgresser pour le plaisir de transgresser. C’est refuser l’entre-soi légaliste « j’ai le mandat, donc j’attends qu’on me le demande », quand la DSI sait que négocier patiemment cette conviction dans les canaux habituels la diluerait dans des mois de gouvernance, de comités d’arbitrage et de jeux politiques. Une DSI qui hacke prend parfois la place plutôt que d’attendre une invitation qui ne viendra jamais, ou qui viendra trop tard pour que l’innovation ait encore un sens.
Ce n’est pas une posture sans risque, et elle ne se justifie pas pour n’importe quel sujet. Elle suppose une conviction réelle, étayée, pas un coup d’éclat technologique gratuit. Mais c’est précisément cette audace qui distingue une DSI qui se contente d’accompagner ce qu’on lui demande d’une DSI qui transforme l’entreprise au-delà de ce qu’elle savait demander.
La réalité, c’est que beaucoup de DSI ont déjà ces sujets en tête. Elles savent identifier, sur certains périmètres, où une amélioration significative serait accessible si elles prenaient le sujet de bout en bout, à la place du métier, pour sortir un résultat impactant rapidement. Le problème n’est donc pas un manque d’idées. C’est que ce risque est rarement pris, parce qu’il est difficile à assumer : si le pari échoue, ou s’il prend trop de temps, le métier ou la DG ne retiendront pas l’audace de la tentative, ils reprocheront à la DSI de ne pas avoir tenu ses engagements de base pendant qu’elle s’aventurait ailleurs. Cette asymétrie explique en grande partie pourquoi si peu de DSI franchissent réellement le pas : il faut être à peu près sûr de sortir un résultat convaincant pour ne pas se faire prendre en faute sur le reste.
La technologie est, par nature, un gisement pour cette conviction. La DSI a une double légitimité pour l’exploiter : elle connaît les processus métier, largement retraduits dans le système d’information et elle connaît les technologies, leurs roadmaps, leur potentiel réel. Cette double connaissance lui permet d’aller plus loin qu’une simple vulgarisation polie : « voilà ce qu’on va construire, parce que j’ai la conviction que ça transformera votre activité et que vous attendre à le formuler vous-même nous aurait fait perdre un temps que nous n’avons pas. »
L’intelligence artificielle illustre ce rôle de façon particulièrement nette, et particulièrement inconfortable pour la DSI. Le réflexe naturel de l’entreprise est de se tourner vers elle pour obtenir de la valeur de l’IA, alors que le gisement de valeur se trouve très largement dans la transformation des processus métier eux-mêmes. Une DSI qui se contente d’attendre que le métier vienne chercher ce potentiel laisse, le plus souvent, ce potentiel inexploité. Une DSI qui hacke ne demande pas la permission de le démontrer.
La donnée et le legacy : les deux fondations qu’on continue d’esquiver
Il y a deux sujets structurels sans lesquels aucune innovation technologique ne peut vraiment porter ses fruits — et que les entreprises traitent encore trop superficiellement.
Le premier est la donnée. Quelle que soit l’innovation envisagée, IA ou toute autre technologie émergente, sa valeur dépend directement de la qualité de la donnée sous-jacente. Nettoyer, structurer et gouverner les données est un sujet largement porté à l’initiative de la DSI, mais qui reste insuffisamment pris à bras-le-corps dans la plupart des entreprises. C’est une clé de voûte trop souvent négligée parce qu’elle ne produit pas, en elle-même, un résultat visible et démontrable, contrairement à un POC séduisant.
Le second est le legacy. Il est facile, et tentant, de désigner la dette technique comme le frein principal à l’innovation, les nouveaux systèmes permettraient de tout faire, si seulement le legacy ne pesait pas autant. Mais les DSI qui parviennent réellement à innover sont celles qui regardent leur legacy en face, plutôt que de le contourner indéfiniment. Cela suppose des choix explicites : quelles parties du patrimoine applicatif ne recevront plus d’investissement, et lesquelles méritent un effort de modernisation pour devenir le socle des innovations futures plus modulaire, plus flexible, plus connecté.
Sans cette double base, donnée maîtrisée, legacy assumé et travaillé les DSI se retrouvent à courir après des innovations de court terme, souvent superficielles, qui ne s’industrialisent jamais vraiment. C’est un travers fréquent : une innovation réactive, motivée par l’envie de montrer un résultat rapide, plutôt qu’une stratégie technologique pensée pour permettre l’innovation dans la durée.
Le vrai test : la capacité à généraliser, pas la séduction du test
Le foisonnement de POC a sa valeur, il permet de tester des idées rapidement, à moindre risque. Mais le véritable enjeu ne se loge pas dans la réussite du test. Il se loge dans une question qu’on pose trop rarement avec la rigueur nécessaire : cette innovation, est-elle réellement déployable à l’échelle de l’entreprise ?
Une innovation séduisante en POC mais impossible à industrialiser n’a pas fait gagner de temps à l’entreprise, elle lui en a fait perdre. Et c’est précisément là que se trouve l’exercice le plus délicat : cette capacité à généraliser n’est jamais évidente à anticiper en amont. On peut croire qu’un sujet sera facile à déployer et découvrir, en cours de route ou à l’issue du POC, des difficultés techniques ou organisationnelles sous-jacentes qu’on n’avait pas vues venir. Ce n’est pas un échec de méthode, c’est la nature même de l’innovation que de comporter cette part d’incertitude.
C’est précisément sur ce point que la DSI peut faire une différence réelle. Pas en prétendant avoir une réponse certaine dès le départ, mais en étant capable d’expliciter, au fur et à mesure que le sujet se précise, ce que le passage à l’échelle va concrètement supposer : quel modèle de delivery faudra-t-il mettre en place, quelles contraintes organisationnelles le déploiement va-t-il générer, quelles dépendances techniques restent à lever. Cette capacité de projection, exercée avec honnêteté plutôt qu’avec excès de certitude, est ce qui distingue une innovation qui reste un test satisfaisant d’une innovation qui devient réellement transformante pour l’entreprise.
Ce que cela implique concrètement.
Pour le DSI : oser, sur certains sujets à forte conviction, prendre la place plutôt qu’attendre une demande métier qui ne viendra jamais et porter la conviction que l’innovation se construit sur des fondations : donnée gouvernée, legacy assumé et travaillé.
Pour le CODIR IT : structurer des cellules d’innovation transverses connectées au reste de l’organisation IT plutôt que des labs isolés, arbitrer les choix d’investissement ou de désinvestissement sur le legacy, et anticiper le défi de mobilisation des compétences et des profils qu’un dispositif de delivery adapté à l’innovation suppose.
Pour les managers IT : intégrer les sujets data et architecture dans toute réflexion d’innovation dès l’amont, et accompagner les porteurs de projets dans l’anticipation des contraintes de déploiement à l’échelle plutôt que de les découvrir trop tard.
Pour les métiers : s’approprier les pistes d’inspiration technologique proposées par la DSI sans en faire un simple cahier des charges à exécuter, accepter qu’un test concluant ne vaut pas encore une transformation acquise, et renoncer à exiger un ROI démontré sur chaque initiative d’exploration.
Votre démarche d’innovation produit-elle des tests satisfaisants, ou des transformations qui changent vraiment votre activité ? Participez à notre enquête sur le positionnement des DSI et comparez-vous à vos pairs → ici
