Votre entreprise a grandi, les logiciels aussi. Pourtant, suivre une commande demande encore de passer par trois outils et un fichier Excel. Avant d’ajouter une nouvelle solution, une question mérite d’être posée : comment tout cela fonctionne-t-il ensemble ?
Qu’est-ce que l’urbanisation du SI ?
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.
J’aime 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. L’urbanisation informatique cherche à remettre de la cohérence entre ces quartiers, avec une trajectoire que l’entreprise peut réellement mettre en œuvre.
Voici comment je l’aborderais dans une PME ou une ETI, avec cinq règles pour garder la maîtrise.
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.
Exemple concret : une commande, trois versions du stock
Prenons un exemple simplifié dans une entreprise de distribution. Le site e-commerce affiche une disponibilité, l’ERP en annonce une autre et l’entrepôt travaille avec son propre stock. Le service client passe son temps à vérifier quelle promesse il peut tenir.
La tentation serait d’ajouter une interface ou de changer un logiciel. Je commencerais par suivre une commande : quel système fait foi pour le stock disponible à la vente ? Quand la réservation intervient-elle ? Comment une annulation est-elle répercutée ? Qui traite un écart ?
La décision peut être de clarifier la source de référence, de revoir la réservation et de retirer une synchronisation devenue inutile. Le choix dépend du fonctionnement réel. C’est cela, urbaniser : comprendre les dépendances pour choisir une évolution cohérente, puis vérifier son effet sur le travail des équipes.
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.
Comment démarrer l’urbanisation du SI en pratique ?
Je commencerais par un processus qui coûte du temps ou bloque des projets, par exemple de la commande à la facturation. Pour ce premier périmètre, voici les éléments à mettre sur la table :
- Le problème à résoudre. Quelle ressaisie, quel retard ou quel écart cherche-t-on à réduire ? Avec quel constat de départ ?
- Le parcours réel. Quelles équipes interviennent, dans quels outils, avec quelles exceptions et quels échanges manuels ?
- Les données et les responsabilités. Quelle source fait référence ? Qui peut modifier la règle et qui traite les erreurs ?
- La cible et les arbitrages. Que conserve-t-on, que change-t-on et que retire-t-on ? Quelles dépendances faut-il traiter avant de lancer les autres projets ?
- La première étape réalisable. Un responsable, une capacité disponible et un résultat observable, puis une cartographie mise à jour après le changement.
Cette approche évite de produire un inventaire que personne ne sait exploiter. Pour approfondir la construction et l’entretien de la cartographie, le guide de l’ANSSI sur la cartographie du système d’information propose une démarche progressive, principalement orientée vers la maîtrise des risques et la sécurité.
Questions fréquentes sur l’urbanisation du SI
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.
Quel outil utiliser pour urbaniser son SI ?
Pour un premier périmètre, un tableau partagé et un schéma lisible peuvent suffire à préparer les décisions. Si le nombre d’applications, de dépendances et de contributeurs augmente, un outil dédié peut faciliter les mises à jour et l’analyse d’impact. Le choix dépend surtout de ce qu’il faut maintenir et des personnes qui s’en chargeront. Acheter l’outil ne clarifie pas, à lui seul, les responsabilités.
Pour approfondir
Pour voir comment le diagnostic peut s’articuler avec la transformation et l’organisation de l’équipe IT, découvrez ma mission chez OPNR, du diagnostic SI au passage de relais au DSI.
Votre SI est devenu difficile à faire évoluer ?
Vos équipes ressaisissent les mêmes informations, personne ne sait quel outil fait foi ou chaque évolution perturbe un autre service ? Ce sont de bons points de départ pour examiner votre SI.
Dans un diagnostic du système d’information, je travaille avec la direction, les métiers et l’IT pour comprendre les blocages et mettre les décisions à prendre dans un ordre réaliste. Vous pouvez aussi m’écrire pour me décrire votre situation.
