Petit guide du numérique pour grande DSI

Pour s’adapter aux évolutions rapides de notre environnement et aux succès des blockbusters de l’Internet, la transformation numérique des acteurs traditionnels est engagée : dématérialiser son offre, repenser sa relation client autour des réseaux sociaux et du big data, stimuler l’innovation, ou même changer son cœur de métier… chacun cherche sa voie.

Mais les startups et les acteurs traditionnels ne jouent pas à armes égales lorsqu’il s’agit de transformation : l’alignement d’une structure légère centrée sur une proposition de valeur unique est une chose (d’autant qu’il s’agit souvent d’une obligation « vitale » pour ce type de structure), la conduite du changement pour adapter les organisations, processus et systèmes d’information d’une grande structure en est une autre, en particulier lorsque ces transformations doivent se conjuguer avec le sécurisation d'un modèle d'activité qui génère jusqu’à nouvel ordre le chiffre d’affaires de l’entreprise.

Or paradoxalement, les DSI qui ont pourtant contribué aux gains de productivité des entreprises au point de devenir une fonction stratégique dans bien des domaines d’activité, ne semblent pas être à l’avant-garde de ces transformations :

• Le « legacy » est jugé trop lourd / trop cher / trop long, marqué par les grands projets de refonte qui captent une part importante des budgets IT et façonnent des trajectoires pluriannuelles.

• La structuration du SI par métiers ou segments de client multiplie les fonctionnalités similaires et les projets en recouvrement ; une certaine transversalité étant recomposée au-dessus de ces silos par des structures complémentaires (cadrage, urbanisme, gouvernance des données) qui complexifient les processus et dont le ROI reste discutable du fait des limites de leurs champs d’action.

Cette pesanteur structurelle des DSI favorise l’émergence d’entités locales de développement SI au sein des métiers, des structures régionales, et même au sein de certains départements du SI, qui contournent les processus mis en place par la DSI (gouvernance, achats, architecture, sécurité) pour retrouver une meilleure proximité avec les utilisateurs et la réactivité nécessaire pour accompagner l’évolution rapide de leurs métiers.

Malgré les succès des projets SI, la généralisation des méthodes agiles et l’introduction d’une dose de liberté d’action au sein des projets, une certaine résignation s’installe auprès des acteurs de ces grandes structures, en particulier du fait de l’écart important entre l’esprit d’innovation martelé sur les réseaux sociaux ou via les programmes d’évangélisation interne des entreprises, et la réalité de leurs activités au quotidien.

Face à ces constats, voici trois propositions pour « réenchanter » votre DSI :

• Adopter le business modèle des plateformes pour mobiliser les acteurs du SI autour d’un projet fédérateur qui porte pourtant un objectif affiché de réduction de coûts.
• Repenser le couple Interne/Externe pour capter les potentiels d’innovation qui se situent à l’extérieur.
• Démocratiser l’émergence des projets pour démultiplier les capacités d’action.

Adopter le business modèle des plateformes

À l’échelle d’une DSI, la partie visible d’une plateforme de service IT prend la forme d’un « itStore » dans lequel chaque chef de projet peut commander, piloter, ou restituer les ressources sont nécessaires à ses environnements applicatifs, depuis le développement jusqu’à la production.

Cette plateforme répond à un ensemble d’exigences fondamentales :

• La commande, mise à jour, ou restitution de « produits IT » constitutifs des environnements applicatifs est automatique, la livraison est réalisée sans délai (quelques heures), et la validation par les managers de l’engagement des nouvelles ressources est réalisée ex post, sur un modèle responsabilisant chaque acteur.
• La plateforme s’appuie sur les référentiels de l’entreprise (centre de coûts pour la structuration des portefeuilles de projets, annuaires pour les utilisateurs et leurs profils), et permet en contrepartie leur mise à jour automatique (ex. : cartographie des applications, des services, des flux, des données…).
• Le suivi du fonctionnement des applications et le reporting sur l’utilisation des ressources sont accessibles à tous les protagonistes, y compris en situation de mobilité : disponibilité et performance des applications, supervision technique et fonctionnelle des produits, consommation des ressources…
• Les interfaces répondent aux standards actuels de design et d’ergonomie des applications (ex. : aucune information non nécessaire ou qui ne peut être déduite n’est demandée à l’utilisateur).

