Architecture d'entreprise, IA et souveraineté : conversation avec Almudena Manjarin

Entretien avec Sylvain Melchior, Boldo

Almudena Manjarin est consultante et architecte d’entreprise indépendante, elle accompagne aujourd’hui des PME et des ETI dans leur transformation : cartographie de leur système d’information, mise en place de l’IA sur des cas d’usage concrets, souveraineté des données et gouvernance. Nous avons échangé sur son parcours, sa vision du métier d’architecte d’entreprise et ses convictions.

Almudena, peux-tu te présenter et nous raconter comment tu es arrivée à l'architecture d'entreprise ?

J’ai commencé dans le domaine comme consultante chez Octo Technology, où je suis restée six ans. Mon point d’entrée n’était pas la technique : j’étais consultante stratégie et coach agile à l’échelle. C’est par l’organisation que je suis venue à l’architecture, en passant par la loi de Conway, les diagrammes de Team topologies, jusqu’à comprendre à quel point les systèmes d’information sont liés au système organisationnel.

Ça a commencé à m’intéresser, et j’ai rejoint une tribu d’architectes. J’y ai appris les bases : les différents niveaux avec TOGAF, le fonctionnel, le technique, l’infra. J’ai appris à cartographier et à modéliser, et c’est devenu une vraie passion. On apprend énormément sur une entreprise, on sécurise les choses, on comprend les enjeux aussi bien côté métier que côté technologique.

Ce que j’aime, c’est que c’est un travail de terrain, mais qui donne aussi des outils aux personnes qui doivent prendre des décisions, juger de l’utilité d’une application ou d’un outil. On est vraiment à cheval entre la technologie et le métier.

Est-ce que l'architecture d'entreprise était quelque chose que tu voyais systématiquement déployé chez tes clients ?

Honnêtement, pas tant que ça, et c’est justement ce qui m’a poussée à m’en occuper. J’ai souvent binômé avec des experts techniques d’un côté, et de l’autre des profils non tech qui travaillaient sur la culture d’entreprise, le change, le produit, l’UX. Ce qui m’intéressait, c’était le transversal et le fait d’avoir un langage commun.

Je voyais qu’on pouvait être déconnecté d’une certaine réalité quand on ne se plongeait pas dans la compréhension de l’architecture des produits et de l’entreprise. Il y a aussi une porte d’entrée par la data : on voit par où passe la donnée, comment elle est structurée, échangée. C’est un volet que j’ai abordé un peu plus tard, notamment avec le MDM.

Le métier d'architecte d'entreprise n'a pas toujours eu bonne presse. Qu'en penses-tu ?

C’est vrai qu’il y avait beaucoup de discussions autour de ça : est-ce qu’un architecte d’entreprise est vraiment un architecte, par rapport à un architecte technique ?

C’est un métier qui n’est pas toujours bien compris. Est-ce que c’est vraiment un métier, ou plutôt un état d’esprit ? Faut-il parler d’urbaniste, d’architecte d’entreprise, d’autre chose ? Le DSI ou la directrice de la transformation sont-ils des architectes d’entreprise ? Dans la communauté, ces échanges sont nombreux. Personnellement, je ne suis pas dogmatique. Quand l’équipe de Boldo a lancé le produit, ils n’étaient pas eux-mêmes architectes d’entreprise : le rôle s’endosse souvent naturellement. L’important, c’est d’ouvrir le débat.

Tu as mentionné le MDM (Master Data Management). Peux-tu nous en dire plus sur ce sujet ?

J'ai contribué à des missions de MDM et j’ai suivi une formation à la fin de mon expérience chez Octo qui m’a beaucoup plu. Concrètement, il s’agit de modéliser le processus métier d’un domaine et de créer un catalogue de données de référence, pour établir une base commune à plusieurs applications.

Prenons une entreprise commerciale : plusieurs acteurs différents utilisent souvent une même plateforme. Pour que tout fasse sens d’un métier à l’autre, il faut bien modéliser la donnée : qu’est-ce qu’un client, un fournisseur, une facture ? C’est toute une couche sémantique. Aujourd’hui, le MDM est un réel besoin, et c’est un vrai métier, différent de celui de l’architecte d’entreprise, même s’ils se rejoignent. J’ai d’ailleurs une mission en cours sur la single source of truth : faut-il créer une base de données dans le CRM, ou à l’extérieur pour avoir une source unique ? Ce sont typiquement des questions d’architecture.

Quels sont aujourd'hui les grands sujets de transformation qui rendent l'architecture indispensable ?

Auparavant, en tant que salariée de cabinets de conseil, j’avais plutôt de grands clients avec des problématiques parfois éloignées du terrain. Aujourd’hui, j’accompagne surtout des PME et des ETI et je vois peut être plus facilement l’impact concret et les enjeux d’un investissement dans le bon outil d’architecture d’entreprise. C’est ce qui me plaît.

