Six couches
Canaux, expérience, métier, intégration, data et IA, infrastructure, sécurité, identité et observabilité restant transversales.
- Demander un diagnostic
- France et Afrique francophone
Représenter le système d'information en six couches, définir la source de vérité de chaque donnée, et choisir entre acheter, configurer, intégrer ou développer.
Canaux, expérience, métier, intégration, data et IA, infrastructure, sécurité, identité et observabilité restant transversales.
Décider quel système possède quelle donnée évite la synchronisation bidirectionnelle et ses conflits permanents.
Acheter, configurer, intégrer ou développer : le choix se justifie par le TCO, l'exportabilité et le contrôle, pas par la préférence technique.
Chaque partie traite un point de la démarche ; les liens ci-dessous mènent directement à la section correspondante.
Une architecture utile répond à trois niveaux de question : pour la direction, quelles capacités soutiennent l'activité et où sont les risques ? Pour les métiers, quels outils couvrent quel processus et quelle donnée fait autorité ? Pour l'IT, comment les composants communiquent-ils, sont-ils sécurisés, déployés et observés ?
Six couches structurent une architecture numérique : canaux (web, mobile, WhatsApp, email, voix), expérience (site, portail, app, chatbot), métier (CRM, ERP, e-commerce, support), intégration (API, webhooks, iPaaS, event bus), data & IA (base de données, entrepôt, BI, RAG, agents) et infrastructure (cloud, VPS, conteneurs, réseau), la sécurité, l'identité et l'observabilité restant transversales.
Pour chaque application, un inventaire minimum précise : nom, fonction, owner métier, owner technique, fournisseur, utilisateurs, coût annuel, contrat, date de renouvellement, criticité, données principales, SSO/MFA, intégrations, sauvegarde/export et dépendances.
Une API expose des opérations qu'un autre système peut demander ; un webhook informe un système qu'un événement vient de se produire. Chaque action déclenchée par un événement doit être conçue pour ne pas se répéter dangereusement si l'événement est reçu deux fois, c'est le principe d'idempotence.
Décider quel système possède chaque donnée (le CRM pour le statut d'une opportunité, l'ERP pour la facture, l'outil RH pour le contrat) évite la synchronisation bidirectionnelle par défaut, qui ajoute des règles de conflit dès que deux systèmes peuvent modifier librement le même champ.
Quatre options : acheter un SaaS quand la capacité est standard et le marché mature ; configurer une plateforme existante quand les écarts portent surtout sur des règles et workflows ; intégrer plusieurs produits spécialisés quand aucun outil unique ne couvre le besoin ; développer lorsque la capacité crée un avantage spécifique ou nécessite un contrôle particulier.
Le SaaS offre un délai plus court et un coût initial souvent plus faible, au prix d'un contrôle technique limité et d'un risque de verrouillage fournisseur. Le développement sur mesure est plus long et plus coûteux à construire, mais reste adaptable et évite la dette technique d'un outil mal ajusté au besoin. Le consultant calcule toujours le TCO sur plusieurs années et examine l'exportabilité des données, les API, le modèle de permissions et le SLA.
Une bonne architecture cible n'est pas un dessin de produits mais un ensemble de principes : identité centralisée et MFA pour les accès critiques, API documentées, journalisation sur les flux critiques, donnée propriétaire exportable, séparation des environnements développement/test/production, sauvegarde et restauration testées, secrets hors du code, droits minimaux, système de référence défini pour chaque objet métier et mécanisme de reprise manuelle pour les workflows critiques.
Ces écueils reviennent régulièrement en mission. Les identifier tôt évite de reconstruire un chantier déjà livré.
Synchroniser deux systèmes dans les deux sens par défaut, sans définir qui fait autorité.
Choisir un SaaS sans vérifier l'exportabilité des données, les API et le modèle de permissions.
Comparer un SaaS et un développement sur mesure sur le seul coût de la première année.
Laisser des applications sans owner : personne ne renouvelle, ne sécurise ni ne supprime.
Nous livrons l'inventaire applicatif et la matrice des sources de vérité avant toute intégration. C'est ce document qui permet ensuite de brancher n8n, une API ou un ERP sans créer de dépendances circulaires.
Une API expose des opérations qu'un autre système peut demander. Un webhook informe un système qu'un événement vient de se produire. Les deux se complètent, et toute action déclenchée par un webhook doit être idempotente.
Acheter un SaaS quand la capacité est standard et le marché mature, configurer une plateforme quand les écarts portent sur des règles et workflows, intégrer plusieurs produits quand aucun outil unique ne couvre le besoin, développer quand la capacité crée un avantage spécifique ou exige un contrôle particulier.
Le système qui fait autorité sur cette donnée : le CRM pour le statut d'une opportunité, l'ERP pour la facture, l'outil RH pour le contrat. Les autres systèmes en reçoivent une copie sans pouvoir la modifier librement.
Ce chapitre appartient au pilier « Construire un système fiable ». Architecture, données, infrastructure, automatisation, IA et cybersécurité : les capacités sur lesquelles reposent tous les usages métier.
Faire de la donnée un actif utile : types de données, qualité, gouvernance, tableaux de bord orientés décision et préparation de la donnée pour l'IA.
Lire le chapitre →Chapitre 6Socle techniqueChoisir une infrastructure proportionnée (IaaS/PaaS/SaaS), séparer les environnements, industrialiser avec CI/CD et l'observabilité, sans créer de dette d'exploitation.
Lire le chapitre →Chapitre 7Socle techniqueIdentifier les bons candidats à l'automatisation, choisir entre API, workflow, RPA ou agent IA, concevoir un workflow robuste et calculer son ROI réel.
Lire le chapitre →