Cabinet de conseil en architecture SI et data : exigez une trajectoire, pas seulement un audit

Un cabinet de conseil en architecture SI et data doit vous aider à décider quels composants conserver, quelles données fiabiliser et quels chantiers engager en priorité. Sa valeur ne se mesure pas au volume de diagrammes produits, mais à la capacité de ses recommandations à guider les investissements et la réalisation. Pour sélectionner un partenaire, examinez ensemble son périmètre d’expertise, ses livrables et les conditions de passage à l’action.

Partir des décisions à prendre, plutôt que des technologies

Une fusion, une migration cloud, des applications vieillissantes ou des indicateurs métiers contradictoires constituent des points d’entrée possibles. Ils n’appellent pas nécessairement la même mission. Avant de demander un audit général, formulez la décision attendue : rapprocher plusieurs SI, remplacer une application critique, sécuriser les échanges ou rendre les données exploitables.

Cette formulation permet de distinguer les niveaux d’intervention. L’architecture d’entreprise relie stratégie, organisation, capacités métiers et système d’information. L’architecture SI décrit l’organisation des fonctions, applications, interfaces et infrastructures. L’architecture data précise la structuration, le stockage, la circulation et l’exposition des données. La gouvernance définit, quant à elle, les responsabilités et les règles qui encadrent leur gestion.

L’urbanisation du SI vise la cohérence de cet ensemble : éviter les fonctions redondantes, clarifier les frontières entre applications et maîtriser leurs dépendances. Ces disciplines doivent dialoguer. Une plateforme de données ne corrigera pas, à elle seule, des définitions métiers incompatibles ou une responsabilité mal attribuée.

Lors du cadrage, associez donc la DSI, les responsables data, les métiers concernés et l’exploitation. Le cabinet apporte une méthode et un regard externe ; l’entreprise reste responsable de ses priorités et de ses arbitrages.

Exiger un diagnostic qui explique les blocages

Une cartographie applicative est utile si elle permet de comprendre les conséquences d’un changement. Elle doit relier les applications aux fonctions métiers, aux données échangées, aux interfaces et aux composants techniques critiques. Un inventaire sans dépendances ni responsables identifiés reste difficile à exploiter.

Observer les flux réels et la dette technique

Le diagnostic combine entretiens, analyse documentaire et vérifications techniques adaptées au périmètre. Il recherche les obsolescences, les traitements manuels, les échanges fragiles, les duplications et les contraintes d’exploitation. La dette technique doit être qualifiée par ses effets : risque d’incident, difficulté de maintenance, lenteur des évolutions ou dépendance à une compétence rare.

Pour éprouver la cartographie, suivez une donnée comme une aiguille traverse plusieurs couches de tissu : de sa saisie jusqu’au reporting, en passant par les transformations et les interfaces. Sur un montant de commande, vérifiez notamment l’unité, la devise, la date de référence et les corrections. Cette traversée révèle parfois une rupture de sens invisible dans les schémas techniques : deux applications échangent correctement un champ, mais n’en partagent pas la définition.

Rendre les constats vérifiables

Demandez un registre des constats distinguant faits observés, hypothèses à confirmer et risques associés. Chaque recommandation importante devrait préciser le périmètre touché, les dépendances et la décision attendue. Cette discipline évite de transformer une préférence technologique en conclusion d’audit.

La sortie du diagnostic doit permettre de prioriser. Une application ancienne n’est pas automatiquement le premier chantier ; un flux récent mais indispensable à la facturation peut présenter un risque plus immédiat.

Relier architecture cible, gouvernance data et feuille de route

L’architecture cible décrit un fonctionnement souhaité, mais aussi les principes qui permettront de le maintenir. Projexion met notamment en avant 4 principes d’agilité du SI : modularité, couplage faible, interopérabilité et cohérence dans le temps. Leur intérêt est opérationnel : permettre l’évolution d’un composant sans imposer la refonte de tout le système.

Comparer des scénarios plutôt que prescrire une solution

Le cabinet doit confronter plusieurs options : conserver et sécuriser, moderniser progressivement, remplacer ou mutualiser. L’arbitrage entre développer, réutiliser et acheter doit intégrer le coût total de possession, la sécurité, la performance, les compétences et la réversibilité. Les microservices ou le serverless ne sont pas des objectifs en soi ; leur pertinence dépend aussi de votre capacité à les exploiter.

Le schéma directeur transforme ces choix en trajectoire. Des horizons à +1 an et +3 ans, évoqués par Projexion, peuvent articuler actions prioritaires et transformations structurelles. Chaque chantier doit comporter des prérequis, un responsable, des jalons et des conditions de validation, avec une place explicite pour la migration et le retrait des anciens composants.

Attribuer des responsabilités sur les données

La gouvernance des données doit désigner qui définit une donnée, qui contrôle sa qualité et qui arbitre les usages. Un Data Management Office peut coordonner ce dispositif si sa taille reste proportionnée à l’organisation. Le socle comprend des définitions partagées, des responsables identifiés, des règles de qualité et des droits d’accès cohérents avec les exigences de conformité.

L’automatisation vient ensuite. Selon une statistique attribuée à The Open Group et relayée par Eleven Labs, 60 % des organisations prévoiraient d’automatiser une partie de leur gouvernance d’ici 2027. Cette perspective ne dispense pas de clarifier les règles : automatiser un contrôle mal défini ne résout pas le désaccord métier initial.

Contractualiser des livrables utilisables par les équipes

Une proposition commerciale doit préciser ce qui sera remis, à quel niveau de détail et selon quels critères d’acceptation. Le tableau suivant constitue une base de discussion, à adapter à votre maturité et à l’étendue de la mission.

Prévoyez également les modalités de mise à jour des cartographies et du référentiel de décisions. Sans propriétaire interne ni support modifiable, les livrables risquent de devenir obsolètes dès les premières évolutions.

Le suivi peut porter sur les incidents d’interface, les délais de mise à disposition des données, les anomalies de qualité ou les applications effectivement retirées. Fixez l’état initial et la méthode de mesure avant de promettre une amélioration.

Choisir le cabinet sur des preuves et préparer le premier échange

Comparez les intervenants réellement affectés à la mission, pas seulement les références du cabinet. Une certification comme TOGAF 9.2, mentionnée par Projexion, renseigne sur une formation méthodologique ; elle ne remplace pas l’expérience d’une transformation comparable à la vôtre.

• Compréhension métier : les consultants relient-ils leurs propositions à vos processus critiques ?
• Expérience pertinente : peuvent-ils expliquer leur rôle précis dans une mission comparable ?
• Indépendance : les partenariats éditeurs et les intérêts d’intégration sont-ils explicites ?
• Capacité de réalisation : qui accompagne les migrations, l’exploitation et le changement ?
• Transmission : comment les équipes internes reprendront-elles les décisions et les outils ?

Le budget et la durée dépendent notamment du périmètre, de l’accessibilité des informations, du nombre d’interlocuteurs et de la profondeur des vérifications. Demandez que ces hypothèses figurent dans la proposition, avec les responsabilités respectives du cabinet et de votre organisation.

Pour un premier échange, préparez vos priorités métiers, vos principales difficultés, les projets engagés et les documents existants, même incomplets. Demandez ensuite un cadrage précisant livrables, mobilisation interne et critères de réussite. Le bon partenaire doit rendre votre organisation capable de décider et de faire évoluer son architecture après son départ.