Un sujet de transformation que j’observe est par exemple de mettre en place l’IA, mais sur des cas d’usage très précis, en commençant petit. J’accompagne la sécurisation et la gestion de la donnée, et tout le mindset à installer autour : data mesh, responsabilité sur le cycle de vie de la donnée. J’insiste aussi sur la transparence des produits adoptés : souveraineté, hébergement en Europe, un vrai service après-vente, de la proximité, et un prix correct.

J’ai aussi coécrit un livre blanc sur les OKR, et accompagné une équipe autour d’un catalogue de services de données open source. C’est très varié, du plus stratégique au plus opérationnel.

Parlons des OKR. Qu'est-ce qu'ils apportent, notamment côté DSI ?

D’abord, les OKR permettent d’engager le dialogue entre les leaders et les équipes. C’est précieux pour écouter les équipes, souvent plus à jour sur les nouvelles technos, et se mettre d’accord sur des objectifs à six mois avec des key results. Les key results clarifient ce qu’on veut suivre et obtenir, avec un calendrier précis de points d’étape. C’est une stratégie qui avance en marchant.

Ça débouche souvent sur des audits de système. L’architecture d’entreprise permet de cartographier puis d’auditer : une fois l’audit fait, on voit quel projet accompagner en premier, là où le risque est le plus grand. L’OKR et l’agile préconisent justement de commencer par là où il y a le plus de risque, avec une valeur ajoutée rapide, pour dérisquer.

Il y a aussi la question de l’intégration ou de l’abandon de solutions. On se réfère à la cartographie et aux OKR pour décider : a-t-on encore besoin de cet outil ? On arrête, on continue ? Cartographie, audit et stratégie sous forme d’OKR, tout ça permet de garder le système rationnel et optimal. Dans un monde idéal, bien sûr.

Un point clé des OKR, c'est l'autonomie laissée aux équipes. Tu peux développer ?

Un key result n’est pas un livrable, c’est le résultat qu’on veut obtenir, par exemple une meilleure satisfaction client. Réduire le nombre d’incidents devient alors un moyen, pas une fin en soi.

Ce que je trouve important, surtout dans les grandes entreprises, c’est de laisser de l’autonomie et de l’espace aux équipes. Si tu imposes « réduisez les bugs à X », tu peux l’obtenir. Mais si tu dis « voici le résultat qu’on vise, à vous de trouver les moyens », tu génères une motivation bien plus forte.

Tu évoques la souveraineté. Est-ce aussi un enjeu pour les petites entreprises ?

C’est un enjeu, mais ce n’est pas par là qu’elles commencent. Sortir de grandes solutions étrangères, ce sont d’énormes projets qui demandent beaucoup de structuration en amont : MDM, cartographie, liste des applicatifs. On parle de sources d’information colossale qui structurent l’entreprise. On ne peut pas casser ça sans préparation.

Ces projets demandent des équipes et des budgets conséquents, avec une roadmap par étapes. L’idée, c’est de commencer plus petit, par des POC, autour d’un domaine métier. Une fois la méthode éprouvée sur un domaine avec de nouveaux outils, on peut envisager de sortir progressivement des produits qu’on considère non conformes à une stratégie.

Concrètement, quand tu arrives chez un nouveau client, à quoi ressemble ta roadmap des premiers jours ?

Il y a d’abord plusieurs rendez-vous de prise de contexte et de compréhension, et beaucoup de recherche de ma part sur le métier. En tant qu’indépendante, on passe des cosmétiques à la banque en passant par l’industrie : il faut commencer par comprendre le langage et le métier du client.

Ensuite, ça passe souvent par des ateliers, par exemple pour modéliser et cartographier les processus métier, un vrai travail sur Boldo. À partir de là, et selon la demande, on peut avoir une phase de cartographie, puis du conseil sur l’intégration d’une solution avec tout le processus que cela implique, et de la formation derrière, à l’usage des solutions ou de l’IA.

J’ai par exemple une cliente dont l’entreprise a grossi et qui veut une cartographie de son SI avec de la hauteur de vue pour rationaliser. En résumé : prise de contexte, cartographie, puis audit de la situation, et ensuite de petits projets pour intégrer des solutions ou accompagner une équipe sur le mindset, la data as a product par exemple.

Pour finir, quelles convictions souhaites-tu partager ?

On a parlé de rationalisation, de coût, de sécurité. Une conviction forte : en tant qu’architecte d’entreprise, j’aime faire énormément de veille. Toute cette nouvelle génération de solutions, comme Boldo ou d’autres dans leurs domaines, mérite qu’on s’y intéresse de près. C’est un vrai plus pour avoir une longueur d’avance dans mon travail de conseil.

Je prends beaucoup de temps pour rencontrer les entreprises qui proposent des solutions, solliciter ou accepter des démos, comprendre qui est derrière, comment les solutions sont structurées, le pricing. C’est essentiel vu le moment actuel où tout bouge très vite. La technologie évolue vite. Cette veille permet de répondre aux besoins métiers, à ses processus.