Système d’information distribué : architecture, exemples et compromis

Un système d’information distribué stocke, traite ou fournit des informations au moyen de composants exécutés sur plusieurs ordinateurs en réseau. Il fait coopérer ces composants : un employé peut consulter un dossier client unique à l’écran, alors que les coordonnées, les commandes et les livraisons proviennent de systèmes distincts.

La difficulté consiste à définir le sens des informations réunies. Quelle source fait référence pour une adresse ? Quel retard peut-on accepter pour un état des stocks ? Que doit afficher l’application lorsqu’un service ne répond plus ? Ce guide présente l’architecture à partir d’un exemple de commerce, puis examine la cohérence, l’intégration, la sécurité et les situations où une conception plus simple suffit.

Qu’est-ce qu’un système d’information distribué ?

Un système d’information distribué répartit ses applications, ses services, ses données ou ses traitements entre des machines en réseau qui coopèrent pour répondre aux besoins d’utilisateurs ou d’autres systèmes. Ces machines peuvent se trouver dans un même bâtiment ou sur plusieurs sites. Leurs logiciels, leurs bases de données et les équipes responsables peuvent être différents.

Une interface commune peut réunir des informations sans tout déplacer dans une seule base. Elle doit néanmoins distinguer les sources de référence des copies, les résultats récents des données en cache, et les réponses complètes des résultats partiels. Un écran unifié ne signifie pas que tous les composants sous-jacents sont d’accord à chaque instant.

Un portail universitaire peut, par exemple, réunir le statut d’inscription, les cours choisis, les emprunts à la bibliothèque et les frais de scolarité. Chaque service conserve son application, tandis que les étudiants accèdent aux informations utiles depuis le portail.

Systèmes d’information distribués et notions voisines

Systèmes distribués et calcul distribué

Un système distribué désigne plus largement des composants en réseau qui coordonnent leur travail. Le calcul distribué porte sur la répartition des calculs entre les machines. Un système d’information distribué met l’accent sur le stockage, l’interprétation, le partage et la mise à jour des informations entre ces composants.

Ces catégories se recoupent. Une plateforme de commandes effectue des calculs distribués tout en gérant des informations. Un cluster de simulation peut surtout répartir des calculs entre ses nœuds. La distinction permet de préciser le problème de conception ; elle ne classe pas tous les logiciels dans des catégories exclusives.

Bases de données distribuées

Une base de données distribuée gère une base logique sur plusieurs nœuds, grâce au partitionnement, à la réplication ou aux deux. Elle peut constituer un composant d’un système d’information distribué. L’ensemble comprend aussi la logique applicative, les identités, les interfaces et l’intégration avec d’autres sources.

Plusieurs services peuvent disposer chacun d’une base centralisée et former un système d’information distribué lorsque leurs applications coopèrent par le réseau. L’adoption d’une base distribuée ne résout pas les différences entre leurs identifiants clients ou leurs règles de responsabilité.

Fédération et décentralisation

La fédération permet à des systèmes gérés indépendamment de coopérer en conservant une certaine autonomie locale. Un réseau de bibliothèques peut proposer une recherche commune alors que chaque établissement maintient son catalogue. Les participants doivent s’accorder sur les interfaces, les autorisations et le sens des champs partagés.

La décentralisation concerne la répartition de l’autorité. Une entreprise peut exploiter un système d’information réparti sur plusieurs régions tout en gardant un contrôle central. Notre article sur les systèmes distribués et décentralisés détaille cette distinction.

Cloud computing

Le cloud computing permet d’obtenir des ressources informatiques et des logiciels sous forme de services. Il constitue un choix de déploiement, pas une condition nécessaire à un système d’information distribué. Les composants peuvent fonctionner sur site, dans un cloud public ou dans un environnement hybride.

Les bases de données gérées, les files de messages et le stockage cloud peuvent réduire le travail d’exploitation de l’infrastructure. Les équipes applicatives restent responsables des règles qui définissent l’autorité sur les données, leur interprétation et leur mise à jour.

Architecture et principaux composants

Les couches suivantes décrivent des responsabilités. Elles n’imposent pas six produits ou équipes distincts.