À ce stade, les gains associés à une telle plateforme sont en premier lieu financiers :

• La réactivité des équipes de développement est décuplée.
• Les délais de mise à disposition de ressources et la possibilité de les restituer influencent les comportements des utilisateurs pour limiter les ressources dormantes (le « trésor de guerre » des projets pour lutter contre les lourdeurs des procédures d’approvisionnement).
• L’introduction d’une unité d’œuvre : « itCoins », qui valorise l’empreinte des produits commandés sur l’IT, permet de clarifier les responsabilités. Les utilisateurs optimisent leurs consommations de ressources via une «facturation au réel », les commanditaires sont autonomes dans les arbitrages, et le service IT actionne les leviers permettant d’agir sur le coût unitaire de l’itCoins : coûts des équipements et des licences, virtualisation, optimisation des taux d’occupation, externalisation de certains services IT via les clouds externes...

L’impact sur les équipes d’infrastructure IT est majeur, car le barycentre des compétences bascule progressivement des tâches opérationnelles vers :

• L’expertise sur les concepts et solutions « modernes » d’infrastructures (Software Defined Networks, Multi-tenancy, Hierarchical Storage Management) qui d’une part permettent de supporter ces niveaux de service et d’automatisation, et d’autre part sont en eux-mêmes des sources de gains supplémentaires : système de déduplication de données pour réduire l’empreinte du stockage, chiffrement des couches physiques pour supprimer les solutions applicatives d’anonymisation, mobilité à chaud des applications pour repenser les plans de reprise d’activité, sécurité distribuée pour provisionner automatiquement les règles de filtrage et de contrôle au plus près des applications…
• Les tâches de développement des couches basses de la plateforme, des connecteurs vers les référentiels de l’entreprise, et l’intégration avec les solutions d’hébergement externes.
• Le recours aux datasciences pour optimiser les produits IT (ex. : A/B testing), réaliser la maintenance prédictive des équipements, ou optimiser dynamiquement les choix d’implantation des produits fonction de différents critères (coût, sécurité, confidentialité).

Standardiser les produits… dans votre écosystème spécifique

Une telle plateforme pourrait se limiter à un « Cloud hybride » (en mieux tout de même si vous relisez bien le paragraphe précédent) si les produits proposés se limitaient à des composants de bas niveau de type IAAS/PASS. Mais l’objectif d’automatisation n’est qu’une étape vers un objectif plus grand en termes de gains pour une DSI de grande taille : la standardisation dans l'écosystème spécifique de l'entreprise.

Imaginons un produit de type « Environnement de développement Java » qui mettrait à disposition d’un chef de projet en un clic :

• Des serveurs préconfigurés pour la base de données, le serveur d’application, le gestionnaire de configuration, l’intégration continue et les tests, et des machines virtuelles pour les développeurs (afin de profiter de l'élasticité de l'infrastructure de la plateforme et éviter les lourdeurs de gestion d’une flotte de PC renforcés pour les développeurs).
• Le paramétrage et l’intégration de ces différents composants autour d’une application « vierge » prête à l’emploi qui contiendrait déjà toutes les fonctions de support nécessaires à chaque application : modèles de pages à la charte graphique de l’entreprise, mécanismes d’authentification des utilisateurs connectés à l’annuaire d’entreprise, système de logs et de supervision intégrés à la plateforme…

Sur ce modèle, on peut imaginer un catalogue de produits IT à même de répondre à la plupart des cas d’usage métiers de l’entreprise (site Web, analyse de données, décisionnel, écosystèmes ELK, apps pour tablettes et smartphones…), la clé étant de définir le corpus d’exigences permettant d’intégrer ces produits dans la plateforme.

La standardisation permet d’atteindre un palier de gains beaucoup plus important :

