Fin des cathédrales, ère du pragmatisme : l'architecture d'entreprise change de posture

Interview de Louis Collinet (Onepoint), propos recueillis par Sylvain Melchior (Boldo).

De l'audit IT chez PwC à l'Enterprise Technology Management chez Onepoint, Louis Collinet a vu le système d'information sous toutes ses coutures. Consultant spécialisé dans le luxe et l'enseignement supérieur, il défend une architecture d'entreprise pragmatique : une discipline qui commence par la connaissance du SI, se prouve par la valeur, et se matérialise aujourd'hui grâce à une nouvelle génération d'outils.

De la machine à la stratégie

Salut Louis, merci beaucoup pour ton temps. Pour commencer, dis-nous en un peu plus sur toi, ton parcours et ce que tu fais aujourd'hui.

Je suis ingénieur diplômé de Télécom SudParis et j'ai commencé très vite dans le conseil et l'audit : d'abord chez EY, puis quatre ans d'audit des systèmes d'information chez PwC. J'ai ensuite rejoint Onepoint sur des sujets de stratégie IT et d'architecture d'entreprise, avant d'évoluer vers ce qu'on appelle chez nous l'Enterprise Technology Management : l'orchestration de l'ensemble des technologies, et des compétences qui les entourent, au service du système d'information, lui-même au service de l'entreprise.

Quels types d'organisation accompagnes-tu ? Plutôt des grands groupes, des ETI ?

Quand j'étais auditeur, je couvrais le secteur assurantiel, pour des groupes comme AXA ou Swiss Life. Il s'agissait d'audits réglementaires récurrents sur la sécurisation du SI : gestion des accès, des évolutions, séparation des droits et des environnements. Chez Onepoint, mon parcours a été multisectoriel : enseignement supérieur, banque, assurance, énergie, construction, et plus récemment le luxe, sur lequel je travaille activement depuis plus de deux ans et demi.

Aujourd'hui, je cultive trois choses. D'abord ma connaissance sectorielle : avant de parler de technologie, un architecte d'entreprise doit comprendre le marché et le métier de l'entreprise qu'il accompagne. Ensuite mon expertise de cœur, la gestion de patrimoine SI : connaître suffisamment son système d'information, ses forces et ses faiblesses, pour prendre les bonnes décisions de modernisation et l'orienter vers une cible adaptée, résiliente et performante. Enfin, une activité de prospection et de pilotage commercial dans l'enseignement supérieur, un secteur qui me tient particulièrement à cœur.

Côtoyer des organisations de tailles et de maturités très différentes m'a appris une chose : ce qui a fonctionné dans un grand groupe ne s'applique pas partout. Les problématiques se déclinent selon des maturités, des histoires, des segments de marché. C'est en orchestrant tous ces paramètres qu'on devient vraiment impactant dans ce métier.

Connaissance, coûts, risques : le triptyque de tous les DSI

Y a-t-il des enjeux communs entre un grand groupe du luxe et un établissement d'enseignement supérieur ?

Certaines problématiques concernent n'importe quel DSI, dans n'importe quelle entreprise au monde.

La première, c'est la connaissance de ce qu'on possède. Quelles sont mes applications, mes flux ? Quelles équipes utilisent quoi ? Quels projets vont avoir quel impact sur le SI, le métier, la chaîne de valeur ? Et la question la plus critique de toutes : quelles sont les dépendances entre tout cela ? C'est cette connaissance qui permet de mesurer l'impact d'une décision, d'une transformation ou d'un événement extérieur. Quand on parle de transformation IA ou de souveraineté, quand on veut s'éloigner de certains éditeurs ou de certaines régions, il faut d'abord comprendre les conséquences d'être, par exemple, full Microsoft, et quels scénarios catastrophes pourraient se produire demain. Pour construire ces scénarios et une matrice d'impact correcte, il faut connaître tous ces éléments interdépendants.

La deuxième, c'est le pilotage des coûts SI, ce qu'on appelle le pilotage TCO (Total Cost of Ownership) : l'ensemble des coûts qu'un parc applicatif engendre, qu'ils soient humains, de licences ou contractuels.