• Présentation : les applications web, les applications mobiles et les interfaces partenaires affichent les informations et reçoivent les demandes. Elles doivent rendre visibles les résultats manquants ou périmés.
• Services applicatifs : la gestion des commandes, la facturation, la recherche et les autres fonctions métier appliquent les règles et coordonnent les opérations.
• Stockage des données : bases de données, stockage objet, systèmes de fichiers et applications métier conservent les enregistrements. Leurs schémas et politiques de conservation peuvent différer.
• Intégration : API, appels de procédure à distance, files de messages, flux d’événements et pipelines de données transmettent les demandes ou les changements entre composants.
• Métadonnées et découverte : catalogues et registres décrivent l’emplacement des informations, le sens des champs, les responsables et les versions d’interface prises en charge.
• Identités et contrôle d’accès : les identités des utilisateurs et des services, les politiques d’autorisation et les journaux d’audit encadrent les accès entre systèmes.

Ces responsabilités peuvent s’inscrire dans plusieurs modèles. Dans une architecture client-serveur, les clients demandent des informations aux serveurs. Une architecture à plusieurs niveaux sépare présentation, logique applicative et stockage. Les architectures orientées services ou fondées sur des microservices divisent les fonctions métier ; leur souplesse de déploiement s’accompagne d’un travail sur les interfaces et la coordination.

Une architecture fédérée relie des systèmes qui conservent une gestion indépendante. Les systèmes pair à pair permettent aux participants de fournir et de consommer directement des informations, même si la découverte des pairs ou l’identité peut dépendre de services centraux. Aucun de ces modèles ne garantit à lui seul la tolérance aux pannes ou la cohérence des données.

Fonctionnement : une demande dans le commerce

Prenons un distributeur fictif. Les profils clients se trouvent dans un CRM, les commandes dans un service dédié, les stocks dans des systèmes régionaux et les statuts de paiement dans un autre service. Un conseiller doit vérifier une commande et organiser un remplacement.

1. Vérifier les autorisations. L’application authentifie le conseiller et contrôle son accès au dossier client. Les services sollicités appliquent les autorisations pertinentes avant de renvoyer des données protégées.
2. Identifier les sources de référence. Le CRM fait référence pour les coordonnées, le service de commandes pour leur état, et chaque service d’inventaire pour les stocks de ses entrepôts.
3. Demander les informations nécessaires. Les lectures indépendantes peuvent s’exécuter en parallèle. Chaque appel a un délai maximal, et l’application ne demande que les champs utiles à la tâche.
4. Relier les identifiants et les définitions. La couche d’intégration associe l’identifiant client du CRM à celui du compte dans les commandes. Le stock est identifié par produit et entrepôt, avec des unités et des définitions communes.
5. Évaluer l’ancienneté et les données manquantes. L’application relève quand chaque résultat a été obtenu et s’il provient de la source ou d’un cache. Un entrepôt indisponible apparaît avec un stock inconnu, et non nul.
6. Présenter la vue d’ensemble. Le conseiller voit la commande et les informations disponibles, avec un avertissement clair si certains résultats manquent ou sont trop anciens pour prendre une décision.
7. Confirmer les changements à la source. Avant de promettre un remplacement, l’application demande au service d’inventaire compétent de réserver le stock. La quantité affichée auparavant ne suffit pas à confirmer la disponibilité.

Deux entrepôts qui annoncent des quantités différentes décrivent généralement des enregistrements différents. Retenir uniquement le plus récent ferait perdre de l’information. Si deux copies du même enregistrement d’entrepôt se contredisent, il faut une règle explicite de version ou de résolution des conflits. Un horodatage ne détermine pas, à lui seul, quel événement métier doit prévaloir.

Intégration, schémas et responsabilité des données

Le réseau transporte des octets. L’intégration les rend utilisables. Une application peut définir un client comme une personne, une autre comme un compte de facturation et une troisième comme un foyer. Faire correspondre les noms de champs ne suffit pas si les concepts diffèrent.

Documentez les identifiants, les unités, les champs obligatoires et les définitions métier à chaque interface. Précisez la différence entre une valeur absente et zéro, la résolution des doublons et le comportement attendu lorsqu’une source ajoute ou supprime un champ. La gestion des versions et les contrôles de compatibilité aident les applications consommatrices à supporter les changements d’une autre équipe.

La responsabilité doit être précise. Le service client peut gérer le contact de livraison, tandis que la finance contrôle l’adresse de facturation. Une vue client commune peut afficher les deux sans inventer une adresse universelle. Chaque donnée importante doit avoir un responsable capable de trancher les désaccords.

Requêtes directes, événements et vues préparées

Une requête API peut récupérer l’information au moment du besoin, mais l’utilisateur dépend alors du temps de réponse et de la disponibilité de la source. Les événements propagent les changements de façon asynchrone et permettent aux destinataires de maintenir des copies locales ; celles-ci peuvent prendre du retard et nécessitent une reprise après un traitement manqué ou en échec. Les traitements par lots peuvent convenir aux rapports qui n’exigent pas l’état opérationnel courant.

