Si votre DSI parle d’urbanisation du SI, il n’est pas forcément en train de vous préparer un grand schéma incompréhensible. Il essaie peut-être de répondre à une question très concrète : comment continuer à faire évoluer une entreprise dont les outils se sont empilés ?
J’aime toujours la comparaison avec une ville. Chaque quartier peut fonctionner correctement, alors que la circulation entre les quartiers devient impossible. Dans un SI, les embouteillages prennent la forme de ressaisies, d’écarts de stock ou de projets qui attendent tous la même interface. Voici les cinq règles que je garderais pour remettre de la cohérence.
L’urbanisation du système d’information consiste à organiser les applications, les données et leurs échanges en cohérence avec les activités et la stratégie de l’entreprise. Elle aide à décider ce qu’il faut conserver, faire évoluer, rapprocher ou arrêter. Son intérêt apparaît lorsque chaque nouveau projet devient difficile à intégrer au reste du SI.
L’image de la ville reste utile. Une application peut bien fonctionner dans son quartier et compliquer la circulation partout ailleurs. Dans l’entreprise, cette circulation concerne les commandes, les stocks, les factures, les données clients et les décisions. Ajouter un outil sans regarder ces échanges peut déplacer le problème plutôt que le résoudre.
Pourquoi urbaniser son système d’information
Une entreprise qui grandit accumule des solutions, parfois après un rachat ou pour répondre à une urgence métier. Chacune a sa justification. Avec le temps, plusieurs équipes entretiennent la même donnée, les interfaces deviennent difficiles à suivre et un changement local perturbe un autre service.
L’urbanisation rend ces dépendances visibles pour arbitrer. Elle doit permettre de répondre à des questions concrètes : où se trouvent les informations de référence d’une commande ? Qui décide d’un changement de règle de stock ? Quel outil peut être retiré ? Quel projet doit attendre que le référentiel soit fiabilisé ? Une cartographie qui ne sert à aucune décision mérite d’être simplifiée.
1 Ton legacy tu comprendras avant de le remplacer
Avant de remplacer un système ancien, il faut identifier les règles métier qu’il porte et les services qui en dépendent. Certaines exceptions sont inutiles. D’autres évitent une erreur de facturation ou permettent de servir un client particulier. L’âge de l’application ne suffit pas à trancher. Le risque, la valeur et la capacité à la maintenir doivent guider la décision.
2 Avec les métiers tu travailleras
La cartographie commence par les activités et les responsabilités. Ensuite viennent les logiciels. Sur une commande, par exemple, il faut comprendre qui promet la disponibilité, qui réserve le stock, qui prépare et qui facture. La DSI décrit les dépendances techniques. Les métiers expliquent les exceptions et valident les règles. La direction arbitre les désaccords qui dépassent un service.
3 La simplification tu n’oublieras pas
Deux outils qui contiennent une information identique ne constituent pas forcément un doublon inutile. Il peut exister une raison opérationnelle. En revanche, deux équipes qui corrigent indépendamment le même prix créent une ambiguïté. Pour chaque donnée importante, il faut préciser sa source de référence, les personnes autorisées à la modifier et les règles de diffusion.
La simplification peut conduire à supprimer un outil, à réduire une interface ou simplement à clarifier une responsabilité. Le résultat attendu se mesure dans le travail des équipes : moins de ressaisies, moins d’écarts, moins de temps passé à comprendre où le flux s’est arrêté.
4 Une architecture proportionnée tu choisiras
Une suite intégrée, des logiciels spécialisés et un développement spécifique peuvent coexister. Le headless, les API et les microservices répondent à certains besoins, mais ils ajoutent aussi des composants à exploiter. Je recommande de justifier chaque séparation par une contrainte réelle : autonomie d’évolution, performance, réutilisation ou besoin métier particulier. Le nombre de technologies employées ne mesure pas la qualité de l’urbanisation.
5 De patience et de priorisation tu feras preuve
La cible doit se traduire en étapes réalisables. Commencez par un périmètre qui bloque une activité ou plusieurs projets. Décrivez le changement attendu, les dépendances, le responsable et le résultat observable. Prévoyez aussi ce qui sera arrêté. Sans retrait de l’existant, la transformation peut simplement ajouter une couche.
Quelle place pour l’IA dans cette démarche
Un assistant, un agent ou une application créée avec l’IA doit figurer dans la cartographie dès qu’il intervient dans un processus réel. Quelles données utilise-t-il ? Que peut-il modifier ? Qui contrôle les erreurs ? L’IA donne de nouvelles possibilités, mais ses usages doivent rejoindre les mêmes règles de responsabilité et d’exploitation que les autres composants du SI.
Pour démarrer, choisissez un flux important et suivez-le de bout en bout avec les équipes concernées. Les décisions prises sur ce premier périmètre seront plus utiles qu’une représentation exhaustive dont personne ne se sert. Si votre entreprise a grandi plus vite que son SI, nous pouvons travailler sur les dépendances et les arbitrages à traiter en premier.
Questions fréquentes
Quelle différence entre urbanisation et cartographie du SI ?
La cartographie décrit l’existant. L’urbanisation utilise cette connaissance pour organiser les responsabilités, définir une cible et choisir une trajectoire. Le dessin sert à décider ce qui change et dans quel ordre.
Faut-il tout cartographier avant de commencer ?
Je commencerais par un flux important, ses applications et ses responsables. Le niveau de détail doit permettre les premières décisions. Il peut être enrichi à mesure que les autres périmètres deviennent utiles.
Pour approfondir
Votre entreprise a grandi plus vite que son SI, ou un choix d’outil bloque la transformation ? Je peux prendre ce sujet avec vous.