• Les étapes de conception, réalisation, intégration, validation et de qualification (fonctionnement, architecture, sécurité, connectivité) des sous-jacents qui composent la plupart de vos applications seront exécutées une seule fois sur la souche du produit, et non plus à chaque nouveau projet. Au-delà du gain financier, le « time to market » s’en trouve radicalement amélioré : quelques heures entre l’idée et les premières lignes de code.
• Les équipes transverses (architecture, sécurité, solutions, urbanisme) ne sont plus là pour rédiger des documents de préconisation ou auditer les projets – mobilisant par la même leurs ressources clés –, elles trouvent un levier plus fort en contribuant directement au développement des produits afin qu’ils soient conformes à leurs exigences, ou en développant les systèmes de contrôle directement sur la plateforme.
• L’affiliation des nouveaux projets aux produits proposés, et in fine aux standards préconisés par les équipes transverses, devient naturelle puisque chaque chef de projet a le choix entre une solution ad hoc, qu’il mettra comme aujourd’hui plusieurs mois à mettre en place, ou une solution standard disponible immédiatement.
• Les fonctions SI transverses (bus de services, portail, BPM, transfert de données…) sont intégrées dans la plateforme et complètent les produits proposés sous forme de service optionnels, tout comme les accès aux référentiels de l’entreprise : catalogues de produits, nomenclatures, clients, adresses et représentations cartographiques…

Mobiliser la « multitude »… de vos développeurs

Les projets de mise en œuvre d’offres de services IT transverses ne sont pas simples à conduire dans les grandes structures :

• Le sponsoring nécessaire est difficile à obtenir du fait de la diversité des protagonistes et d’une difficulté structurelle à estimer un ROI a priori. Les capacités/budgets limités des équipes transverses provoquent également des arbitrages qui irritent les commanditaires.
• Les gains liés à la mutualisation sont contrés par les limites de l’offre de service à chaque palier de sa trajectoire de mise en œuvre ce qui induit des situations transitoires qui se résorbent rarement.
• Une défiance s’installe entre les utilisateurs de ces services transverses, dépositaires – selon eux – des « vrais besoins », et les équipes transverses, qui portent – selon elles – une « vraie vision » de la cible.

Fort heureusement, les avancées du développement communautaire apportent des solutions à ces difficultés, car le modèle de l’open source se décline aussi en interne : plutôt que de lancer un grand projet transverse avec des ressources dédiées, laissez le soin à chaque projet SI disposant des compétences nécessaires de développer lui-même les fonctions dont il a besoin.

Votre projet transverse dédié à la plateforme de service IT se réduira ainsi à une « core-team » en charge de mettre en place l’infrastructure de base, les outils ouverts de gestion de projet, l’animation des communautés, les quelques produits d’appels, la documentation des API et exigences pour l’intégration des produits, et la cohérence de l’ensemble.

À titre d’exemple, pour démarrer la mise en place de votre plateforme de service IT, utilisez un de vos projets SI les plus en avancés sur les développements trois tiers pour créer la souche d’un produit qui vous permettra de construire à moindres frais l’itStore de votre plateforme (logique de bootstrap).

Ce nouvel écosystème de développement de la plateforme, que nous pourrons appeler « itLab », peut amener un troisième niveau de gains substantiels. En fédérant des développeurs au travers de cette plateforme, une dynamique de mutualisation se crée autour d'éléments de spécification de code sous un mode communautaire. Le « marché de la popularité » (volume des contributions, recommandations) et la gamification (hackathons, concours, niveaux de certification pour des accès de plus en plus étendus aux couches basses de la plateforme…) se chargeront de stimuler les contributeurs.

L’enjeu d’un tel écosystème est énorme étant donné le nombre de prestataires qui contribuent au développement du SI dans les grandes structures (souvent plusieurs centaines) : réutilisation des développements, capitalisation sur les connaissances, micro-urbanisme applicatif…

Repenser le couple interne/externe

Quels que soient la taille ou les qualités intrinsèques d’une entité (entreprise ou DSI dans le cadre de cet article), le constat est que les potentiels d’innovation seront toujours plus nombreux et diversifiés à l’extérieur qu’à l’intérieur, ne serait-ce que parce que les clients se situent à l’extérieur.