Une vue matérialisée conserve une représentation préparée pour une requête particulière. Dans notre exemple, il pourrait s’agir d’un récapitulatif de commande construit à partir de plusieurs services. Cette approche peut accélérer la lecture, mais il faut définir son actualisation, le retard acceptable et sa reconstruction.

Un même système peut combiner ces approches. Un rapport quotidien de ventes, un tableau de suivi du support et une réservation de stock n’exigent pas la même fraîcheur. Les traiter de manière identique peut gaspiller des ressources ou conduire à des décisions incorrectes.

Cohérence, réplication et transactions

Réplication et partitionnement répondent à des besoins différents

La réplication conserve des copies des mêmes données sur plusieurs nœuds. Le partitionnement les divise, par exemple selon l’identifiant de compte ou la région. Un système peut partitionner ses enregistrements pour augmenter sa capacité et répliquer chaque partition pour résister à certaines pannes.

Les copies sont utiles si leur emplacement et leur comportement de reprise correspondent aux pannes envisagées. Trois réplicas sur un même hôte ne protègent pas contre la panne de cet hôte. La réplication peut aussi propager une suppression accidentelle ou une corruption ; elle ne remplace donc pas des sauvegardes indépendantes et testées.

Définir la cohérence pour chaque opération

La cohérence des données décrit les garanties offertes aux lectures et aux écritures. Dans un modèle linéarisable, les opérations se comportent comme si elles avaient lieu sur une copie unique à jour, dans un ordre compatible avec le temps réel. La cohérence éventuelle accepte des différences temporaires : les réplicas convergent lorsque les mises à jour cessent et que leur propagation s’achève.

Les garanties de session peuvent permettre à un utilisateur de relire ses propres modifications. Cela ne signifie pas que les autres utilisateurs les voient immédiatement. Vérifiez les garanties réelles de la base ou du service au lieu de supposer que le mot « cohérent » possède un sens universel.

Le théorème CAP concerne la cohérence et la disponibilité lors d’une partition réseau. Lorsque les nœuds ne peuvent plus communiquer, un système ne peut garantir à la fois des résultats linéarisables et une réponse à chaque requête dans le modèle du théorème. Une réservation peut attendre ou échouer, tandis qu’une page informative affiche un résultat plus ancien clairement signalé.

Coordonner les changements entre services

Une commande peut mobiliser l’inventaire, le paiement et l’expédition. Si ces fonctions utilisent des stockages distincts, la réussite d’une transaction locale ne prouve pas que toute l’opération métier a réussi.

Certains systèmes emploient des transactions distribuées lorsque leurs composants permettent la coordination nécessaire. D’autres utilisent une saga de transactions locales et d’actions compensatoires. Dans un exemple de commande, l’échec du paiement pourrait déclencher la libération du stock réservé. La compensation est une action métier : elle peut échouer, nécessiter une intervention ou ne pas pouvoir annuler complètement ce qui s’est passé.

Pannes partielles et répétition des requêtes

Un système d’information distribué peut fonctionner partiellement. Le service de commandes répond alors que celui d’inventaire dépasse son délai maximal. L’application doit prévoir quoi faire pour chaque dépendance indisponible : fournir des informations partielles, utiliser un cache acceptable ou arrêter l’opération.

Un délai dépassé laisse le résultat incertain. Un paiement ou une réservation peut avoir réussi sans que sa réponse arrive. Répéter aveuglément la demande peut reproduire son effet. Les API idempotentes permettent d’identifier les nouvelles tentatives d’une même opération afin que le service évite de répéter ses effets.

Limitez les tentatives et espacez-les progressivement ; distinguez les pannes temporaires des requêtes invalides. Conservez assez d’informations sur l’opération pour rapprocher les résultats incertains. Testez les réponses retardées, les événements dupliqués et les dépendances indisponibles, au-delà du seul parcours de réussite.

Sécurité, contrôle d’accès et observabilité

Chaque connexion entre systèmes pose une question de confiance. L’authentification établit l’identité qui émet une demande ; l’autorisation détermine ce qu’elle peut faire. Appliquez les permissions à la frontière du service ou des données, sans vous contenter de masquer des champs à l’écran.

Utilisez des connexions chiffrées, protégez les données stockées et limitez les privilèges des identifiants de service. Définissez quelles informations peuvent franchir les frontières organisationnelles ou régionales, y compris les sauvegardes, les journaux et les copies analytiques. La répartition physique ne garantit ni la conformité ni la confidentialité.

