« Pour avoir un plan B face aux éditeurs dominants, EDF Commerce doit garder un savoir-faire technique »

 

François Raynaud est le directeur des systèmes d’information d’EDF Commerce. Dans le cadre de sa contribution au Do Tank 2025 d’Alliancy « Maîtrise des dépendances technologiques », il revient sur la façon dont se pose ce défi pour sa DSI et les leviers qu’il active.

 

Vu de votre périmètre de responsabilité, quels sont les risques des dépendances technologiques auxquelles une entreprise peut se retrouver confrontées ?

 

Le premier risque est déjà celui de la confusion autour des expressions de souveraineté, confiance ou dépendances. Dans les activités « Clients, Services et Territoires » d’EDF, qui n’incluent donc pas les activités de producteur d’énergie (ex. le nucléaire ou l’hydraulique), les réglementations auxquelles nous sommes soumis imposent des mesures de niveau « confiance » mais pas « souveraineté ». Ainsi, lorsqu’elles seront certifiées SecNumCloud #3.2, nous pourrons utiliser des offres cloud comme « S3NS » ou « Bleu ».
La question de la dépendance technologique est avant tout celle de l’équilibre entre risque économique versus avantage technique ou fonctionnel. L’exemple du rachat de VMware par Broadcom l’a parfaitement illustré, hélas, mais ce n’est ni le premier, ni le dernier cas. Des grandes organisations comme les nôtres ont des systèmes d’information anciens et hybrides qui multiplient les facteurs de dépendance. Ceux-ci provoquent une perte de maîtrise et de rapidité de transformation pour le SI, ce qui peut se transformer en perte d’opportunités ou de performances pour nos métiers. Pour limiter le risque, nos trois enjeux au niveau du SI d’EDF Commerce sont la résilience, la réactivité et la compétitivité… Toutes nos décisions sont prises à l’aune de ces trois points. D’un point de vue technologique, elles impliquent une agilité et une forte capacité d’adaptation pour pouvoir faire des choix rapides et prendre le bon chemin aux embranchements technologiques.

 

À quel point êtes-vous confrontés à des pratiques problématiques de la part d’éditeurs ?

 

Le modèle économique et financier des éditeurs fait qu’ils ont toujours besoin d’augmenter leur chiffre d’affaires (du moins, c’est ce qu’ils disent). Donc de plus en plus de tensions commerciales apparaissent. De tous temps, nous avons eu des éditeurs qui ont essayé de nous tordre le bras, jusqu’à ce que l’on se décide à sortir de leurs produits (ce qui représente toujours un budget significatif et du temps « non productif »). Ce qui est vrai pour les logiciels se reproduit avec les infrastructures ou le Cloud ou le Saas. Le marché se concentre sur un nombre limité d’acteurs et donc la question de la réversibilité des choix se pose là aussi.

 

Quel est l’état du dialogue avec le Comex et les métiers sur un tel sujet ?

 

Cette question de la dépendance est un des volets de la Politique Industrielle de l’Entreprise. De fait, elle dépasse donc le seul cadre IT. Une prise de décision peut donc remonter selon ses enjeux et risques à des niveaux élevés de l’entreprise, voire au Comex. Pour ce type de décision, une des difficultés à traiter est celle de l’objectivation des gains, des risques associés et surtout de la réversibilité potentielle. C’est d’autant plus difficile lorsqu’il y a beaucoup d’informations plus ou moins erronées ou incomplètes qui circulent sur ces sujets dans le grand public, les réseaux sociaux, voire parmi les politiques. A l’inverse, ne pas faire remonter le débat et la décision en laissant des experts techniques de la DSI mettre en production des solutions « dépendantes » peut conduire à un « patchwork » de solutions dans l’entreprise avec des écueils de performance économique voire de vulnérabilités. Dans ce contexte, je pense que le défi est de faire prendre conscience des risques aux équipes DSI et Métiers afin qu’elles incluent une piste de réversibilité dans chaque choix « stratégique ». Par exemple, en Cloud, les services managés font gagner en réactivité, résilience et coûts mais ils rendent dépendants. Donc, avant de choisir de les utiliser massivement, il faut évaluer le coût et le temps nécessaire à une éventuelle réversibilité. Bref, être factuel, sans dogmatisme. Soyons réalistes : on n’est jamais totalement prisonnier ni totalement indépendant dans un écosystème technologique.

 

Quel plan mettez-vous en place pour lutter contre les dépendances ?

 

La dépendance, cela se traite comme l’obsolescence : elle peut être acceptable sur certains sujets et beaucoup plus grave sur d’autres. Mais il faut en avoir conscience et surtout s’assurer d’avoir les compétences pour y remédier en fonction de l’analyse de risques associée. On ne va pas s’interdire d’utiliser des services managés d’un « clouder », mais il faut savoir clairement quel est le plan B. Factuellement : comment éviter une nouvelle affaire « VMware-Broadcom » ?

 

Comment planifiez-vous un tel plan B ?

 

Pour être capable d’avoir un plan B qui soit vu comme crédible vis-à-vis d’un éditeur dominant, une DSI doit garder un savoir-faire technique mais aussi une capacité à acheter finement. Pensez-vous qu’un vendeur s’inquiètera s’il entend des menaces de sortie rapide de sa solution de la part d’une organisation qui n’a pas de compétences techniques ou de pilotage adéquat ? Autrement dit, il faut être aussi bon en « make » qu’en « buy » pour se laisser toutes les portes ouvertes. Le premier élément, c’est donc d’entretenir sa compétence « au top » en termes d’expertises, de certification, de réseau d’utilisateurs… Ce n’est pas seulement faire de l’Excel et du PowerPoint ! Il faut pratiquer, regarder et tester les nouvelles technologies, et agir sur la dette technique et contractuelle en permanence.

 

