Un site web n'est pas seulement un outil de communication. C'est aussi un ensemble de droits, d'accès, de données et de dépendances. Quand tout va bien, on n'y pense pas. Quand quelque chose se dégrade — prestataire qui disparaît, contrat qui expire, relation qui se dégrade, tarifs qui explosent —, on réalise qu'on n'a peut-être pas la maîtrise qu'on croyait avoir.

La réversibilité numérique, c'est la capacité à changer de prestataire, à reprendre son site, à récupérer ses données et à continuer à fonctionner sans dépendre d'une seule entité. Ce n'est pas un concept abstrait. C'est une question concrète que toute organisation devrait être capable de répondre.

Les sept questions de la réversibilité

1. Qui détient le nom de domaine ?

Le nom de domaine est l'adresse de votre organisation sur internet. Il est déposé auprès d'un bureau d'enregistrement (registrar). La question n'est pas de savoir chez quel registrar il est hébergé, mais qui en est le titulaire déclaré et qui a accès à la gestion.

Si votre prestataire a déposé votre nom de domaine en son propre nom, ou si vous n'avez pas accès à l'interface de gestion, vous ne maîtrisez pas votre adresse numérique. Un changement de prestataire peut devenir un bras de fer juridique.

Ce qu'il faut vérifier : Connectez-vous à la base WHOIS (who.is ou whois.domaintools.com) avec votre nom de domaine. Le titulaire doit être votre organisation, pas votre prestataire.

2. Qui a accès à l'hébergement ?

L'hébergement est le serveur qui stocke les fichiers de votre site. Si vous ne connaissez pas l'hébergeur, si vous n'avez pas de compte propre chez lui, ou si votre prestataire est le seul à pouvoir intervenir sur le serveur, vous êtes dépendant.

Ce qu'il faut vérifier : Avez-vous un accès direct à l'interface de gestion de l'hébergement (cPanel, Plesk, interface spécifique) ? Pouvez-vous télécharger les fichiers de votre site sans passer par votre prestataire ?

3. Où est le code source de votre site ?

Un site web est constitué de fichiers : templates, fichiers de configuration, code personnalisé, thème. Si ces fichiers ne sont stockés que chez votre prestataire, vous ne pouvez pas les remettre à quelqu'un d'autre pour reprendre votre site.

Un dépôt Git (GitHub, GitLab, Bitbucket, ou une instance auto-hébergée) est la solution standard. Il permet de versionner le code, de le partager et de le transférer facilement.

Ce qu'il faut vérifier : Avez-vous accès au dépôt Git de votre site ? Êtes-vous propriétaire du dépôt, ou seulement collaborateur ?

4. Vos sauvegardes sont-elles indépendantes ?

Les sauvegardes doivent exister, être régulières, et être stockées dans un endroit auquel vous avez accès — pas seulement chez votre prestataire.

Une sauvegarde chez un prestataire qui disparaît ou qui rompt le contrat n'est pas une sauvegarde utilisable. Une sauvegarde que vous n'avez jamais testée peut s'avérer corrompue le jour où vous en avez besoin.

Ce qu'il faut vérifier : Qui effectue les sauvegardes ? À quelle fréquence ? Où sont-elles stockées ? Avez-vous déjà testé une restauration ?

5. Pouvez-vous exporter votre contenu ?

Le contenu de votre site — textes, images, pages, articles — doit pouvoir être exporté dans un format exploitable. Si votre site est construit sur un CMS propriétaire fermé, ou si votre prestataire ne vous fournit pas les outils d'export, vous risquez de repartir de zéro en cas de changement.

Les CMS open source (Drupal, WordPress, TYPO3) offrent généralement de bonnes capacités d'export. Les solutions propriétaires, notamment les constructeurs de sites en marque blanche, verrouillent souvent le contenu dans leur environnement.

Ce qu'il faut vérifier : Pouvez-vous exporter l'intégralité du contenu de votre site (pages, articles, médias, utilisateurs) dans un format ouvert (JSON, XML, CSV) ?

6. La documentation existe-t-elle ?

Un site non documenté est un site difficile à reprendre. Si votre prestataire est le seul à savoir comment le site est construit, quels modules sont installés, comment les mises à jour doivent être effectuées — vous dépendez de sa mémoire et de sa disponibilité.

Une documentation minimale comprend : la liste des technologies utilisées, les identifiants d'accès (stockés de façon sécurisée), les procédures de mise à jour, les contacts des différents fournisseurs.

Ce qu'il faut vérifier : Disposez-vous d'un document qui vous permettrait de confier votre site à un nouveau prestataire sans appeler l'ancien ?

7. Les licences vous appartiennent-elles ?

Si votre site utilise un thème graphique, des plugins ou des composants sous licence commerciale, vérifiez que ces licences sont à votre nom et transférables. Certains prestataires achètent des licences en leur nom, ce qui crée une dépendance supplémentaire.

Les signes d'une dépendance problématique

