Interview de Yann-Éric Devars (Solve DSI)

L'architecture d'entreprise au service de la souveraineté et de la transformation continue

Sylvain Melchior : Bonjour Yann-Éric, merci beaucoup pour ton temps. Pour commencer, peux-tu te présenter et nous parler de ton activité ?

Yann-Éric Devars : Je suis dirigeant de Solve DSI, une entreprise de conseil. J'exerce deux activités complémentaires :
DSI de transition en temps partagé, plutôt pour des grosses PME et ETI, et Architecte d'entreprise, le plus souvent au service de DSI dans de grandes entreprises, des services publics ou administrations.

Sylvain Melchior : Tu as des secteurs de prédilection, ou c'est assez généraliste ?

Yann-Éric Devars : Plutôt généraliste. Je comprends assez vite les métiers et leurs points communs, ça fait pas mal d'années que je travaille dans le domaine, j’ai donc de l'expérience dans à peu près tous les secteurs.

Sylvain Melchior : Pourquoi les entreprises font-elles appel à toi ? Y a-t-il des incendies à éteindre ?

Yann-Éric Devars : Ce qu'elles voient, ce sont souvent les incendies effectivement.
Mais en réalité, elles ont souvent mal lancé leur transformation, ne l'ont pas lancée, ou n'ont pas financé son lancement. Alors leur transformation ne se fait pas, ou par petits morceaux peu matures, et ça allume des feux un peu partout. Mon rôle, c'est de traiter les causes, en m'appuyant sur les équipes fonctionnelles et techniques locales qui connaissent bien le terrain. J'arrive avec un œil externe, je règle les sources des problèmes et j'éteint les feux : c'est le travail opérationnel le plus courant.

Sylvain Melchior : Quelles sont les thématiques chaudes du moment ? On entend parler de souveraineté, d'IA…

Yann-Éric Devars : La souveraineté, on la définit en général au niveau des États.
Au niveau des entreprises, c'est la capacité à prendre des décisions dans leur propre intérêt. L'époque du SaaS a fait beaucoup de mal de ce point de vue. Les entreprises ont acheté des solutions un peu partout et se retrouvent dépendantes de fournisseurs parfois abusifs, avec des contrats signés en confiance mais mal cadrés. Il y a souvent une sortie de dépendance à organiser. Le SaaS reste utile, bien sûr : on ne peut pas tout faire soi-même, c'est un modèle qui fonctionne, à condition de le cadrer.

Il y a aussi le « move to cloud », plus ancien, où l'on mettait tout dans le cloud en pensant externaliser totalement la DSI : ça n'a pas fonctionné. Et puis il y a l'IA, avec des attentes énormes, là, ce qui compte, c'est la structuration des données et la capacité à faire sa propre IA. Dans le SaaS, vous dépendez de l'IA du fournisseur, et si vous ne voulez pas qu'on exploite vos données, vous devez bâtir la vôtre, tout ça doit être défini, accepté, cadré et mis en œuvre. Je ne suis pas là pour freiner l'évolution, au contraire. : l'objectif, c'est d'avoir des bases solides pour ne pas retomber dans les mêmes travers et ne pas être ralenti par des corrections ultérieures.

Sylvain Melchior : Et c'est là qu'entre l'architecture, dans ce cadrage, cette gouvernance ? Comment définirais-tu le rôle de l'architecte ?

Yann-Éric Devars : L'architecte est là pour préparer l'avenir, pour construire une maison qui dure, pas une maison vite faite, ou si c’est le cas, il faudra prévoir sa consolidation ultérieure : parfois nécessité fait loi.
Les SI deviennent de plus en plus complexes et interconnectés, ils durent longtemps et coûtent cher. Il faut donc qu'ils soient solides, en identifiant les endroits qui doivent l'être le plus. L'architecte construit des choses durables et économiques à exploiter. Cette dimension économique est justement la grande oubliée de l'architecture, et c'est ce que j'ai ajouté dans Dynamap SI. Aujourd'hui, beaucoup de SI tombent en panne par manque de carburant : depuis 2019, les DSI sont presque tous entrés dans les CODIR. Avant, c'était le directeur financier qui portait leur voix et leur budget, désormais les DSI font face au CODIR mais ne savent parfois pas parler d'argent, ni expliquer les bénéfices concrets du SI et se retrouvent en difficulté.