La troisième, c'est le risque, au sens large. Le risque réglementaire d'abord : suis-je exposé sur le RGPD ? La souveraineté, dont on parle beaucoup, entre dans cette dimension. Puis le risque informatique : suis-je vulnérable à des attaques ? Et même avant d'être attaqué, il y a l'obsolescence technique et les fins de support. Si un éditeur cesse de maintenir un système d'exploitation ou une application, l'entreprise se retrouve exposée à un risque qui ne dépend pas directement d'elle.

Et les différences sectorielles, alors ?

Traditionnellement, dans l'enseignement supérieur comme dans certains autres secteurs, on attend d'abord des DSI une excellence opérationnelle au quotidien, ce qui a parfois tendance à occulter leur potentiel stratégique. Ils gèrent le run : le quotidien, les incidents, les petites évolutions, les data centers, les serveurs. Ils sont rarement dans une posture de proposition de valeur auprès des directions académiques. Pourquoi ? Parce qu'historiquement, le DSI était un profil très technique, dans le garage ou dans la cave, qui s'assurait que la mécanique fonctionnait.

Aujourd'hui, l'enjeu rejoint celui de l'architecte : oui, cette complexité existe et il faut la traiter. Mais il faut aussi prendre du recul sur la valeur apportée à l'entreprise, sur ce qui bouge côté éditeurs, sur les technologies qui émergent, l'IA en tête. Bref, devenir un business partner. Ce mélange entre problématiques de marché et culture historique de la DSI, je le retrouve partout, quelle que soit la taille de l'organisation.

Le DSI au Comex : deux mondes qui se rencontrent enfin

Observes-tu une évolution de la position du DSI, notamment dans les grands groupes ?

Les Comex évoluent dans leur manière de solliciter les dirigeants tech, pour une raison simple. Dans le passé, le business model d'une entreprise dépendait souvent d'un éclair de génie : ce qu'on allait vendre et comment. Et ce « comment » ne devait pas grand-chose à l'informatique, simple outil d'accélération. On comptait surtout sur des profils brillants : dans le luxe, les directeurs artistiques, les directeurs marketing, les gardiens de l'image de marque. C'est toujours vrai. Mais aujourd'hui, pour gagner des parts de marché, le SI a pris son rôle.

Un exemple très simple. Avant le Covid, le luxe vendait très peu sur Internet. Les sites eCommerce n'étaient pas le vecteur principal d'achat, parce qu'une expérience luxe se vivait en magasin, soigneusement orchestrée pour des clients prêts à dépenser des sommes mirobolantes. L'effort ne portait pas sur la technologie mais sur l'accueil. Le Covid a accéléré une prise de conscience : il faut pouvoir vendre ailleurs, et la technologie permet d'offrir une expérience luxe virtualisée. Cela a déclenché énormément de réflexions sur la manière dont la technologie aide à mieux vendre, mieux porter l'image de marque, mieux écouter le client final. Les départements innovation des groupes de luxe voient leurs budgets technologiques croître. Avec l'IA, on peut aujourd'hui projeter via la caméra comment une pièce de collection pourrait m'aller. C'était impensable : il fallait aller en magasin.

Le Comex s'en rend compte. Et comme la technologie est un sujet nébuleux (on ne parle pas juste d'IA ou de cloud, mais d'un ensemble orchestré), il accorde beaucoup plus d'importance à ces profils. Sauf qu'il subsiste un clash, en train de se résorber : les directeurs techniques historiques n'ont pas toujours le langage Comex. On comble peu à peu ces lacunes, pour que celui qui connaît intimement le SI sache aussi en projeter la valeur pour le modèle économique et l'image de marque. Ces deux mondes commencent à se rencontrer. Et la souveraineté comme l'IA ne sont pas des sujets uniquement technologiques, mais ils restent éminemment technologiques : impossible de parler d'IA sans parler de data centers, d'énergie, de capacité, de performance. C'est formidable d'imaginer de l'IA partout dans l'entreprise, encore faut-il pouvoir l'accueillir, à tous les étages, y compris techniques.