Voici des situations concrètes qui révèlent une dépendance numérique excessive :

  • Vous ne connaissez pas votre hébergeur et n'avez jamais eu de contact avec lui.
  • Votre prestataire ne vous a jamais communiqué vos identifiants d'accès complets.
  • Le nom de domaine a été déposé par votre prestataire et « vous appartient de facto ».
  • Votre contrat ne mentionne pas la propriété des fichiers, du code ou du contenu.
  • Vous avez demandé une sauvegarde à votre prestataire et n'en avez jamais reçu.
  • Votre site utilise un outil propriétaire que seul votre prestataire sait configurer.
  • Vous n'avez aucune visibilité sur les mises à jour réalisées ni sur leur fréquence.

Aucune de ces situations ne signifie nécessairement que votre prestataire est de mauvaise foi. Beaucoup résultent simplement d'un manque de formalisation au départ. Mais elles créent une dépendance réelle qui peut devenir bloquante.

Pourquoi la réversibilité est aussi un enjeu de sécurité

La réversibilité ne protège pas seulement contre un changement de prestataire. Elle protège aussi contre les incidents :

  • Disparition du prestataire : faillite, cessation d'activité, départ à la retraite sans transmission.
  • Perte d'accès : conflit commercial, impayé, prestataire injoignable.
  • Incident technique : hébergement indisponible, données corrompues, piratage.
  • Évolution réglementaire : obligation de changer d'hébergeur (données sensibles, cloud souverain).

Dans tous ces cas, une organisation qui maîtrise ses accès, dispose de sauvegardes indépendantes et a une documentation à jour peut rebondir rapidement. Une organisation dépendante subit la situation passivement.

Le cas particulier des sites Drupal

Drupal est un CMS open source, ce qui est un avantage structurel pour la réversibilité : le code source est public, les formats d'export sont standardisés, et n'importe quel prestataire Drupal compétent peut reprendre un site existant.

Mais cette réversibilité théorique n'est pas automatique. Un site Drupal peut être difficile à reprendre si :

  • le code custom n'est pas documenté ni versionné dans un dépôt Git ;
  • les mises à jour n'ont pas été faites depuis longtemps (dette technique) ;
  • les configurations ne sont pas exportées en CMI (Configuration Management Interface) ;
  • le contenu n'est pas exporté via default_content ou équivalent ;
  • des modules contrib personnalisés ont été développés sans documentation.

À l'inverse, un site Drupal bien maintenu — code versionné, configuration exportée, contenu sauvegardé, documentation à jour — est l'un des plus faciles à transférer.

Ce que doit contenir un contrat de prestataire web

Un contrat de prestataire web qui protège réellement le client doit préciser :

  • la propriété du code source développé spécifiquement pour le client ;
  • la liste des accès à remettre en fin de contrat (hébergement, nom de domaine, CMS, dépôt Git) ;
  • les modalités de sauvegarde et leur fréquence ;
  • les conditions de réversibilité et le délai de transfert ;
  • la documentation technique à fournir ;
  • les licences utilisées et leur titulaire.

En l'absence de ces clauses, la réversibilité dépend de la bonne volonté du prestataire.

Une démarche en quatre étapes

Étape 1 — Inventaire : lister tous les composants de votre présence numérique (nom de domaine, hébergement, CMS, outils tiers, emails, formulaires, analytics).

Étape 2 — Vérification des accès : pour chaque composant, vérifier que vous disposez d'un accès direct et indépendant, ou identifier qui le détient.

Étape 3 — Audit des contrats : vérifier les contrats en cours (hébergement, prestataire web, logiciels SaaS) pour identifier les clauses de réversibilité ou leur absence.

Étape 4 — Plan de remédiation : prioriser les actions à engager — récupération des accès, mise en place de sauvegardes indépendantes, demande de documentation, régularisation des licences.

À retenir

La réversibilité numérique n'est pas un luxe réservé aux grandes organisations. C'est une condition de base de l'autonomie numérique pour toute structure qui dépend d'un site web pour fonctionner, communiquer ou servir ses usagers.

Elle ne demande pas de tout changer. Elle demande de savoir où sont les clés.

Comment Stoelabs peut aider

Stoelabs propose un audit de réversibilité web pour les collectivités, associations, TPE et PME :

  • inventaire des composants numériques (domaine, hébergement, CMS, outils) ;
  • vérification des accès et de leur indépendance ;
  • analyse de la documentation existante ;
  • revue des contrats prestataires ;
  • rapport avec niveau de réversibilité et recommandations priorisées ;
  • accompagnement pour la reprise en main progressive.

Vous souhaitez savoir si vous maîtrisez réellement votre site web ? Commençons par un audit de réversibilité.

Demander un audit →

Sources

  1. CNIL — Sous-traitance et responsabilité des prestataires — Obligations des prestataires traitant des données personnelles pour le compte de leurs clients.
  2. ANSSI — Guide de l'hygiène informatique — Bonnes pratiques incluant la gestion des accès et des sauvegardes.
  3. Cybermalveillance.gouv.fr — Baromètre 2025 de maturité cyber des TPE-PME — État des pratiques numériques dans les petites structures.
  4. DINUM / code.gouv.fr — Pôle open source et communs numériques — Arguments pour la réversibilité via l'open source dans les administrations.
  5. ANCT — L'open source, un atout clé pour les collectivités — Janvier 2026.