2018 : le DSI doit arbitrer la nouvelle organisation de ses équipes

Désormais, les DSI sont face à un seul choix. Soit ils fabriquent (ce sont des « crafter ») soit ils utilisent (ce sont des « buyers »). Préserver les deux modèles n’est pas souhaitable, car au-delà de la technique, c’est toute la culture de la DSI qu’il faut réinventer et parfois aussi ré-enchanter. Dès lors, pour le DSI, il est urgent de se décider afin de modifier la stratégie, l’organisation et le schéma directeur de sa DSI pour survivre aux transformations en cours.

2018, année charnière

Le statu quo n’est plus possible. En 2018, pour les DSI qui ne l’ont pas encore fait, ils vont devoir faire des choix d’avenirs structurants, car les forces en présence sont trop puissantes.

Il y a d’abord la fulgurante transformation du monde des opérations informatiques et des services IT délivrés par les opérateurs Cloud. L’étendue des services proposés, la facilité d’utilisation et la puissance de calcul et de stockage assurées par les trois grands prestataires de Cloud que sont Amazon AWS, Microsoft Azure et Google GCP finissent par séduire même les plus difficiles. A cela s’ajoute un élément clef, l’ouverture en 2018 de centres de données en France par Microsoft et Amazon, rendant ainsi possible le stockage des données sur notre sol.

Concomitamment à cette offre illimitée de calcul et de stockage, on trouve la révolution de la création, de l’intégration et du déploiement du logiciel. Des logiciels qui étaient anciennement décomposés en services (à l’ère du SOA) sont aujourd’hui construits de manière autonome sous la forme de micro-services communicants, dont le cycle de vie est lui-même géré par logiciel.

Les micro-services sont déployés dans des conteneurs, c’est l’approche Docker avec l’orchestration Kubernetes. Ou il s’agit de plateformes intégrées qui facilitent à l’extrême le déploiement du logiciel. C’est l’offre récente de Redhat nommée RHOAR ou Red Hat OpenShift Application Runtimes.

L’intelligence artificielle prête à l’emploi

La capacité de gestion et de mouvement (le streaming) des données (massives) et de consommation de la puissance de calcul à la demande ouvre alors de nouvelles opportunités d’agilité au sein du système d’information.

Il s’agit alors aussi bien de mise en œuvre de solutions jetables pour un besoin donné ou de « mini-systèmes d’information » alimentés en données et spécialisés pour des besoins spécifiques ou tout simplement de lancer de nouveaux services innovants ou « intelligents ».

Plus récemment, les services d’intelligence artificielle sont apparus, à intégrer dans ses propres logiciels, ou déjà intégrés par les acteurs du Cloud ou par des logiciels dans leur offre de services. On citera « Elastic Container Service for Kubernetes » d’Amazon qui permet d’exécuter Kubernetes (solution de déploiement d’applications en containers) sur Amazon AWS sans devoir installer, faire fonctionner et maintenir ses clusters Kubernetes ! Si ces services en sont encore à leurs prémices, force est de constater que ce qui freine leur utilisation n’est pas leur maturité mais avant tout le manque de données, de compétences ou tout simplement d’envie.

Il y enfin, le problème le plus important, le manque de ressources, en interne à l’entreprise ou via une société de services. Ces ressources doivent être formées à ces nouvelles architectures de micro-services, aux technologies Cloud et bien entendu à leur sécurisation. Aujourd’hui, plus que jamais attirer et garder les meilleurs architectes et « codeurs » au-delà d’un simple projet ou d’une simple mission, devient un travail à plein temps.

Faire appel à des travailleurs indépendants

L’essor du travail indépendant entraine de faire appel à des ressources diverses, via des canaux de recrutement multiples pour construire des équipes pérennes. Se pose aussi le problème de la formation continue, adaptée à des populations où les technologies et plateformes évoluent tous les jours.

Pour répondre à ces transformations, la DSI va devoir se transformer très rapidement, et adopter un des deux modèles opérationnels suivants : une DSI qui construit et un DSI qui utilise.

Dans le premier cas, des centres de production de logiciels (ou Digital Factory) pourront être mis en place et rassembleront dans un même espace des équipes intégrées (souvent agiles) en prise directe avec le métier pour répondre à des besoins fonctionnels clairement délimités, indépendants les uns des autres, et pouvant être associés pour créer des applications (par association de microservices).

