Culture Innov’ : “La DSI m’a tuer”

Faits divers - **"L’innovation défenestrée, la DSI soupçonnée"

**

Il fait encore nuit et brumeux ce lundi matin lorsque Henri arrive en bas de la tour de cette multinationale. Il n’est que 5h34 lorsqu’il prévient la police. En bas de la tour gît dans une mare de sang …. une innovation.

Scène de crime (D. Lequepeys)

Depuis plus de cinq ans, l’innovation est devenue la mode utile. Chacun y va de son incubateur, son lab d’innovation, son tiers lieux. Mais malheureusement, nous voyons de plus en plus d’innovations qui ne réussissent pas à sortir de ces cellules dédiées, qui ne parviennent pas à se rattacher aux métiers ou qui ne parviennent pas à grandir, scaler pour atteindre une taille respectable avec un impact visible . Plusieurs explications sont avancées. Le manque de moyens en temps et en argent, la qualité des personnes mais il s’avèrent que la DSI est aussi désignée comme le suspect idéal. Autopsie d’un meurtre presque parfait.

Quels sont les soupçons sur la DSI pour tuer l’innovation ?

La DSI présente un certain nombre de raisons pour assassiner l’innovation. Passons en détail les accusations portées à la DSI pour ne pas aider l’innovation à grandir et prendre son autonomie, voire pour l'assassiner.

Ne pas savoir faire scaler son IT et son organisation