L'architecture d'entreprise : une discipline, pas une personne

C'est là que la démarche d'architecture peut réconcilier ces deux mondes ?

Exactement. L'architecte n'est pas la seule personne à avoir un pied dans le métier, voire dans la stratégie, et un pied dans la tech, mais il reste un rôle pivot. Cela dit, je préfère parler de la discipline, ou de la culture de l'architecture d'entreprise, plutôt que de l'architecte. Faire tout reposer sur une personne (connaissance du business, de toutes les technos, capacité de veille) crée une pression énorme et n'est pas réaliste. Personne ne fabrique un iPhone de A à Z : des experts et des orchestrateurs intermédiaires font que le produit arrive à son terme avec de la qualité. Il en va de même pour l'architecture d'entreprise. Mais cette discipline, elle, demande à être orchestrée.

Elle demande aussi de ne pas faire porter tout le poids sur la technique. On a souvent reproché aux architectes, qu'ils soient solution, entreprise, technique ou intégration, d'être des ayatollahs de leur sujet, enfermés dans leur tour d'ivoire : des experts incapables de sortir de leur carcan, de projeter en quoi leurs concepts chéris et leurs vérités avec un grand V doivent, in fine, apporter de la valeur à l'entreprise. Ils se désintéressent alors de la réalité du terrain et s'enlisent dans des débats infinis. Cette mentalité doit évoluer.

Pour moi, l'architecture d'entreprise, c'est la capacité à identifier les bonnes personnes, celles qui détiennent la connaissance clé à chaque niveau du SI, pour garantir un enchaînement : connaissance de mon système d'information, évaluation de celui-ci, puis définition d'une cible et d'une trajectoire. Où je veux aller dépend des capacités du marché à fournir certaines technologies, de la maturité des éditeurs, de notre maturité interne et de nos compétences, mais aussi de la valeur qu'on peut apporter à l'entreprise. À la fin, l'architecte dit : voilà où est mon SI aujourd'hui, voilà où j'aimerais qu'il soit demain, voilà comment je le dirige, et voilà comment je m'assure de piloter tout cela correctement.

Cette mécanique as-is / to-be, on l'a toujours eue. Le vrai pivot, c'est de prendre des décisions pragmatiques. Je dois raconter une histoire qui part de la stratégie de l'entreprise et descend jusqu'à la donnée la plus opérationnelle que je pilote, puis distiller des responsabilités cohérentes sur des personnages clés. Cette histoire doit tenir d'un bout à l'autre : je ne peux pas me contenter d'une stratégie d'intégration, d'une stratégie d'infrastructure, d'une stratégie d'outils collaboratifs ou de cœur de métier, chacune dans son coin. Je dois comprendre comment tout s'instancie à la maille la plus opérationnelle, tout en permettant la prise de décision au Comex. Tant que ce fil rouge n'est pas écrit, on fait des choses en local qui n'apporteront peut-être jamais de valeur, ou une valeur discutable. C'est particulièrement vrai dans les grandes entreprises, où les équipes ont parfois du mal à se parler.

En mission : le devoir de conseil et l'art du séquençage

De l'audit IT, très proche de la machine, à la prise de hauteur chez Onepoint : quelles convictions ces expériences ont-elles forgées ?

Ce fil rouge dont je parlais, j'essaie de me l'appliquer à moi-même. Quand on arrive chez un client, via un appel d'offres ou parce qu'il nous confie ses problèmes du quotidien, on a ce qu'on appelle un devoir de conseil, qui vaut d'ailleurs aussi en interne : s'assurer que la problématique formulée est la bonne. On ne pose pas assez de questions, et parfois pas les bonnes. Celles qui permettent de vérifier si le problème posé est vraiment celui que l'entreprise doit affronter, ou s'il existe des problématiques sous-jacentes, des prérequis, qu'il serait plus judicieux de traiter d'abord. Mon premier principe : ne rien prendre pour argent comptant, et avoir assez de curiosité pour débusquer les points de douleur invisibles.

