L’externalisation cloud consiste à confier à un prestataire externe une partie de l’infrastructure informatique, des applications, du stockage ou des opérations techniques nécessaires au fonctionnement d’un système d’information. Les ressources sont accessibles par un réseau et reposent sur des équipements administrés hors des locaux de l’organisation utilisatrice.
Cette démarche ne correspond pas uniquement au déplacement de fichiers vers un espace en ligne. Elle peut concerner une base de données, un serveur applicatif, une messagerie, une plateforme de sauvegarde, un environnement de développement ou encore la supervision de postes et de réseaux. Le niveau de responsabilité transféré dépend du modèle retenu et du contrat signé.
Trois modèles sont souvent distingués :
Dans chacun de ces cas, l’externalisation ne supprime pas les responsabilités. La gestion opérationnelle peut être confiée à un tiers, mais l’organisation doit continuer à maîtriser ses accès, ses données, ses obligations réglementaires et la continuité de ses activités.
Le cloud peut répondre à plusieurs contraintes concrètes. Une structure qui souhaite éviter l’achat et le renouvellement d’un serveur local peut louer des ressources adaptées à son usage. Une équipe informatique réduite peut également rechercher des services supervisés, des mécanismes de sauvegarde ou une capacité de déploiement plus souple.
Les bénéfices potentiels sont les suivants :
Ces avantages doivent être évalués avec prudence. Le coût d’un service cloud inclut parfois la consommation de stockage, les transferts de données, les comptes utilisateurs, les options de sauvegarde, le support et les opérations de sortie. Une facture prévisible dépend donc d’un périmètre défini et d’un suivi régulier des usages.
L’externalisation ne constitue pas non plus une stratégie de sécurité en elle-même. Un service hébergé peut bénéficier de protections avancées, mais une configuration incorrecte, un compte compromis ou une autorisation trop large peuvent exposer les données. La qualité du projet dépend autant de la gouvernance et des réglages que de la technologie choisie.
La question centrale d’un projet cloud est celle de la responsabilité partagée. Le prestataire peut protéger ses centres de données, son matériel, son réseau interne et la couche technique qu’il exploite. Le client conserve souvent la responsabilité des comptes, des rôles, des données, des paramètres de partage et d’une partie des systèmes installés au-dessus du service.
La répartition varie selon le modèle. Dans un service d’infrastructure, le client doit généralement maintenir les systèmes invités, les applications, les correctifs et les règles d’accès. Dans un logiciel en ligne, le fournisseur administre davantage de composants, mais le client reste responsable de la gestion des utilisateurs, du contenu stocké et des usages autorisés.
Avant toute migration, il est utile de dresser une matrice de responsabilités. Pour chaque élément, elle précise qui installe, qui configure, qui surveille, qui sauvegarde, qui corrige et qui intervient en cas d’incident. Cette matrice doit couvrir notamment :
Une responsabilité qui n’est attribuée à personne devient un angle mort. La matrice doit donc être annexée à la documentation du projet et révisée après chaque évolution importante.
Toutes les données ne présentent pas le même niveau de sensibilité. Un inventaire préalable permet de séparer les documents publics, les données internes, les informations personnelles, les secrets commerciaux, les identifiants techniques et les données dont la perte interromprait une activité.
Pour chaque catégorie, il faut déterminer plusieurs propriétés :
La CNIL recommande de prendre en compte la protection des données dès la conception des traitements. Cette approche conduit à limiter les informations transférées, à définir les personnes autorisées et à documenter les mesures de sécurité. Une analyse d’impact relative à la protection des données peut être nécessaire lorsque le traitement présente un risque élevé pour les personnes concernées.
Il est également pertinent de repérer les dépendances cachées. Une application peut utiliser une base de données, un service d’authentification, une tâche planifiée, une adresse réseau fixe ou un partage de fichiers. Migrer le serveur principal sans inventorier ces éléments crée des interruptions difficiles à diagnostiquer.
Le choix entre cloud public, cloud privé ou approche hybride dépend des exigences techniques, de la sensibilité des données et des compétences disponibles. Un cloud public mutualise certaines ressources entre plusieurs clients, avec une séparation logique et des mécanismes d’isolation. Un cloud privé est réservé à une organisation ou à un périmètre défini, mais il peut être exploité dans un centre de données externe ou dans les locaux. Une architecture hybride associe plusieurs environnements et nécessite une interconnexion maîtrisée.
Le tableau suivant résume les principaux compromis :
| Modèle | Atout principal | Point de vigilance |
|---|---|---|
| Cloud public | Large choix de services et capacité d’évolution | Configuration des accès, maîtrise des coûts et dépendance à l’écosystème |
| Cloud privé | Contrôle renforcé de l’environnement dédié | Coûts d’exploitation et compétences nécessaires |
| Approche hybride | Répartition des charges selon les contraintes | Complexité des réseaux, des identités et des sauvegardes |
| Service SaaS | Administration applicative réduite | Portabilité des données et limites de personnalisation |
La décision doit partir des besoins et non du vocabulaire commercial. Il faut notamment vérifier les interfaces disponibles, les formats d’export, les mécanismes d’authentification, les limites de capacité, les options de journalisation et les conditions d’assistance.
Un cahier des charges utile décrit des exigences observables. Une formule générale comme sécurité renforcée ne permet pas de comparer des solutions. Il vaut mieux demander quelles méthodes d’authentification sont disponibles, quels journaux peuvent être exportés, quelles sauvegardes sont réalisées et comment une restauration est testée.
Le document peut être organisé autour des rubriques suivantes :
Les documents de sécurité du prestataire peuvent apporter des éléments, mais une certification ne remplace pas l’analyse du service réellement utilisé. Il faut vérifier le périmètre couvert, la date du document et les contrôles qui concernent effectivement l’offre retenue. Les recommandations de l’ANSSI et les référentiels de la famille ISO 27000 fournissent des repères pour structurer cette évaluation.
Une migration progressive limite les conséquences d’une erreur et permet de valider les hypothèses techniques. Une démarche opérationnelle peut suivre les étapes ci-dessous :
Après la bascule, une période d’observation doit être planifiée. Les erreurs de droits, les temps de réponse inhabituels et les flux oubliés apparaissent parfois seulement lorsque l’activité reprend dans des conditions normales.
La gestion des identités constitue un point de contrôle majeur. Chaque utilisateur doit disposer d’un compte individuel, avec des droits correspondant à sa fonction. Les comptes partagés rendent les investigations plus difficiles et compliquent le retrait d’un accès lorsqu’une personne change de rôle.
Les mesures prioritaires comprennent :
Le chiffrement réduit les conséquences d’un accès non autorisé, mais il ne remplace pas le contrôle des permissions. Il faut aussi savoir qui détient les clés, comment elles sont renouvelées et ce qui se passe si une clé est perdue ou révoquée.
Les sauvegardes doivent être isolées des comptes d’administration ordinaires. Une sauvegarde accessible avec les mêmes identifiants que le système principal peut être affectée par un incident touchant ces comptes. Des tests de restauration planifiés permettent de vérifier que les fichiers sont exploitables et que les délais correspondent aux besoins réels.
Le contrat doit décrire le service utilisé, les niveaux d’assistance, les responsabilités et les procédures d’incident. Les engagements de disponibilité doivent être lus avec leurs exclusions : maintenance planifiée, défaillance d’un accès internet local, mauvaise configuration du client ou événement hors périmètre peuvent être traités différemment.
La réversibilité mérite une attention particulière avant la signature. Elle doit répondre à des questions concrètes :
La portabilité ne se résume pas à télécharger un fichier. Une base de données exportée dans un format propriétaire peut être inutilisable sans le logiciel qui l’a produite. Un test d’export et de réimport, réalisé avant une dépendance forte au service, apporte une information bien plus fiable qu’une clause générale.
L’externalisation déplace une partie de l’exploitation, sans supprimer le besoin de pilotage. Un tableau de suivi peut regrouper les incidents, les alertes de sécurité, les comptes actifs, les consommations, les sauvegardes réussies et les résultats des restaurations.
Une revue régulière doit porter sur les points suivants :
Un exercice de crise peut simuler une indisponibilité, une compromission de compte ou une suppression accidentelle. Il doit préciser les actions, les contacts, les décisions et les preuves à conserver. L’objectif est de vérifier la capacité à réagir, pas de démontrer qu’aucun incident ne peut se produire.
Plusieurs erreurs reviennent dans les projets mal préparés. La première consiste à migrer sans inventaire complet. Les applications oubliées et les flux non documentés créent des interruptions après la bascule. La deuxième consiste à confondre hébergement et sauvegarde. Une copie dans le même environnement que les données principales ne protège pas contre tous les scénarios.
Une autre erreur consiste à accorder des droits d’administrateur pour gagner du temps. Cette pratique augmente l’impact potentiel d’un compte compromis et rend les actions difficiles à attribuer. La conservation de comptes de secours non surveillés présente également un risque important.
Il faut aussi éviter de comparer uniquement le prix affiché. Les frais de transfert, de stockage supplémentaire, de support, de journalisation et de reprise peuvent modifier le coût global. Une estimation pertinente décrit plusieurs scénarios d’usage et inclut une hypothèse de sortie.
Enfin, une migration ne doit pas être considérée comme terminée le jour de la bascule. Les réglages, les droits et les procédures évoluent avec l’organisation. La documentation, les tests et les revues d’accès doivent accompagner toute la durée de vie du service.
Non. Une architecture peut conserver certaines données sur site et en transférer d’autres vers un service externe. La décision dépend des exigences de sécurité, des performances, des contraintes réglementaires et des dépendances entre applications.
La réponse dépend de la cause, du contrat et du cadre juridique applicable. Une mauvaise configuration des droits peut relever du client, tandis qu’une défaillance d’un composant exploité par le prestataire peut relever de sa responsabilité. La matrice de responsabilités et les clauses d’incident doivent préciser les rôles de chacun.
Non. Il faut connaître la fréquence des copies, leur durée de conservation, leur isolation, leur localisation et la procédure de restauration. Un test régulier est nécessaire pour vérifier que la sauvegarde permet réellement de récupérer les données et les paramètres utiles.
Il est possible de documenter l’architecture, de choisir des formats d’export exploitables, de tester les restaurations, de conserver les informations de configuration et de prévoir un environnement de reprise. La réversibilité doit être étudiée avant la migration, puis vérifiée périodiquement.
Une migration par étapes permet de limiter le risque. Un pilote, des critères de validation et une procédure de retour arrière donnent davantage de contrôle qu’une bascule globale réalisée sans test préalable.
L’externalisation cloud consiste à confier à un prestataire externe une partie de l’infrastructure informatique, des applications, du stockage ou des opérations techniques nécessaires au fonctionnement d’un syst...
L’externalisation des données consiste à confier à un prestataire extérieur tout ou partie de la conservation, de l’hébergement, de la sauvegarde ou du traitement d’informations num...
Passer une PME au logiciel libre ne consiste pas à remplacer tous les programmes le même jour. Cette approche provoquerait des incompatibilités, des interruptions de travail et une forte...
Un logiciel libre n’est pas un logiciel dépourvu de règles. Son auteur conserve ses droits d’auteur et choisit d’accorder certaines libertés au moyen d...
Un programme peut être gratuit, donner accès à son code ou autoriser sa modification. Ces caractéristiques sont souvent associées dans les conversations courantes, alors qu’elles répondent...
La formation continue en technologie de l'information (TI) est un processus d'apprentissage continu qui permet aux professionnels de la TI de rester à jour sur les derniè...