Les méthodes d’innovation font l’apologie du se tromper rapidement (#FailFast). On pense son innovation rapidement et on code sans faire attention (#quick&dirty). Mais quand la traction est au rendez-vous, la solution ne sait pas tenir la charge et la croissance est synonyme de bugs en cascade. La solution faite de bric et de broc devient un amas de complexité qui génère de la dette technique de manière organique. Alors la DSI ne veut pas s’en approcher. Cette solution imaginée hors les murs, dans un “lab” avec des solutions sans un minimum de sécurité est devenue le mouton noir de l’entreprise, fuie de tous et en premier de la  DSI qui effrayée par la perspective d'une catastrophe en production dont elle aurait à assumer les conséquences préfère s’en débarrasser.

Le syndrome du “not invented here”

L’entreprise veut aller vite grâce à la technologie vécue comme un accélérateur. Mais la DSI veut aussi tout inventer soi-même : “on a quand même les meilleurs ingénieurs, on va le fabriquer nous-mêmes ce truc”. Alors, par manque d’humilité, beaucoup de temps est perdu, à tout repenser, et réinventer puis à affiner, puis à recoder, corriger, recoder… La DSI réinvente la roue et investit temps et argent pour développer des fonctionnalités déjà disponibles sur le marché. Et par la même occasion on met tout en place pour être dans les standards du groupe dès le début. On construit une solution solide qui sait encaisser une charge importante et répond à toutes les contraintes de sécurité. On a oublié qu’il fallait avant tout tester rapidement, s’assurer de l’appétence des utilisateurs et du marché et que pour valider ses hypothèses, il faut développer rapidement sans trop dépenser temps et argent (#FailFast). Rentrer dans les standards du groupe ne sera pertinent qu’une fois qu’on aura validé l’appétence des utilisateurs. Dans ce scénario, la DSI piège l'innovation dans l'enlisement de l'industrialisation jusqu'à la pousser au suicide.

La désillusion à court terme et la sous estimation d’une technologie à plus long terme

On entrevoit et parfois on fantasme sur le potentiel disruptif à court terme des technologies émergentes telles que l’IA ou la blockchain par exemple. Il est plus probable qu’elles auront un impact à moyen et long terme. Même si certaines apparaissent un peu déceptives dans les premières phases d’émergence, elles ne pourront pas être désinventées et bien qu’encore en évolution elles sont dores et déjà disponibles et activables. Il ne faut pas rater les premières vagues d’expérimentations même si elles n’aboutissent pas complètement. Elles sont riches d’enseignements et permettent de grandir et de mieux appréhender les vagues d’amélioration successives qui vont s’enchaîner et porter leurs fruits. Il faudra alors être prêt et ne pas se laisser emporter par la vague. Aux premiers essais infructueux ou déceptifs la DSI ne doit pas jeter la technologie et abandonner. Les expérimentations sont des apprentissages, un passage obligé parfois pour grandir et atteindre une certaine maturité des usages ou de la technologie en elle même.

La peur de ne pas être au carré avec le réglementaire ou la sécurité

La DSI comme d’autres services craignent les départements qui gèrent les aspects  réglementaires ou la sécurité (légal, RGPD, compliance, RSSI...). Ces départements dans leur quotidien gèrent des enjeux et des risques indiscutables. Tout le monde les craint car ils ont le pouvoir d’influer un projet qui ne rentrerait dans les clous. La DSI pour ses propres projets passe systématiquement devant ces instances en comité qui peuvent décider ou non de leur pérennité voire de leur passage en production. Les innovations dans leur phase émergente, bien qu'opérant sur des périmètres plus restreints (cible client réduite, CA réduit…) engendrent des risques beaucoup plus faibles mais le plus souvent inconnus (absence de jurisprudence…). Par peur de l’inconnu et de l’échec, la DSI demande, consciemment ou par simple excès de zèle, à appliquer le même process que pour un projet à large échelle. L’équipe innovation est entraînée dans un long tunnel de plan RSSI, d’analyses d’impacts, d’allers-retours de mail et d’attente d’un créneau dans un prochain du Comité d’homologation bimestriel...

Le “réglementaire” tel un tueur à gage mandaté par contrat par la DSI achève alors froidement l’innovation.

Les Usual Suspects (D. Lequepeys)

Alors comment fait-on pour contrer ces difficultés ?

Du MVP jetable à la V1 en passant par le VLab

Une fois les équipes embarquées dans la construction de leur innovation si la traction est au rendez vous, d’un point de vue IT, il s’agit d’être prêt à absorber l’accélération. De notre expérience, les logiciels et les équipes capables de passer à l’échelle anticipent ce moment. Métaphoriquement, contrairement à la morale des petits cochons, il est astucieux de commencer avec une maison de paille, puis de passer au bois avant de peut-être un jour, bâtir une maison en briques et ainsi investir à mesure que l’utilité est confirmée.

Il faut anticiper la déconstruction avant de rebâtir plus solidement pour pouvoir grandir et affronter les demandes plus nombreuses. En effet, le but est d’aller vite au début et bâtir sur des fondations légères juste pour prouver un concept auprès de 10 clients  : le fameux MVP, Minimum Viable Product que l’on considère comme jetable donc développé de manière rapide et peu maintenable. Puis, pour commencer le passage à l’échelle et toucher 100 clients, il faut repartir d’un socle adapté à cette échelle. On va développer une version intermédiaire qui servira de base pour la suite. On commence à adopter une démarche avec un “code propre” et des bonnes pratiques pour être capable d’encaisser la traction et ne pas créer de la dette par la suite. C’est la Version Laboratoire en production restreinte: VLab 1.0.  Enfin, si la traction est là, il faut bâtir sur cette base d’architecture scalable et cette fois être capable de passer 100 à 1000 puis à 10 000 clients. On passe ensuite sur la V1 officielle sur laquelle communiquer à large échelle.

Car du moment où les choses s’accélèrent, l’équipe qui s’agrandit ne sera plus en mesure de gérer de front mise l’échelle de la technique, le changement d’échelle de son équipe et les nouvelles demandes métier. Les pratiques informatiques, les architectures et les fondations gagnent alors en robustesse et le métier peut accélérer sans risque d’effondrement. N’espérez pas enrichir votre innovation ou mieux la faire passer à l’échelle avec un logiciel, une équipe ou un SI construit en “paille” ou en “bois”.

Accélérer avec du buy

S’il existe un acteur technologique en place qui peut accélérer le développement, ne pas le négliger, soit en tissant un partenariat, soit en rachetant (brevet, techno, licence, tout), soit en investissant dedans (prise de participation tel un VC) ou encore en utilisant directement sa solution (Saas, progiciel). En cas de rachat ou d’investissement, diligenter une due dill technique avec votre DSI pour auditer ladite société en soulevant son “capot technologique” par l’intermédiaire d’un audit de son code et des interviews de ses équipes. La rencontre des équipes ouvre un regard sur leur méthodologie de travail et d’organisation: leur capacité à travailler ensemble, à livrer du logiciel démontrable régulièrement, de manière soutenable, à communiquer, à s’améliorer ensemble continuellement, à intégrer des nouveaux...

En ce qui concerne les solutions sur étagères (Saas, progiciel), il convient de mesurer le risque et l’opportunité. Garder en tête qu’il faut aller vite et dérisquer au plus tôt. Il est aujourd’hui souvent facile et rapide de sortir un MVP en quelques jours en combinant différents services Saas et des services d’intégration en ligne (comme Zapier ou IFTTT). Si la solution fait l’affaire et en cas de succès, une phase de rationalisation viendra ensuite : rachat complet de la solution (périmètre possible : code, licence, équipe, ...) avec ou sans refactoring, ou jouer cavalier seul dans une réécriture complète chez soi. C’est le jeu du balancier perpétuel entre l’accélération pour appréhender vite le marché et la rationalisation pour assurer un passage à une autre échelle (cycle successif d’accélération et de consolidation).

Quelle architeture pour quel objectif (D. Lequepeys)

Explorer les technologies émergentes

En matière d’innovation, aujourd’hui nous vivons comme au début du XXe siècle un moment bouillonnant de synthèse créative. C’est à dire qu’après une longue période d’avancées scientifiques puis technologiques, des hommes et des femmes rapprochant les technologies disponibles dans un assemblage ingénieux transforment ces avancées en progrès pour chacun dans une synthèse créative. L’innovation doit d’appuyer sur la DSI pour explorer ces progrès et comprendre techniquement comment ils fonctionnent et comment vous pouvez vous les approprier et monter en compétence sur ces nouvelles technologies.. Même si vous ne les activez pas tout de suite, soyez en familier, pour rester en éveil et être prêt à les mettre en oeuvre à plus grande échelle au moment de leur maturité technique, d’usage et/ou sociétale.

Industrialiser ses développements logiciel

Si ce n’est pas déjà fait, sécuriser et libérer du temps en mettant en place une usine de déploiements automatisés des développements. Pour conserver voire augmenter une vélocité pour les développements futurs et faire en sorte que les coûts liés aux tests de non régression n’augmentent pas avec le temps, mettre et conserver la pratique des tests automatisés (unitaires et fonctionnels). Ils faciliteront par ailleurs la documentation du code et l’intégration de nouveaux membres dans l’équipe. Enfin, ils participeront à la résilience des équipes. Faire des revues de code systématique dans l’équipe (avec ses pairs ou un techlead).

Mettre les conditions pour rendre l’équipe de développement dans un cadre d’amélioration continue en lui permettant d’auto-organiser ses rituels et rétrospectives. Laisser l’équipe proposer, expliquer et gérer ses moments de refactoring du code, de changement de frameworks technologiques voire de réécriture de pans entiers. Ce afin de conserver l’évolutivité du code et la vélocité de l’équipe dans le développement et l’amélioration des fonctionnalités.

Impliquer les grands “anticorps” à intervalle de temps régulier

Changer le paradigme en positionnant dans votre problématique et avec vous les départements de la DSI, du “réglementaire” ou de la sécurité. Leur demander “comment on pourrait faire” et non “qu’est ce qu’on a le droit de faire”. Evaluer les risques avec eux, en rappelant qu’en phase d’expérimentation MVP, le nombre d’utilisateurs donc le risque est potentiellement limité. Trouver d’éventuelles solutions et si besoin faire décider/trancher au plus haut niveau avec ces éclairages.

Ainsi, lors des phases de réflexions amonts ainsi que pendant les phases de construction, pensez à embarquer/solliciter avec la DSI les départements liés au “réglementaire”. Les impliquer ainsi à intervalle de temps régulier dans le processus d’innovation est un bon moyen de sensibiliser chacun (ça marche dans ls 2 sens) et d’éviter le rejet et la “balle entre les 2 yeux” en fin de parcours. Invitez les régulièrement lors de vos comités de décision, de choix d’investissement, de choix technologique ou de due diligence technique avant investissement.

Conclusion

La DSI comme suspect parfait, la piste était trop belle. Mais la DSI a un mobile impeccable. Elle a tout intérêt à ce que l’innovation réussisse. C’est une véritable opportunité pour la DSI de devenir le partenaire des métiers et de l’entreprise pour codévelopper des nouveaux produits. Elle devient partenaire et non fournisseur. Elle devient acteur dans le process et non prestataire interne qui répond à un cahier des charges.

L’innovation est une formidable occasion pour repo****sitionner la DSI comme un atout stratégique de l’entreprise et la sortir de la rationalisation systématique. Il suffit de gérer les susceptibilités, bénéficier des connaissances en impliquant très tôt les responsables futurs (à qui on va remettre le “bébé”) et en expliquant la démarche d’innovation (petits pas, investissements par phase). La DSI ne doit pas être le suspect du meurtre de l’innovation mais le complice de son succès.

En allant un peu plus loin, la DSI peut même faciliter la vie des innovateurs qui ont besoin d’IT. En leur mettant à disposition dans des sandbox, des infrastructures cloud, des repository de développement (ex. GitHub), des plateformes d’intégration et d'analyse de code continue (ex.Jenkins; SonarQube), des plateformes de suivi des incidents (ex. Jira) voire des API d’accès à des jeux de données, elle facilite la vie des innovateurs et apporte une réponse aux phénomènes des shadow IT (SI réalisés et mis en œuvre sans son approbation).

La DSI peut ainsi s’impliquer au plus tôt dans le processus d’innovation. Elle permet aux innovateurs qui ont besoin d’IT ou de données de tester vite leurs innovations et ainsi de favoriser l’émergence rapide d’expérimentations dans l’entreprise.

Aller plus loin

https://blog.octo.com/culture-innov-innover-comme-une-startup-investir-comme-un-vc/