Je précise que je ne suis pas un ayatollah de méthode. Je ne suis pas du genre à décréter : « c'est exactement un schéma directeur qu'il te faut, on déploie ». J'aime entrer en empathie avec les problématiques de la personne en face, les croiser avec un contexte d'entreprise, un historique. Quelques principes guident mes questionnements, quelle que soit la méthodologie : repartir de la stratégie, regarder sa déclinaison opérationnelle, vérifier que des responsabilités existent à tous les étages pour faire vivre l'ensemble, s'assurer qu'on opérationnalise le conceptuel et qu'on sait reprendre de la hauteur quand on s'enfonce dans l'opérationnel. Si à la fin l'histoire s'appelle « schéma directeur », très bien ; si c'est un audit, très bien aussi. Cela ne m'empêche évidemment pas de m'appuyer sur les frameworks du marché quand c'est opportun : une analyse TIME, un 6R, une méthodologie TOGAF, ou des outils qui embarquent leur propre méthode.

Tu aurais un exemple concret de ce devoir de conseil en action ?

Récemment, un client est venu me voir car il croulait sous les urgences contradictoires. Il devait à la fois modéliser ses processus, planifier son move-to-cloud, se conformer à l'AI Act, réduire sa dette technique et éteindre l'incendie du shadow IT. Sa direction attendait des résultats sur tous les fronts, et tout de suite. Face à cette paralysie par l'analyse, son premier vrai problème n'était pas technique, il était méthodologique : c'était le séquençage.

Je lui ai donc posé une question toute simple : « Sais-tu exactement quels outils informatiques tournent chez toi aujourd'hui ? Avant de décrire tes process, de penser conformité ou data, as-tu un point de départ ? C'est comme si je te demandais : connais-tu le nombre de pièces de ta maison ? »

Avant d'accrocher un cadre au mur…

Voilà. Avant d'accrocher ton cadre, ce serait bien de savoir si tu as l'eau et l'électricité : les fondations de ta maison, celles qui permettent d'y vivre. Pour moi, les bases, ce sont ces questions : connais-tu les outils informatiques de ton entreprise ? Sais-tu ce qu'ils font ? À quelle capacité métier répondent-ils ? Es-tu capable de dire si tel outil sert à la vente ou à l'après-vente, s'il sert aux designers, à la compta, aux RH ?

Rien qu'en posant ces questions élémentaires, on découvre parfois qu'on ne sait pas y répondre. « Cet outil, il est un peu utilisé par les comptables et un peu par les RH. » Là, les vraies questions surgissent : est-il normal d'avoir des outils fourre-tout ? N'a-t-on pas détourné l'usage de celui-ci ? Ces simples interrogations révèlent si l'histoire de l'entreprise n'a pas produit une vraie confusion dans le déploiement des outils, surtout à l'échelle d'un grand groupe. Et elles engendrent les premières discussions utiles.

Et une fois cette base posée, comment priorises-tu ?

Ensuite, compte tenu de la maturité de l'entreprise et de ses ambitions, qu'est-il urgent que moi, architecte d'entreprise, je sache répondre à un Comex ? Si on me dit : « Louis, la conformité est impérative, on est dans l'assurance, demain il faut savoir répondre à DORA », mes questions seront : concrètement, que dois-je savoir piloter ? Quel est le cahier des charges ? Quelles informations cela demande-t-il ? Les ai-je dans mon SI ? Qui les détiendrait ? Quel outil pourrait porter quelle connaissance ? Avec quelle qualité de donnée ? Qui est responsable ?

Puis il faut savoir documenter dans le temps. Là, je suis en réaction ; demain, je ne veux plus l'être. Si on me repose la question DORA, je dois disposer d'un socle d'informations centralisées, sourcées partout dans mon SI, et répondre très vite : on est à risque ou pas, voilà l'effort à fournir, on a trois mois, et voici exactement ce qu'on va faire pour être irréprochable. Demandez aujourd'hui à n'importe quelle entreprise où elle en est sur DORA : la réponse est très difficile. Et je ne parle même pas d'aborder une transformation IA sans connaître ses applications de base.