La supervision doit suivre les flux d’information importants. Vérifiez que les commandes atteignent le service d’expédition, mesurez l’ancienneté des vues de stock et le nombre de messages en attente. Un serveur peut fonctionner correctement tout en fournissant des données périmées.

Le traçage distribué relie les opérations entre services grâce au contexte de trace et aux segments, ou « spans ». Combinez-le aux journaux et aux métriques pour examiner les retards et les appels en échec. Les identifiants de corrélation et les relations causales aident à reconstituer une demande ; les horodatages seuls ne fournissent pas un historique global parfaitement ordonné. Évitez de copier des données sensibles dans les diagnostics.

Exemples de systèmes d’information distribués

Ces architectures illustratives montrent pourquoi l’intégration de l’information compte :

• Services universitaires : admissions, inscriptions, bibliothèque et finance alimentent un portail étudiant. Un identifiant commun et des règles d’accès précises relient des dossiers qui restent sous la responsabilité de services différents.
• Chaîne d’approvisionnement : un fabricant réunit les confirmations de fournisseurs, les stocks et les mises à jour des transporteurs. L’application distingue une livraison prévue d’une réception confirmée et indique la dernière actualisation des informations du partenaire.
• Commerce : le parcours de support présenté plus haut réunit les informations de compte et de commande, tandis que les réservations restent contrôlées par le système responsable du stock.

L’architecture de l’annuaire Microsoft Entra ID fournit un exemple documenté au niveau des données. Elle utilise le partitionnement et la réplication, avec un traitement principal des écritures et des réplicas secondaires pour les lectures. La propagation asynchrone influence le moment où les mises à jour deviennent visibles. Une organisation qui relie cet annuaire à ses applications RH et métier doit encore définir ses propres responsabilités et règles de mise à jour.

Avantages, compromis et critères de choix

La distribution peut être utile lorsque les informations appartiennent déjà à des systèmes distincts, que les composants ont des besoins de capacité différents ou que les utilisateurs et les sources sont géographiquement dispersés. Elle peut préserver une responsabilité locale et permettre de remplacer un composant sans remplacer toutes les applications.

Ces avantages ont un coût. Les dépendances réseau ajoutent de la latence et des pannes partielles à gérer. Les copies nécessitent un suivi de leur fraîcheur et des rapprochements. Les versions indépendantes exigent des interfaces compatibles, et les équipes d’exploitation doivent voir au-delà de chaque composant. Ajouter des machines ne garantit pas de meilleures performances, des coûts inférieurs ou une disponibilité supérieure.

Avant d’adopter une architecture distribuée, répondez à cinq questions :

1. Quelles informations doivent rester sous une responsabilité distincte, et pourquoi ?
2. Quelle source fait référence pour chaque enregistrement ou champ important ?
3. Quel retard est acceptable pour chaque résultat, et quelles opérations doivent s’arrêter si leur exactitude est incertaine ?
4. Comment détecter, reprendre et rapprocher les opérations en échec ou répétées ?
5. Qui maintiendra les interfaces, résoudra les désaccords sur les données et exploitera le système ?

Si une application et une base bien gérée répondent aux besoins, elles peuvent être plus faciles à construire et à maintenir. Introduisez la distribution lorsqu’elle résout un problème précis de responsabilité, d’intégration, de localisation ou de capacité.

Questions fréquentes

Un système d’information distribué peut-il avoir un serveur central ?

Oui. Un portail central, un service d’identité ou un coordinateur peut travailler avec des données et des services exécutés ailleurs. Examinez son comportement en cas de panne et son plan de reprise : le terme « distribué » ne supprime pas les dépendances centrales.

Faut-il copier toutes les données partout ?

Non. Certains systèmes interrogent les données à leur emplacement d’origine, d’autres copient certains champs ou répliquent des partitions. Chaque copie doit répondre à un besoin précis, avec des règles d’accès, de conservation et de fraîcheur définies.

Les microservices sont-ils nécessaires ?

Non. Un serveur applicatif classique qui intègre des bases indépendantes et des services partenaires peut former un système d’information distribué. Les microservices constituent une façon de répartir les responsabilités, avec leurs propres coûts d’exploitation.

Par où commencer la conception ?

Choisissez un parcours utilisateur réel et cartographiez les informations nécessaires. Identifiez les responsables, les droits d’accès, les limites de fraîcheur et les conséquences des pannes avant de choisir les bases ou les outils de messagerie. Vous pourrez ainsi préciser les décisions que l’architecture doit prendre en charge.