Or aucun framework d'architecture connu ne parle d'économie, à part Dynamap SI et NAF : DYNAMAP SI cartographie où investir, pourquoi, ce que ça va rapporter et faire économiser et tout ça dans une logique de transformation continue. Avant, on raisonnait par vagues, à la manière industrielle : on renouvelait le parc, on repartait. Aujourd'hui, voter un budget figé sur un an est complètement hors de propos par rapport au contexte de transformation continue. Il faut pouvoir réagir immédiatement à un nouveau concurrent, un nouveau marché, un nouveau produit. La transformation est continue, donc l'économie doit l'être aussi : c'est pour ça que tout le monde devrait avoir un architecte.

Sylvain Melchior : Ça me rappelle une conférence de Gregor Hohpe sur l'organisation « anti-fragile » : ne pas construire une forteresse incassable, mais un système capable d'encaisser les chocs, technologiques ou de conformité, pour rester compétitif. Tu utilises ce concept dans Dynamap SI ?

Yann-Éric Devars : Dans mes démarches, oui, dans le framework lui-même, non.
Le framework reste axé sur une méthodologie pour permettre à tout le monde de faire de l’architecture d’entreprise : on monte en maturité étape par étape. C'est aussi une vision ! penser que TOGAF est le seul référentiel, c'est fou : il a été conçu par le département de la Défense américain, un million de salariés. Aucune entreprise française n'atteint cette taille, et nos plus grandes fonctionnent plutôt en business units, comme des PME. Ouvrir TOGAF aujourd'hui sans avoir une culture de l’architecture d’entreprise suffisamment mature  c'est l'échec assuré. Il faut monter progressivement en maturité : utilisez TOGAF si vous voulez, mais un framework comme Dynamap SI suffira en général.

Sylvain Melchior : Quand tu interviens chez un client, il part de quelle base ? Feuille blanche, ou TOGAF qui n'a pas pris ? Qu'est-ce qui les séduit dans ton framework ?

Yann-Éric Devars : Plusieurs cas :
La feuille blanche, d'abord : ils ne savent même pas qu'un framework d'architecture existe. Ensuite, ceux qui ont déjà fait du TOGAF ou du Zachman, et qui constatent que Zachman, plus ancien, est en fait moins ringard car plus facile à adapter aux méthodes modernes. Et puis les services publics, qui doivent s'appuyer sur des référentiels en français, notamment du fait de la loi Toubon : pour eux, être souverains jusqu'au bout, c'est aussi utiliser une méthode française. En général, la complexité de TOGAF joue fortement en sa défaveur. Il y a aussi l'approche « outil magique » : croire qu'on fait de l'architecture en achetant un logiciel qui travaille à votre place : ça ne marche pas, car il manque la gouvernance et la compréhension de ce qu'est l'architecture, et les formations disponibles parlent encore de concepts des années 80.

Dynamap SI modernise tout ça et apporte les bénéfices de l'architecture de manière progressive. On entre souvent par un angle précis : le SI coûte trop cher, le SI est trop complexe à réparer, ou les projets n'aboutissent pas.

Sylvain Melchior : Les ERP, par exemple…

Yann-Éric Devars : Voilà. Il y a plein d'angles d'arrivée différents.

Sylvain Melchior : On voit beaucoup de portes d'entrée : le coût, la technique, les transformations qui patinent. Et la conformité ?

Yann-Éric Devars : Plus rarement, et ça me va très bien, car le sujet évolue très vite.
En revanche, je la facilite énormément.
Ce sont souvent les prestataires de mes clients qui me sollicitent : ils veulent une méthode pour comprendre le SI du client, l'expliquer au métier et le projeter dans l'avenir et c'est exactement l'objectif de Dynamap SI.

Sylvain Melchior : Tu as évoqué la façon dont le DSI communique avec le Comex. Est-ce que l'architecture, ou Dynamap SI, peut l'aider à mieux communiquer ?

Yann-Éric Devars : Regardez la logique de TOGAF : « Allez voir les métiers, recueillez leurs besoins, adaptez le Framework et déployez. » D'abord les processus métier, puis l'IT, puis l'infra, puis le projet. Cette démarche fonctionne mal dans les PME, les ETI et les services publics, parce qu'on ne sait pas ce qu'on a. Dans le public surtout : gros legacy, départs en retraite, complexité que plus personne ne maîtrise. Et quand vous demandez au métier ce qu'il veut, il ne connaît souvent même pas tous ses propres processus, ni totalement les logiciels qu'il utilise. Ce que précise Dynamap SI, c'est l'inverse : connaître votre SI* avant d'aller voir les métiers, sinon vous allez vous faire atomiser, parce que le métier connaîtra mieux que vous le vieux logiciel absent de votre CMDB ou le fichier Excel que vous ignorez. Vous risquez de proposer des solutions moins bonnes que l'existant, ou de découvrir votre SI en même temps qu'eux.