Il y a des points de départ, puis des paliers stables de maturité. Une fois solide sur le nombre d'applications et leur fonction, on peut s'interroger sur leurs dépendances : qu'échangent-elles comme information ? Ce n'est pas une mince affaire, mais le jour où cette information existe, on passe à l'étape suivante, la santé sécurité des applications par exemple. Les équipes sécu portent cette connaissance, mais s'appuient souvent sur des référentiels périmés : elles se renseignent en local quand un audit arrive, et six mois plus tard, leur connaissance est déjà obsolète.

Le but, c'est une connaissance qui ne se périme pas : une méthode orchestrée qui responsabilise les bonnes personnes, installe la gouvernance et les bons rituels, crée une dynamique collective pour capter la bonne information. Et à l'ère de l'agentique, l'effort qu'on fournissait avant par bouche-à-oreille ou par mails collectifs, l'IA va pouvoir le démultiplier : sonder les SharePoint qu'on a correctement structurés, interroger les outils qui centralisent les informations clés, et vérifier rapidement si la connaissance est bonne, si on sait évaluer correctement, si on sait répondre aux enjeux de souveraineté, de réglementaire, de dette technique.

À chaque nouvelle priorité, on décline ce framework maison : responsabilisation, information à piloter, capacité d'évaluation, prise de décision. Et donc : comment je fais mieux, comment je fais différemment. Moins de dette technique, plus de conformité, anticiper un carve-out en cas d'acquisition, connaître sa data et ses interdépendances applicatives, être RSE compliant. C'est la base de la base. C'est une construction difficile à distiller dans l'entreprise, parce qu'il faut changer les mentalités et les cultures. Mais le jour où on prouve la valeur, en apportant une réponse très rapide sur un périmètre très large, la personne en face se dit : « Waouh, je n'aurais jamais cru que tu puisses me répondre si facilement. » Et cela donne envie à toute l'entreprise d'adopter la méthode, pour que chacun y trouve de quoi soulager son quotidien, accélérer ses décisions, anticiper les événements extérieurs. À la fin, on quitte la réaction pour la proaction : quand je n'ai plus peur de mon passé, de ce qui peut casser, de là où je ne suis pas conforme, je peux enfin me poser les bonnes questions, celles du mieux et du différent. On passe de la maîtrise des risques à l'innovation.

Or aujourd'hui, on essaie souvent de faire de l'innovation avant de maîtriser ses risques, notamment sur les grandes transformations IA à l'échelle. Ce n'est pas le bon timing. Oui, il faut y aller, mais en se posant les bonnes questions sur le comment. On le fait de manière un peu anarchique, et la discipline d'architecture d'entreprise apporte justement du rationnel à ces grandes transformations qu'on engage parfois à l'aveugle.

C'est vrai qu'il y a un côté FOMO de l'innovation : tu vois une entreprise voisine communiquer sur son IA (qu'elle mène peut-être aussi à l'arrache) et tu te précipites sur le use case avant même d'avoir, disons, rangé ta chambre.

« Ranger ta chambre »… j'aime beaucoup la métaphore. C'est exactement cela.

Outiller la discipline : la fin des cathédrales, l'ère du pragmatisme

Penses-tu qu'on peut outiller cette conviction, pour simplifier la collecte et la gouvernance de ce savoir ?

Oui, et c'est l'une de mes convictions fortes. L'architecte d'aujourd'hui doit avoir ses propres outils, comme un forgeron a les siens pour forger. L'architecture ne doit pas être que du « bullshit » méthodologique ou culturel ; je dis bullshit parce que certains pourraient la percevoir ainsi. Il faut rendre tout cela concret.

Pendant plus de vingt ans, le marché des outils d'architecture d'entreprise s'est lancé dans des solutions qui voulaient tout représenter dans le SI. C'était une époque où l'on se disait : le jour où le SI sera parfaitement modélisé, avec les organisations, les process, la chaîne de valeur, les coûts techniques, on comprendra les chaînes de dépendance et on prendra d'excellentes décisions. L'idée était déjà là. Le problème, c'était la méthode. À vouloir tout collecter, le temps de compter tous vos moutons, l'un est né à l'autre bout du pré et d'autres se sont échappés. Votre conclusion est déjà fausse au moment où vous l'obtenez.

