Et si votre transformation digitale ne commençait pas par un outil ?

Revenir aux fonctions, aux besoins et à la création de valeur avant de parler solutions.

Dans les projets de transformation digitale, le même réflexe revient presque systématiquement : on parle très vite de solutions, d’outils, de plateformes. ERP, CRM, EPM, SIRH, outils data ou outils métiers… Les catégories sont connues, rassurantes, et donnent le sentiment d’avancer. Pourtant, en allant directement vers les solutions, on passe souvent à côté de l’essentiel : la question de la finalité.

Quel besoin cherche-t-on réellement à couvrir ? Quels irritants veut-on résoudre ? Quelles fonctions doivent évoluer pour créer plus de valeur ? C’est précisément à cet endroit que l’architecture fonctionnelle joue, selon moi, un rôle clé — et trop souvent sous-estimé.

Une architecture fonctionnelle permet de revenir à l’essence même de l’organisation : ce qu’elle fait, avant de se demander avec quels outils elle le fait. Elle oblige à reformuler le problème non pas en termes de solutions, mais en termes de fonctions et de besoins métier. C’est pour cette raison que je commence systématiquement mes projets de transformation digitale par cette étape.

Un cadre… et surtout un outil de dialogue

L’architecture fonctionnelle est avant tout un outil pour penser l’entreprise à partir de ses besoins réels. Elle permet de se poser les bonnes questions : quelles sont les fonctions clés ? Où se crée la valeur ? Qu’est-ce qui fonctionne aujourd’hui, qu’est-ce qui bloque, et pourquoi ? Contrairement à des approches centrées directement sur les solutions ou les outils, elle remet la finalité au cœur de la réflexion.

C’est aussi ce qui en fait un formidable support de dialogue. Tout le monde sait parler de fonctions. Même sans être architecte, chacun peut se projeter dans ce que fait l’entreprise, dans les interactions entre équipes, dans les zones de friction ou de dépendance. L’architecture fonctionnelle crée ainsi un langage commun entre les métiers, l’IT et la direction, et sert de point d’appui pour des ateliers concrets, où l’on cherche moins à produire un schéma parfait qu’à construire une compréhension partagée de l’organisation et de ses priorités.

Il existe bien sûr des cadres et méthodologies largement reconnus pour structurer l’architecture d’entreprise. Des référentiels comme TOGAF (The Open Group Architecture Framework), Zachman, ou encore les approches d’Enterprise Architecture portées par des organismes comme The Open Group ou BCG / Gartner, fournissent des modèles éprouvés pour penser l’entreprise dans sa globalité : stratégie, processus, données, applications et technologies.

Ces cadres apportent une vision systémique, des principes de structuration solides et des fonds de carte utiles pour aligner IT et stratégie. Ils sont particulièrement pertinents dans des contextes complexes, multi-entités ou fortement régulés, et constituent une base de travail précieuse pour les architectes d’entreprise.

Dans la pratique, toutefois, notamment lorsqu’on travaille avec des équipes métiers, ces cadres peuvent parfois devenir trop abstraits, trop normés ou trop éloignés du quotidien opérationnel.

Un modèle pensé pour les organisations de services

Au fil des années, mon expérience m’a amenée à développer une approche spécifique de l’architecture fonctionnelle pour les organisations de services, de conseil et de technologie. Ce sont des environnements particuliers, où il n’y a pas de produit tangible, et où la connaissance, les compétences et les personnes constituent la matière première de la création de valeur.

Dans ce modèle, toutes les fonctions sont essentielles au fonctionnement de l’entreprise, mais elles n’ont pas toutes le même poids vis-à-vis du business ni le même impact sur la création de valeur. J’y distingue trois grands ensembles.

Le premier correspond au cœur business. Dans les sociétés de services, il regroupe typiquement le commerce, les talents, le matching entre besoins clients et expertises, ainsi que le delivery. C’est là que la valeur se crée directement.

Le deuxième ensemble regroupe les fonctions support : finance, juridique, achats, marketing et communication, IT, data et analytics. Ces fonctions assurent le bon fonctionnement de l’entreprise et se positionnent comme de véritables business partners du cœur business.

Enfin, j’introduis volontairement très tôt un troisième ensemble : les référentiels et concepts métier. Quels sont les grands concepts manipulés par l’organisation ? Quelles données structurantes ? Qui en est responsable ? Ce travail prépare la suite : gouvernance de la donnée, golden sources, puis architecture applicative.

Un levier stratégique, pas un exercice IT

Travailler sur l’architecture fonctionnelle permet également d’aborder des sujets souvent sensibles mais incontournables : quelles fonctions doivent être portées au niveau groupe ou international, lesquelles doivent rester locales ou régionales, où créer des synergies fortes et où préserver de la flexibilité terrain.

Ces choix ne sont pas techniques. Ils sont profondément stratégiques. Ils traduisent les ambitions de l’entreprise, sa trajectoire de croissance, son rapport au local et au global. C’est précisément pour cela que l’architecture fonctionnelle ne doit pas être cantonnée à un exercice d’architecte IT, mais devenir un outil d’aide à la décision.

De l’architecture fonctionnelle à l’architecture applicative

Une fois ces fondations posées, la transition vers l’architecture applicative devient beaucoup plus naturelle. On ne choisit plus un outil “par catégorie”, mais on associe des solutions à des ensembles de fonctions clairement définis, en tenant compte de la stratégie de l’entreprise, de son organisation et de ses réalités opérationnelles.

Cela permet d’éviter les approches uniformes et dogmatiques — un outil unique pour tout le monde — au profit de trajectoires plus nuancées, plus réalistes et souvent plus efficaces. L’outillage devient alors un moyen au service d’une ambition business, et non une fin en soi.

La transformation digitale commence avant les outils

La transformation digitale n’est pas une stratégie IT. Ce n’est ni un objectif autonome, ni un exercice abstrait mené loin du terrain. C’est une réponse à des enjeux de stratégie d’entreprise : création de valeur, performance, attractivité, capacité à évoluer.

Lorsqu’elle est bien utilisée, l’architecture fonctionnelle permet précisément de faire le lien entre la vision stratégique et les choix opérationnels à venir. Et, peut-être tout simplement, de se poser les bonnes questions avant de chercher les bonnes solutions.