Choisir une architecture de services

La coopérative fictive VéloPartage possède trois ateliers. Chaque site conserve son fichier de réservations et les versions se contredisent. La direction envisage un service commun, des outils répartis ou une offre d’informatique en nuage. Choisir une architecture ne consiste pas à retenir un mot à la mode : il faut préciser les besoins de partage, la disponibilité attendue, les compétences et les risques.

Dans une organisation centralisée, un service commun ou une autorité centrale assure une fonction pour plusieurs utilisateurs. Cela facilite la gestion des versions et l’application de règles communes. Cette centralisation peut être logique : plusieurs machines physiques peuvent fournir le même service. Un dessin avec un seul serveur ne suffit donc pas à compter les machines ou à prouver l’existence d’un point de panne unique.

Une organisation décentralisée confie des responsabilités à plusieurs sites ou acteurs. Des services peuvent être répartis et échanger des données. Cette proximité peut permettre à un atelier de continuer certaines opérations localement. Elle exige toutefois des règles de synchronisation et de résolution des conflits : que faire si deux sites réservent la dernière pièce avant de recevoir les changements de l’autre ?

Centralisé, distribué et décentralisé décrivent des aspects liés mais différents. La distribution concerne la répartition des composants ; la décentralisation concerne aussi les responsabilités et le contrôle. Une application distribuée peut dépendre d’un fournisseur central. Le choix doit être décrit par les fonctions et les échanges réels, plutôt que déduit du nombre de boîtiers visibles.

L’informatique en nuage fournit à la demande, par le réseau, des ressources configurables comme du calcul, du stockage ou des applications. Elle s’appuie notamment sur la mutualisation, l’ajustement rapide de ressources et la mesure de leur utilisation. Un simple accès à un fichier distant ne démontre pas à lui seul toutes ces caractéristiques. Un nuage privé peut utiliser un réseau interne ; le nuage ne se confond donc pas avec Internet.

Trois modèles de service aident à situer ce qui est fourni. En IaaS, infrastructure en service, le client utilise des ressources et gère notamment ses systèmes et applications selon le contrat. En PaaS, plateforme en service, il déploie ses applications sur un environnement géré. En SaaS, logiciel en service, il utilise une application fournie. Ces modèles n’effacent pas ses responsabilités sur les comptes, les droits et les données.

Le mode de déploiement répond à une autre question. Un nuage public propose ses services à un ensemble de clients ; les données de chaque client ne deviennent pas publiques pour autant. Un nuage privé est réservé à une organisation. Un nuage communautaire est partagé par des organisations ayant des besoins communs. Un nuage hybride relie des environnements distincts. Aucun de ces noms ne prouve à lui seul un niveau de sécurité.

L’élasticité permet d’adapter des ressources aux variations de la demande, dans les limites techniques et contractuelles. Elle ne rend pas la capacité infinie ou gratuite. Les dépenses peuvent dépendre des comptes, de la capacité, des traitements ou des échanges. Il faut comprendre la facturation, surveiller l’usage et prévoir la sortie du service. Un coût initial faible peut s’accompagner de dépenses récurrentes importantes.

La confidentialité limite l’accès aux personnes autorisées. L’intégrité vise à préserver les données des modifications indues. La disponibilité permet leur utilisation au moment nécessaire. Ces objectifs demandent des mesures complémentaires. Un mot de passe ne restaure pas un fichier supprimé ; une copie ne remplace pas le contrôle des autorisations. L’architecture doit être examinée à travers des risques concrets.

L’authentification vérifie l’identité présentée. L’autorisation décide de l’action permise sur une ressource. Un responsable d’atelier peut être autorisé à consulter les réservations sans administrer tous les comptes. Les droits doivent suivre les besoins professionnels et être revus lorsqu’une personne change de fonction. Les contrôles doivent s’appliquer au service qui traite la demande, pas seulement à l’affichage d’un bouton.

La répartition des responsabilités entre fournisseur et client dépend de l’offre. Même lorsqu’un fournisseur maintient l’application, le client peut encore créer des comptes trop puissants, publier un document au mauvais public ou oublier de retirer un accès. Il doit donc vérifier les engagements, les procédures et les preuves disponibles. Le stockage chez un prestataire ne transfère pas automatiquement toute responsabilité opérationnelle.

Une sauvegarde conserve un état permettant une restauration. Une réplication ou synchronisation peut recopier immédiatement une suppression ; elle ne remplace pas un historique protégé. Il faut distinguer la fréquence des copies, leur séparation du système actif et la durée nécessaire pour reprendre le service. La présence d’un fichier de sauvegarde ne prouve pas qu’il peut être restauré correctement.

Une chaîne de blocs organise des enregistrements en blocs liés par des empreintes cryptographiques. Plusieurs participants conservent et valident un registre selon des règles communes. Le lien entre blocs aide à détecter une modification de l’historique ; le mécanisme d’accord détermine comment une nouvelle écriture est acceptée. Les droits de participation et de validation dépendent du type de réseau.

Cette organisation peut être utile lorsque plusieurs acteurs doivent partager un registre sans confier tout son contrôle à un seul d’entre eux. Elle ajoute aussi des contraintes de gouvernance, de performance, de correction des erreurs et de confidentialité. Tous les dispositifs n’emploient pas le même mécanisme d’accord ni la même quantité de ressources. Une chaîne de blocs n’est pas synonyme de cryptomonnaie.

Le registre ne vérifie pas par magie un événement extérieur. Si un partenaire saisit une livraison qui n’a pas eu lieu, une inscription techniquement valide peut conserver cette déclaration fausse. Il faut donc vérifier l’origine et la qualité des données avant leur inscription. Pour VéloPartage, une base partagée sous une gouvernance acceptée peut suffire ; la chaîne de blocs demande une justification liée à un véritable besoin de confiance entre acteurs.

S’entraîner : retrouve le hub à l’adresse https://www.allostmg.fr/exercices.