SI en croissance : quand faut-il repenser son architecture

Le premier indicateur n’est pas technique, il est opérationnel.

Une évolution qui prenait deux semaines en prend désormais six.

Non pas parce que le sujet est plus complexe, mais parce qu’il faut “faire attention” à des zones sensibles.

Nous observons généralement :

• des impacts imprévus sur d’autres applications lors de modifications pourtant localisées,
• des phases de test qui s’allongent car le périmètre réel est difficile à anticiper,
• des dépendances implicites entre modules qui n’étaient pas documentées,
• des arbitrages permanents entre “faire vite” et “ne pas casser”.

Par exemple, une simple modification dans un outil de facturation peut nécessiter de vérifier des effets de bord dans le CRM, le reporting et un outil logistique, car des règles métier ont été dupliquées au fil du temps.

Ce type de situation indique que l’architecture a perdu en lisibilité, et surtout, qu’elle n’est plus maîtrisée.

Un autre signal critique concerne la donnée.

Tant que les volumes sont faibles, les incohérences restent invisibles.

Mais à mesure que le système d’information se développe, elles deviennent visibles et souvent problématiques.

Nous retrouvons des situations comme :

• un même client présent avec des informations différentes dans plusieurs systèmes,
• des écarts entre les chiffres du reporting et ceux de l’ERP,
• des règles de calcul non alignées entre applications,
• des synchronisations qui échouent sans être immédiatement détectées.

Prenons un cas classique : une entreprise gère ses clients dans un CRM, mais certaines informations sont modifiées directement dans un outil de facturation.

Au fil du temps, les deux systèmes divergent.

Le marketing travaille sur une base, la finance sur une autre.

Ce problème n’est pas un bug, c’est un problème d’architecture de la donnée.

À ce stade, continuer à ajouter des correctifs ne résout rien.

Il devient nécessaire de revoir la structuration globale, souvent via une démarche d’audit des systèmes d’information, pour identifier les sources de vérité et les flux critiques.

Un système d’information en croissance voit ses flux se multiplier.
Au départ, quelques intégrations suffisent.
Puis, chaque nouveau besoin ajoute une connexion supplémentaire.

Sans cadre architectural clair, cela donne :

• des échanges en temps réel mélangés à des traitements batch,
• des API utilisées sans versioning ni gouvernance,
• des scripts ou fichiers intermédiaires devenus critiques sans être supervisés,
• des dépendances circulaires entre systèmes.

Un exemple concret : un outil e-commerce envoie des commandes vers un ERP, qui alimente un outil logistique, qui renvoie des statuts vers le site.

En parallèle, un outil marketing récupère certaines données via un export nocturne.

Lorsque l’un des maillons ralentit ou tombe, l’ensemble du système est impacté, sans qu’il soit toujours évident d’identifier la cause.

Ce type de configuration indique que l’architecture des flux n’a pas été pensée globalement. Elle a été construite au fil des besoins.

Un système d’information mal structuré transforme chaque évolution en prise de risque.

Même des projets simples nécessitent des analyses longues, car les impacts sont difficiles à anticiper.

Nous observons notamment :

• des projets qui nécessitent une phase d’analyse disproportionnée,
• des délais qui explosent en cours de développement,
• des mises en production repoussées par crainte d’effets de bord,
• une dépendance forte à certaines personnes qui “connaissent le système”.

Dans certains cas, une évolution métier simple (comme l’ajout d’un nouveau type de produit ou d’un nouveau canal de vente) nécessite de modifier plusieurs applications, avec des risques sur la cohérence globale.

Ce n’est pas un problème de compétence, c’est un problème de structure.

Prenons un cas très concret : une PME industrielle qui a structuré son activité autour d’un ERP pour la production, puis ajouté un CRM pour le commerce, et plusieurs outils spécifiques pour la logistique et le suivi client.

Au départ, tout fonctionne. Mais avec le temps, des connecteurs sont ajoutés pour faire circuler les données, des exports Excel prennent le relais là où les flux ne sont pas prévus, et certaines informations critiques (comme les données clients ou les références produits) se retrouvent dupliquées dans plusieurs systèmes.

Résultat : une modification dans l’ERP ne se répercute pas toujours correctement dans le CRM, des écarts apparaissent, et chaque évolution nécessite des vérifications manuelles.

Ce n’est pas un dysfonctionnement visible immédiatement, mais une accumulation de dépendances et de contournements qui finit par ralentir tout le système.

C’est typiquement dans ce type de situation que la question de l’architecture ne peut plus être évitée.