Ces services seront aussi déployés de manière automatisés via des forges logicielles pilotées par des ingénieurs qui coderont l’infrastructure et la gèreront en configuration comme le code métier (nommés les devops). Il est à noter, que ces DSI feront souvent le choix du déploiement hybride, car ils seront capables de projeter leur code sur des centres de données internes ou sur du Cloud.

Des ressources en interne quand on fabrique

Enfin, pour terminer, un DSI qui fabrique est un DSI qui dispose en interne des ressources de création, c’est-à-dire de codeurs, en opposition à un DSI qui gère en interne des chefs de projets qui gèrent des prestataires externes.

Dans le second cas, le DSI devra s’organiser pour fonctionner sans équipe de développeurs internes, et devra adopter une approche de sélection et de valorisation des services à mettre en œuvre (on parle de Software as a service).

L’effort devra alors se porter sur l’embauche d’architectes, de responsable des opérations et de responsables fonctionnels capables de créer un système d’information avec des briques techniques, fonctionnelles et métiers externes.

Bien entendu, il existera toujours du spécifique. Le recours à des sociétés « hyper » spécialisées sera nécessaire pour tirer parti au mieux d’un CRM ou d’un outil de gestion RH. Il est à noter, que cette approche n’est pas souvent optimale, le métier choisissant souvent des logiciels en fonction de critères purement fonctionnels, sans regarder les capacités d’intégration ou d’extension du produit.

Logiciels en mode Saas bien limités

C’est comme cela qu’on se retrouve encore en France en 2017 à devoir intégrer des logiciels vendus en mode SaaS, qui sont en fait des instances propres à chaque client et dont les interfaces ne se font que par échanges de fichiers, une ou deux fois par jour. Enfin, cette approche est par essence une vision moyen terme où il faut intégrer dès la conception la dépendance induite aux fournisseurs et imaginer les solutions techniques et contractuelles pour les mitiger.

Rien de nouveau sous le soleil, direz-vous ! Et pourtant, jamais la gestion d’un système d’information et la création de sa stratégie d’évolution n’ont été aussi complexes. D’un côté, des startups issues de nulle part sortent des services dont vos métiers rêvent à un prix défiant toute concurrence, de l’autre, la presse ne cesse de mettre en avant ces sociétés qui innovent en permanence et conquièrent le monde avec leurs plateformes. Et le DSI, que fait-il ? Il doit réagir, faire le choix de son modèle (créer ou utiliser) et accepter les implications sur l’organisation de la DSI, le schéma directeur et les budgets.

La DSI qui « fabrique » va consommer du Capex et va devoir aussi travailler en symbiose avec les métiers (en rompant la ligne Maginot entre MOA et MOE). Si l’adoption du mode agile est bien acceptée du côté de la DSI, il l’est plus difficilement au niveau des métiers, qui se considèrent encore souvent comme des « donneurs d’ordre ».

La DRH acteur indispensable

Le schéma directeur doit donc être adapté pour prendre en compte un système d’information qui se co-construit de manière incrémentale et itérative, sur des technologies qui évoluent vite et dans un contexte où la sécurité est primordiale. Il faudra enfin travailler beaucoup avec la DRH afin de valoriser la marque employeur, et lancer des plans de recrutements permanents sur des profils clefs, condition sine qua none de réussite.

La DSI qui « utilise » pour sa part va consommer de l’Opex de manière quasi linéaire avec le nombre d’utilisateurs. Elle va devoir mettre en place des règles d’architecture et de sécurité strictes, pour éviter de se retrouver prisonnière d’un prestataire. Le système d’information sera construit comme un assemblage de briques Lego indépendantes.

Le centre de données sera réduit à son minimum, et de préférence installé dans le Cloud (ou dans des centres de données spécifiques pour les métiers régulés, ayant le label HDS pour la santé en France par exemple).

Les achats seront très impliqués dans la stratégie, car les contrats signés vont conditionner les niveaux de service du système d’information. La partie la plus complexe étant de s’assurer le contrôle du cycle de vie et la portabilité du code métier et de la donnée. C’est pourquoi l’étude approfondie des APIs et des plateformes proposées pour les extensions métiers est très importante. Par exemple Salesforce propose une plateforme de développement autour des solutions métiers.

Bien entendu, une phase de transition peut-être nécessaire, c’est pourquoi le schéma directeur doit être revu et les budgets adaptés.