Pour stimuler l’innovation, cette captation des potentiels externes devient nécessaire, mais elle se heurte rapidement aux propriétés des frontières de l’entité, qui ne présentent pas les caractéristiques appropriées pour favoriser des interactions exogènes positives (tout en garantissant un niveau d’étanchéité adapté à chaque situation).

En effet, au sein des DSI de grande taille, l’économie des échanges avec l’externe s’articule très majoritairement autour d’actes d’acquisition de ressources : embauche d’un salarié, mise en place de contrats-cadres pour les achats de prestations externes, partenariat avec un éditeur de logiciels, obtention d’un budget métier contre un cahier des charges pour le lancement d’un nouveau projet…

Même si la lourdeur des procédures est, au mieux, proportionnelle aux niveaux des engagements contractés, ce cadre procédural, rendu souvent kafkaïen par le silotage des grandes organisations et les entités transverses, s’avère inadapté lorsqu’il s’agit de traiter les cas d’usage qui caractérisent les activités plus éphémères qui entrent dans le champ de l’innovation.

À titre d’exemple, imaginez l’énergie qu’il vous faudrait déployer pour :

• Collaborer avec une autre société dans ses leurs locaux en utilisant les ressources de votre entreprise (données, outils de gestion partagée de projet…).
• Travailler avec un expert reconnu dans un domaine mais qui souhaite se réserver le droit de publier à son compte une partie de ses réalisations, ou publier dans l’open source certaines parties de code pour bénéficier en échange des améliorations apportées par la communauté.
• Déployer une application mobile interagissant avec le legacy sur des terminaux privés pour une population non limitée aux salariés de l’entreprise, ou utiliser un service en mode SAAS depuis le legacy de l’entreprise (et inversement).

Suivant le niveau de maturité actuel de votre DSI, ces quelques exemples peuvent vous paraître triviaux, longs et coûteux à mettre en place, ou tout simplement inaccessibles du fait du faisceau de contraintes à affronter pour les mettre en œuvre.

Si l’on prend pour acquis l’existence dans votre SI d’une plateforme de service IT telle que celle décrite au paragraphe précédent, de nouveaux cas d’usage à valeur ajoutée peuvent être considérés :

• Louer à un tiers (ou à une autre entité du même groupe) l’accès et certains produits IT proposés dans votre plateforme de services IT.
• Accepter de mettre au catalogue de la plateforme des produits IT qui seront développés « gracieusement » par des tiers (éditeurs, intégrateurs), espérant ainsi attirer de nouveaux talents ou négocier des contrats de licence plus avantageux.

Dans tous les cas, l’évaluation de votre niveau d’agilité et le pilotage d’une transformation pour appréhender ces nouveaux modes de relations avec l’externe est une nécessité, qui peut s’aborder en recensant l’existant et les potentiels de développement suivant deux axes :

• D’une part les actifs matériels (composants d’infrastructure, équipements industriels, objets connectés…) ou plus immatériels (partie de code, Webservices/microservices, compétences clés, technologies, facteurs de notoriété, partenariats, brevets…) qui pourraient faire l’objet de ces échanges.
• D’autre part les modes de transactions (autre que l’acquisition) qui pourraient être développés : revente, location, licences, prêt/échange/troc, publication, alliances opportunistes, partenariats stratégiques, spin-off…

Pour chaque couple actif/mode de transaction pourront être évalués :

• Votre performance actuelle : nombre de collaborations sous ce régime d’interaction, coûts et délais de mise en place d’une nouvelle collaboration.
• Les contraintes spécifiques qui s’appliquent à votre écosystème : effort de mise en œuvre, sécurité, risque juridique, propriété intellectuelle, règlementation.
• L’alignement stratégique de chaque type d’interaction, les objectifs à atteindre et les moyens à mettre en œuvre pour intégrer ces nouveaux modes d’échange dans des processus standards de l’entreprise.

Cette analyse vous amènera certainement à ne plus considérer une seule frontière interne/externe pour l’ensemble des actifs, mais plusieurs frontières concentriques en fonction des actifs considérés afin d’améliorer la fluidité dans l’échange d’actifs de plus en plus banalisés.