Deux choses ont bougé sur ce marché, et n'importe quel architecte devrait s'interroger sur ses outils. D'abord, l'outil principal aujourd'hui, ce sont les solutions d'APM, l'Application Portfolio Management. L'application est le centre névralgique du SI : ce sont les outils de tout le monde, de toute l'entreprise. Derrière, il y a bien sûr des personnes, des process, des projets, des organisations, des technologies. Mais ce sont ces applications qui sont vitales au fonctionnement de l'entreprise. L'APM, c'est « je compte mes applications », mais pas n'importe comment. Je pourrais collecter toutes les informations du monde autour de chaque application : le contrat, le code sous-jacent, l'écosystème technique, le réseau, la sécurité. Sauf que le temps de tout compter, l'information est périmée, surtout en one-shot plutôt que dans la durée.

Et c'est là qu'interviennent les nouveaux outils ?

Les outils comme Boldo arrivent packagés avec une méthode, une philosophie. Je le sens dans ta manière d'en parler : tu ne recommandes pas de modéliser jusqu'à la prise électrique de l'entreprise, mais au contraire une approche hyper pragmatique, pour démontrer la valeur de cette discipline d'architecture.

Le plus grand enjeu d'un architecte d'entreprise aujourd'hui, c'est de rendre visuelle la culture qu'il essaie d'instaurer, cette connaissance du SI. Et pour la rendre visuelle, rien de mieux qu'un outil, couplé à la bonne méthode : je vais chercher une information vitale et je la dépose dans cet outil-là. Ces outils sont en plus très modernes, enrichis à l'IA ; ils ont hérité des casseroles du passé et se concentrent sur l'essentiel. L'architecte d'entreprise doit cesser de vouloir être expert de tout depuis sa tour d'ivoire : il doit se focaliser sur l'essentiel. Un outil comme Boldo est la parfaite matérialisation de ce pragmatisme.

L'avantage de cette nouvelle approche, c'est de rendre très vite les choses concrètes et visuelles auprès d'une direction générale : « Regardez ce qu'on a collecté en trois mois. Voici des cartographies, des dépendances très parlantes, qui s'adressent à un Comex et pas seulement à des profils techniques. » Et le Comex peut conclure : « Le budget de trois mois qu'on vous a accordé, vous l'avez vraiment rentabilisé, parce qu'aujourd'hui, dans cette instance, nous sommes capables de prendre une excellente décision : nous connaissons les risques, la criticité métier à l'échelle du groupe, les coûts. » Une fois qu'on a démontré que les outils et la méthode du passé n'étaient pas les bons, on peut réinvestir davantage dans la discipline, parce que sa valeur est désormais comprise.

Boldo arrive dans un formidable momentum : c'est un outil superbe, moderne, taillé pour le monde d'aujourd'hui. Et surtout, il a compris cet enjeu clé, celui qui permettra demain à l'architecture d'entreprise d'être une discipline reconnue au Comex, mais aussi au niveau des projets, des opérationnels, des équipes sécurité et juridiques. Elle deviendra ce point pivot qui établit un langage commun à l'échelle du SI et de l'entreprise, où l'on parle enfin de la même chose au service du même but, et qui réconcilie une histoire parfois douloureuse, faute de bonne méthode, de maturité technologique ou culturelle. Boldo apportera, à mon avis, beaucoup de valeur à tous les architectes qui lui donneront sa chance, et qui se donneront leur propre chance de changer de posture : prouver que derrière la méthode et le concept, il y a une réalité terrain, et une réalité visuelle, qu'on peut offrir à chacun.

Merci infiniment Louis, c'était une interview passionnante.

Avec plaisir !

Louis Collinet est consultant chez Onepoint, spécialisé en Enterprise Technology Management et gestion de patrimoine SI. Sylvain Melchior est fondateur de Boldo, plateforme moderne d'Application Portfolio Management et d'architecture d'entreprise.