(* Par SI, je ne parle pas seulement des logiciels et infrastructures mais également les objets métiers, les processus, etc. …)

Une fois que vous maîtrisez votre SI, le dialogue change. Le métier exprime un besoin, et vous pouvez répondre : « Ça, ça se fait déjà ici. » et là on entre dans un vrai échange, pas dans une interview. Car TOGAF, c'est une interview, comme si vous maîtrisiez déjà votre SI et ce n'est pas la réalité du terrain.

Sylvain Melchior : Tu as aussi évoqué Solve DSI Studio. Tu peux nous en dire plus ?

Yann-Éric Devars : J’ai fini par créer le Studio pour déployer l'intégralité de Dynamap SI dans un seul logiciel car beaucoup de clients me le demandaient. Ceci évite que les gens finissent sur des feuilles Excel ou se perdent dans des outils externes pour produire les livrables. Le Studio est orienté architecture d'entreprise : c'est un repository, pas un simple outil de cartographie. La connaissance s'y retrouve facilement, simplifiée, organisée autour de la chaîne de valeur et des assets vitaux de l'entreprise, avec les capacités d’analyse d’impacts en cas d'incident.

Sylvain Melchior : On aime finir nos interviews par des conseils opérationnels, « les dix travaux de Yann-Éric ». Quand tu démarres une mission, tu as des convictions sur la bonne façon de découvrir un nouveau SI ?

Yann-Éric Devars : Il faut découvrir le SI au sens large par le haut, pas par les outils du bas. Les gens disent souvent : « On a une CMDB, on connaît notre SI. » Pas du tout : une CMDB vous donne votre système informatique, pas votre système d'information. Connaître le système d'information, c'est savoir où l'information est vitale, où elle est stratégique, où elle est support. Prenez une grande enseigne d'articles de sport qui tomberait en panne à la rentrée scolaire ou juste après le Nouvel An : elle aurait énormément de mal à s'en relever.

À d'autres périodes, la même panne serait absorbable. Le savoir, c'est déjà essentiel, et la gestion des stocks y est vitale par exemple, mais chaque entreprise est différente : Au restaurant, dire « il n'y a plus ce plat » ne fait pas fuir les clients. Dans un magasin de sport en panne à la rentrée, les gens laissent leur caddie et filent chez le concurrent d'en face : vous profitez à vos concurrents, et en plus vous vous désorganisez en devant tout remettre en rayon. Il faut donc profiler l'entreprise, comprendre ses chaînes de valeur et ce qui est vital, au niveau métier comme technique. C'est le travail du DSI : faire circuler l'information.

Et le piège classique, c'est que tous les métiers se croient vitaux, tous.

C'est un vrai problème, et le côté un peu drôle de la chose. Le responsable des imprimantes vous dira : « S'il n'y a plus d'imprimante, on ne signe plus de contrat, on n'a plus de clients. » Dans la plupart des cas, l'entreprise continue, pourtant parfois il a raison et il est le seul à le savoir.

Sylvain Melchior : Oui, comme le commercial persuadé de faire cent pour cent du chiffre à la force de ses rendez-vous.

Yann-Éric Devars : C'est la notion de continuité. Certains métiers peuvent décevoir sans mettre l'entreprise à genoux, d'autres, s'ils défaillent, la mettent à genoux.
Chacun est souvent vital, mais pas dans le même temps : une interruption d'une heure ou de deux heures n'a pas le même poids selon l’époque. Or, avec une vision ancienne du SLA, on traite les incidents dans l'ordre des SLA contractuels. Résultat : un incident sur quelque chose de vital passe après un SLA non vital qui arrive en fin de vie. Appliquer l'ITSM tel quel, c'est se désintéresser de la chaîne de valeur et laisser le pouvoir sur la continuité de l'entreprise à des techniciens. C'est là que les DSI sont en difficulté, coincés entre l'ancien monde et un nouveau monde qui exige de la réactivité.

Sylvain Melchior : C'est passionnant. En tout cas, merci infiniment pour ton temps, Yann-Éric.

Yann-Éric Devars : Un grand merci à toi pour cette interview.