Démocratiser l’émergence de projet

Comme indiqué supra, les DSI de grande taille sont historiquement marquées par les grands projets de transformation du SI : abandon des mainframes, déploiement d’ERP, intégration de systèmes d’information au grés des concentrations des entreprises, rationalisation des fonctions dans le cadre de plans d’urbanisme, centralisation des référentiels, développement d’offre de service, de catalogues de solutions, d’infrastructures spécifiques pour la gestion de la sécurité…

Les enjeux associés à de telles transformations du SI ont façonné les procédures de cadrage et d’émergence des projets qui mobilisent de nombreux acteurs (experts métiers, urbanistes SI, architectes techniques, responsables sécurité, contrôleurs de gestion, acheteurs), et impliquent la rédaction d’un volume conséquent de documents (dossier d’opportunité, de rentabilité, d’émergence, d’architecture, cahier des charges) discutés dans les comités d’engagement et de validation.

Pourquoi la notion d’agilité qui se déploie actuellement dans l’ingénierie des projets informatique, ne pourrait-elle pas se décliner dans la gouvernance des projets ? À l’heure du digital et de l’innovation continue, un des enjeux majeurs des DSI est de disposer de cycles de lancements et d’arrêts de projets IT beaucoup plus rapides pour tous types de projets, et particulièrement pour des projets de petite taille.

Si nous prenons pour acquis les deux premiers paragraphes de cet article (il n’est pas interdit de se projeter), vous disposez désormais au sein de votre DSI d’une plateforme performante de « Fast IT » pour lancer rapidement de nouveaux projets, tester à moindre coût de nouvelles idées sur la base de responsabilités clairement établies (via le principe des itCoins), avec des équipes focalisées sur la production effective de résultats immédiats et des capacités d’interactions avec un ensemble élargi de parties prenantes.

Pour ce qui concerne les moyens IT engagés sur la plateforme de service mutualisés, les processus d’émergence des projets ne sont tout simplement plus nécessaires, seule importe le pilotage des portefeuilles de projets et les « lignes éditoriales » données à ces ensembles de projets.

Pour aller plus loin, constatons que la tendance actuelle pour stimuler l’innovation dans les entreprises est de formaliser et structurer les processus et outils d’inspiration, d’idéation et d’expérimentation. Des entités spécialisées sont créées (Direction de l’Innovation, Labs), pour regrouper ces « nouveaux experts » de l’innovation (Design Thinking, Techno-push, Cocréation, Coachings en tous genres) et mobiliser les forces créatives de l’entreprise, notamment au travers d’événements potentiellement productifs ou a minima communicants : hackathons, séminaires, collectes et « kick starters » d’idées en ruptures, cellules de veille dédiée à la détection de signaux faibles...

Ces approches descendantes de l’innovation (impulsées par le management) sont structurellement limitées par le nombre et la qualité des participants - en particulier la représentation du terrain -, par la fréquence d’occurrence, ou par la cohérence d’ensemble lorsqu’il n’y a pas de lignes directrices fortes.

Un modèle de plateforme type itLab, couplée au réseau social de l’entreprise, est peut-être une voie à explorer pour fédérer autour de communautés horizontales  d’« inov’acteurs », des initiatives rapprochant le national et les territoires, les experts métiers et les opérationnels, les développeurs et les architectes…
Est-ce qu’Apple a besoin d’organiser des Hackathons pour stimuler la mise à ligne de nouvelles applications sur son store ?

Le modèle de gouvernance d’une telle DSI 2.0 ne serait plus basé sur le reporting, l’arbitrage, la priorisation et les plans à moyen terme, mais sur de nouvelles métriques plus digitales (taille des communautés, notoriété des acteurs, succès des idées auprès de premiers utilisateurs), pour rythmer le lancement et l’arrêt d’un nombre beaucoup plus important de projets de plus petite taille, que ce soit dans l’amélioration de l’existant ou sur des idées plus en rupture.

Pour une description plus générale du business modèle des plateformes sur Internet, qui inspire cette déclinaison plus opérationnelle à l'échelle d'une DSI, vous pouvez lire mon précédent post  « Hello world ! ».