Quels sont les choix en termes de gouvernance que vous avez faits qui vous sont le plus utiles aujourd’hui ?

 

Nous mesurons un indice d’obsolescence, partagé tous les mois en comité de direction, avec beaucoup de granularité et de profondeur. À partir de là, nous savons dire où sont les impacts et qu’est-ce que nous devons changer pour nous prémunir d’obsolescences et cela nous donne aussi le nombre d’instanciations des différents produits que nous utilisons, et donc potentiellement le risque associé. Pour être réactif, il faut avoir cette carte de santé du système d’information et ne pas avoir une vision monolithique. Ensuite, nous avons la chance d’avoir fait il y a plus de 15 ans des choix forts sur la séparation de la technique et du contractuel, avec une équipe d’approvisionneurs/contracts managers indépendante des équipes Build/Run SI. Cette équipe dédiée qui travaillent en lien avec les Achats Groupe, nous permet d’avoir des contrats performants, adaptés et de défendre leur « bonne » exécution face aux fournisseurs sans que les éventuels conflits avec nos fournisseurs ne soient portés par les acteurs techniques dont ce n’est pas le métier.

 

Quels sont les plans de sortie récents que vous avez dû mener ?

 

Le premier est le cas Hadoop. Nous étions chez Hortonworks avant le rachat (par Cloudera, NDLR). Quand nous avons compris les conséquences sur nos développements que cela allait entraîner, nous avons décidé d’abandonner la solution. Cela nous a pris deux ans, pendant lesquels, nous avons aussi pu voir que tous les aspects de cette brique technologique n’étaient pas utiles pour nous : l’essentiel de nos besoins a pu être couvert par des technologies relationnelles et les quelques autres par des bases de données graphe par exemple. Le projet de sortie a coûté cher mais a été salutaire car il nous a permis de rationnaliser une partie de nos SI et d’en décommissionner. Ce qui a fait que ce projet s’est bien passé, c’est que nous avons réinvesti dans les compétences, à la fois sur Hadoop et sur les technologies qui allaient y succéder. Et nous avons mis en place un pilotage très fin, très régulier, avec des arbitrages permanents et des acteurs internes super-motivés !

L’autre cas significatif de ces dernières années, c’est quand nous avons subi un chantage sur la solution utilisée pour l’accès des utilisateurs à notre portail client, avec un coût multiplié par plus de trois si l’on ne changeait rien. Nous avons alors fait le choix de réaliser un « fork » de la version open source de la solution qui a ensuite été privatisée par l’éditeur en question. Aujourd’hui, notre solution est maintenue en interne avec 4 ETP et permet de gérer les accès de plus de 10 millions d’utilisateurs ! Cela a fonctionné car nous avions bien bordé le sujet en amont avec des juristes, d’une part, et nous savions que nous avions les compétences pour le faire d’autre part. Il a fallu que l’on mette les mains dans le moteur, mais ce projet a aussi profité à d’autres puisqu’il a été un des projets fondateurs de TOSIT (association créée pour soutenir et mutualiser des projets open-source, NDLR), et à une utilisation par d’autres grands acteurs français…

 

Quels sont les points à avoir en tête pour réussir à bien s’emparer d’alternatives aux acteurs dominants ?

 

Déjà, il faut affirmer qu’il est bien sûr jouable d’aller chercher des plus petits acteurs que les leaders dominants ! La loi impose de ne pas créer de dépendance « vitale ». C’est tout à fait possible moyennant une ambition raisonnable et un bon appui contractuel. Autre possibilité que nous utilisons pour les sujets critiques : établir un « dual sourcing ». Sur la dématérialisation des factures sortantes par exemple, nous prévoyons deux plates-formes avec du load balancing entre les deux. C’est efficace en termes de résilience, et en plus cela donne un levier de gestion fort (y compris commercial). Gérer deux solutions interchangeables évite aussi de tomber dans le piège du trop spécifique avec un fournisseur…
Là encore, la réussite passe par le défi des compétences techniques. Pour autant, cette attention aux compétences ne veut pas dire tout internaliser. Nous couvrons notre activité avec environ 22 % d’internes et des prestations externes pour le reste. Cela est faible mais ces internes se concentrent sur les compétences clés, que nous gérons de près avec une vision sur 12 mois glissants autant que possible pour gérer les remplacements. Parmi ces compétences clés, se trouvent des architectes, des experts cyber, mais aussi des experts certifiés par technologie, des fonctionnels, des ingénieurs de production (exploitation), des product owners, etc. Dans un fonctionnement en mode agile, cela signifie que l’on produit, tant que faire se peut, des « core products » et des « patterns » utilisables par les autres équipes, avec un effet levier et un impact sur la maîtrise du reste du SI.

 

Quels sont les nouveaux défis que vous anticipez pour les prochains mois ?

 

Nous regardons ce que va amener l’IA agentique comme disruptions. Je pense sincèrement que de nombreux éditeurs seront déstabilisés ce nouveau paradigme. D’ici quelques temps, les entreprises vont pouvoir reprendre la main sur certains de leurs logiciels en les remplaçant avec l’IA agentique. En ajoutant la conteneurisation, cela fera des solutions quasi portables sur différents clouds. L’agentique peut devenir un levier d’indépendance pour faire face aux comportements abusifs de certains acteurs de l’IT. Il faudra juste éviter de se retrouver dépendants de ceux qui créent les moteurs d’agentique ! Et là encore, une clé sera les compétences. Avec les bons experts, on trouvera les solutions.