« Vous nous dites que l'hébergement est sécurisé et conforme. Concrètement, qui est responsable de quoi le jour où il y a un incident, et qu'est ce que vous êtes capable de signer ? »
La question surgit dans toute négociation d'envergure dès qu'un projet implique des données sensibles ou réglementées. Pourtant, la plupart des réponses commerciales restent floues : certifications affichées, promesses d'uptime, métriques techniques.
Or ce qui compte vraiment en cas d'incident (panne, fuite, compromission, indisponibilité), c'est le partage contractuel de responsabilité. Qui répond juridiquement de quoi. Ce qu'une agence de développement peut réellement signer, et ce qu'elle se contente de sous-traiter à un hébergeur dont elle ne maîtrise pas les garanties. La différence entre un hébergeur certifié et un simple serveur administré au fil de l'eau, qui ne se voit qu'au moment où tout s'arrête.
Cet article ne choisit aucune option d'hébergement (cloud public, souverain, serveur dédié), il traite du partage de responsabilité contractuelle et des cinq questions qui révèlent un prestataire incapable de garantir ce qu'il vend. Pour des conseils stratégiques sur le choix de votre infrastructure technique, consultez notre service de conseil digital ou explorez nos solutions d'intégration systèmes.
Responsable de traitement et sous-traitant : qui répond de quoi
La loi 09-08 relative à la protection des données personnelles, comme le RGPD européen, distingue deux rôles juridiques clairs : le responsable du traitement (l'entreprise qui décide de ce qui est fait avec les données) et le sous-traitant (celui qui traite les données sur instruction du responsable).
Toute agence qui développe puis héberge votre application métier agit comme sous-traitant au sens de la loi. Elle est donc tenue par des obligations spécifiques, notamment la notification obligatoire en cas de violation de données (article 24 de la loi 09-08), la documentation des mesures de sécurité, et la capacité à démontrer la conformité.
Sauf que beaucoup de prestataires sous-traitent eux-mêmes l'hébergement, par exemple à AWS, OVHcloud ou un fournisseur local. Dans ce cas, l'hébergeur devient un sous-traitant ultérieur. La responsabilité contractuelle vis-à-vis du client final reste celle de l'agence, car c'est elle qui a signé le contrat, mais si l'hébergeur n'a pas de SLA (Service Level Agreement) opposable, l'agence ne peut techniquement pas s'engager sur ce qu'elle ne contrôle pas.
Concrètement, cela signifie que si l'hébergeur perd vos données ou subit une faille, l'agence répond civilement devant vous, mais ne pourra se retourner contre l'hébergeur que si elle a elle-même un contrat qui lui donne ce droit.
C'est pourquoi la première question à poser est simple : qui, juridiquement, se tient responsable en cas de fuite ou d'indisponibilité ? Si la réponse est « notre partenaire hébergeur », demandez à voir le contrat liant l'agence à cet hébergeur, et vérifiez qu'il contient les mêmes garanties que celles qu'on vous promet.
Ce qu'une agence de développement peut contractuellement garantir, et ce qu'elle se contente de sous-traiter
Une agence de développement sur mesure maîtrise le code, l'architecture applicative, les flux de données. Elle peut s'engager contractuellement sur la sécurité du code qu'elle écrit, sur les tests de pénétration, sur le respect de bonnes pratiques (OWASP, injection SQL, gestion des sessions, chiffrement des données sensibles en base).
En revanche, pour tout ce qui relève de l'infrastructure sous-jacente (disponibilité physique du datacenter, redondance réseau, protection anti-DDoS au niveau du réseau, résilience matérielle), l'agence dépend des garanties de son hébergeur. Si elle n'a pas souscrit un SLA opposable avec garantie de disponibilité à 99,9 %, elle ne peut pas vous engager contractuellement sur ce niveau.
La frontière est simple : l'agence peut garantir ce qu'elle code et administre, elle ne peut que relayer les garanties de ce qu'elle sous-traite.
Dans un contrat bien rédigé, cette ligne est tracée explicitement. Par exemple :
- L'agence garantit contractuellement la sécurité applicative, la conformité du code, et la gestion des sauvegardes applicatives.
- L'agence s'engage à choisir un hébergeur certifié (ISO 27001, HDS si santé, etc.), et fournit au client les certificats de l'hébergeur.
- L'agence transfère au client les conditions générales d'hébergement, incluant le SLA de disponibilité et les clauses de responsabilité en cas de perte de données.
Si votre contrat ne comporte aucune de ces clauses, l'agence ne garantit rien contractuellement, elle se contente de promettre oralement. Le jour de l'incident, vous vous retrouvez sans recours opposable.
Hébergeur certifié ou serveur auto-administré : la différence se voit le jour de l'incident
Il existe une différence fondamentale entre un hébergeur certifié qui exploite un datacenter sous normes (ISO 27001, Tier III, HDS pour la santé) et une agence qui loue un VPS chez un fournisseur généraliste et l'administre elle-même.
Dans le premier cas, l'hébergeur assume contractuellement la disponibilité du matériel, la sauvegarde physique des infrastructures, la redondance énergétique, la sécurité physique du site, et souvent, il propose des services gérés (sauvegardes automatiques, snapshots, tests de restauration).
Dans le second cas, tout repose sur la compétence opérationnelle de l'agence. Si elle a mis en place des sauvegardes automatisées, testé régulièrement la restauration, configuré un monitoring actif, et documenté les procédures de reprise, le risque est maîtrisé. Si elle ne l'a pas fait (et beaucoup ne le font pas, car cela représente du temps non facturable), vous découvrez le problème au moment où vous en avez besoin.
La différence se voit au moment de l'incident. Avec un hébergeur certifié, vous avez un interlocuteur contractuel, un SLA opposable, et des procédures documentées. Avec un serveur auto-administré sans documentation ni tests de reprise, vous dépendez de la disponibilité opérationnelle de l'unique administrateur qui connaît l'infrastructure.
C'est pourquoi la preuve à exiger est simple : demandez le dernier rapport de test de restauration réussi. Si l'agence ne peut pas le fournir, cela signifie qu'elle n'a jamais testé la restauration, donc elle ne peut pas garantir qu'elle fonctionne.
Sortie du territoire : la question à trancher avant le choix technique
Si votre entreprise traite des données personnelles (clients, fournisseurs, salariés), vous devez vous poser la question de la localisation géographique de l'hébergement. La loi 09-08 ne l'interdit pas formellement, mais elle impose la notification à la CNDP (Commission Nationale de contrôle de la protection des Données à caractère Personnel) si les données sont transférées hors du Maroc vers un pays dont la législation n'offre pas un niveau de protection équivalent.
Dans la pratique, cela signifie que si vous hébergez sur AWS eu-west-1 (Irlande), vous êtes dans un pays reconnu comme offrant un niveau de protection équivalent (RGPD), donc pas de notification nécessaire. Si vous hébergez sur AWS us-east-1 (Virginie), vous devez notifier la CNDP et documenter les garanties contractuelles (clauses contractuelles types, Privacy Shield si applicable, ou mécanismes équivalents).
Le piège fréquent est de découvrir après signature que l'hébergeur choisi par l'agence est hors du territoire sans garanties documentées. Dans ce cas, vous vous retrouvez en non-conformité potentielle sans l'avoir choisi.
La bonne pratique est de trancher contractuellement avant tout choix technique. Par exemple :
- Hébergement exclusivement dans l'UE ou au Maroc (clause contractuelle).
- En cas de sortie du territoire, notification CNDP à la charge de l'agence, et transmission au client des garanties contractuelles opposables.
Si votre agence propose un hébergement « international » sans préciser où ni documenter les garanties, c'est un signal d'alerte.
Sauvegarde, restauration testée, réversibilité : les trois preuves à exiger
Au-delà des promesses commerciales, trois preuves concrètes permettent de vérifier qu'un hébergement est réellement maîtrisé :
1. Sauvegarde automatisée documentée
Pas « oui, on fait des sauvegardes », mais un document décrivant la fréquence (quotidienne, hebdomadaire, mensuelle), la rétention (combien de versions conservées), la localisation (même datacenter ou géographiquement distante), et le périmètre (base de données uniquement, ou également fichiers applicatifs, configurations serveur).
2. Rapport de restauration testé
Une sauvegarde qui n'a jamais été testée est une sauvegarde théorique. Exigez le dernier rapport de test de restauration réussie, daté de moins de trois mois. Si l'agence ne peut pas le fournir, cela signifie qu'elle ne teste pas ses sauvegardes, donc elle ne peut pas garantir qu'elles fonctionnent.
3. Procédure de réversibilité documentée
En cas de fin de contrat ou de changement de prestataire, vous devez pouvoir récupérer vos données dans un format exploitable. Exigez une procédure documentée de réversibilité : extraction complète de la base de données (format SQL ou équivalent), récupération des fichiers applicatifs, export des configurations nécessaires à la reprise par un tiers.
Si votre contrat ne mentionne pas explicitement ces trois points, vous dépendez de la bonne volonté opérationnelle de l'agence, pas d'un engagement contractuel opposable.
Les clauses à faire figurer dans le contrat d'hébergement
Un contrat d'hébergement bien rédigé ne se contente pas de promettre « un hébergement sécurisé ». Il précise contractuellement les obligations opposables. Voici les clauses essentielles à exiger :
Article sur le partage de responsabilité : distinction claire entre ce que l'agence garantit directement (sécurité applicative, sauvegardes, administration système) et ce qu'elle sous-traite à un hébergeur tiers (disponibilité matérielle, redondance réseau). Si l'agence sous-traite, le client doit recevoir copie du contrat liant l'agence à l'hébergeur.
Article sur la localisation géographique : clause précisant où sont hébergées les données (pays, région), et en cas de sortie du territoire marocain, engagement de l'agence à notifier la CNDP et à documenter les garanties contractuelles (clauses contractuelles types, certifications équivalentes).
Article sur les sauvegardes : fréquence, rétention, localisation, et obligation de l'agence de fournir au client, sur demande, le dernier rapport de test de restauration réussie. Engagement contractuel sur le délai maximum de restauration (RPO, Recovery Point Objective : combien de données peuvent être perdues, par exemple « dernière sauvegarde quotidienne » signifie jusqu'à 24 heures de perte).
Article sur la réversibilité : obligation de l'agence de remettre au client, en fin de contrat ou sur demande, l'intégralité des données dans un format exploitable, incluant base de données, fichiers, configurations, dans un délai contractuel (par exemple 30 jours calendaires).
Article sur la notification en cas d'incident : obligation de l'agence de notifier le client dans un délai contractuel (par exemple 24 heures) en cas de violation de données, d'indisponibilité prolongée, ou de tout incident susceptible d'affecter la sécurité ou la disponibilité du service.
Article sur le SLA de disponibilité : si l'agence s'engage sur un taux de disponibilité (par exemple 99,5 % mensuel), le contrat doit préciser comment ce taux est mesuré, ce qui compte comme indisponibilité (maintenance planifiée exclue ou incluse), et les pénalités contractuelles en cas de non-respect (par exemple crédit de service proportionnel au temps d'indisponibilité).
Si votre contrat actuel ne comporte aucune de ces clauses, vous avez un risque contractuel majeur. Le jour de l'incident, vous découvrez que rien n'est opposable.
Cinq questions qui révèlent un prestataire qui revend un VPS
Voici cinq questions simples à poser pendant la négociation. Les réponses vous diront immédiatement si vous êtes face à un hébergement maîtrisé ou à un simple VPS revendu.
1. Où sont hébergées les données, et pouvez-vous me montrer le certificat de conformité du datacenter ? Si la réponse est « chez notre partenaire » sans pouvoir fournir le nom de l'hébergeur ni aucun certificat (ISO 27001, Tier III, HDS), c'est un VPS généraliste sans garantie.
2. Pouvez-vous me montrer le dernier rapport de test de restauration réussi ? Si la réponse est « on fait des sauvegardes automatiques » sans pouvoir fournir un rapport daté de test réussi, cela signifie qu'ils ne testent jamais leurs sauvegardes, donc ils ne peuvent pas garantir qu'elles fonctionnent.
3. Quel est le délai contractuel de restauration en cas de perte totale du serveur ? Si la réponse est « ça dépend » ou « on fera au plus vite », cela signifie qu'il n'y a pas de RTO (Recovery Time Objective) contractuel, donc aucun engagement opposable sur le délai de reprise.
4. Si je change de prestataire, dans quel format et quel délai puis-je récupérer mes données ? Si la réponse est floue (« on vous donnera un dump »), demandez une procédure documentée de réversibilité. Si elle n'existe pas, vous prenez un risque de dépendance technique.
5. Si l'hébergeur perd mes données, qui est juridiquement responsable devant moi, et sur quelle base contractuelle ? Si la réponse est « notre partenaire hébergeur est responsable », demandez à voir le contrat liant l'agence à cet hébergeur. Si l'agence refuse de le montrer ou n'en a pas, cela signifie qu'elle ne peut pas se retourner contre l'hébergeur, donc elle ne peut pas vous garantir de recours.
Un prestataire sérieux répond à ces cinq questions en moins de dix minutes, documents à l'appui. S'il tergiverse ou promet de « vérifier plus tard », c'est qu'il ne maîtrise pas ce qu'il vend.
Ce que vous devez garder chez vous quoi qu'il arrive
Même avec un hébergement parfaitement maîtrisé, certaines informations critiques doivent rester sous votre contrôle direct, jamais déléguées intégralement au prestataire.
Les accès administrateurs de dernier recours : vous devez conserver un accès root ou administrateur direct au serveur, ou au minimum un compte séparé avec des droits équivalents. Si seul le prestataire détient l'accès administrateur, vous dépendez de sa disponibilité opérationnelle en cas d'urgence.
Les clés de chiffrement maîtres : si vos données sensibles sont chiffrées en base (cartes bancaires, données de santé, informations confidentielles), la clé de chiffrement maître ne doit jamais être stockée uniquement chez le prestataire. Vous devez en conserver une copie dans un coffre sécurisé hors ligne, ou utiliser un HSM (Hardware Security Module) dont vous contrôlez l'accès.
Les certificats SSL et noms de domaine : le certificat SSL de votre domaine doit être émis au nom de votre entreprise, pas au nom de l'agence. De même, le nom de domaine doit être enregistré sous votre raison sociale. Si l'agence détient le domaine, elle peut techniquement vous en priver en cas de litige.
Les sauvegardes hors ligne : en complément des sauvegardes automatisées de l'agence, conservez au moins une sauvegarde mensuelle hors ligne (disque dur externe chiffré, stockage cloud séparé sous votre contrôle). Cela garantit qu'en cas de compromission totale de l'infrastructure, vous avez un point de reprise indépendant.
La documentation technique : architecture réseau, schémas de base de données, configurations critiques, procédures de reprise. Cette documentation doit vous appartenir contractuellement et être mise à jour régulièrement. Si elle n'existe que dans la tête de l'administrateur du prestataire, vous êtes en dépendance opérationnelle totale.
FAQ
Quelle est la différence entre un responsable de traitement et un sous-traitant au sens de la loi 09-08 ?
Le responsable du traitement est l'entreprise qui décide de ce qui est fait avec les données personnelles (finalité, durée de conservation, qui y a accès). Le sous-traitant est celui qui traite les données sur instruction du responsable, sans autonomie de décision. Une agence qui développe et héberge votre application est juridiquement sous-traitant au sens de la loi, donc tenue par des obligations spécifiques de sécurité, de notification en cas de violation, et de documentation des mesures techniques.
Si mon hébergeur est en Europe, dois-je notifier la CNDP ?
Cela dépend du pays. Si l'hébergement est dans un pays de l'UE (donc soumis au RGPD, reconnu comme offrant un niveau de protection équivalent), aucune notification spécifique n'est requise, car la protection est considérée comme équivalente. En revanche, si l'hébergement est hors UE (par exemple États-Unis, Chine, Russie), vous devez notifier la CNDP et documenter les garanties contractuelles opposables (clauses contractuelles types, certifications équivalentes, mécanismes de transfert reconnus).
Comment vérifier qu'une sauvegarde fonctionne réellement ?
La seule façon fiable est de tester régulièrement la restauration. Demandez à votre prestataire de planifier un test de restauration sur un environnement de test (jamais en production), et de vous fournir un rapport détaillé attestant que la base de données, les fichiers applicatifs, et les configurations ont été restaurés avec succès et que l'application fonctionne après restauration. Un test réussi daté de moins de trois mois est une preuve concrète. Si votre prestataire refuse ou reporte systématiquement, c'est qu'il ne teste jamais ses sauvegardes.
Que faire si mon agence refuse de me montrer le contrat avec l'hébergeur ?
C'est un signal d'alerte majeur. Si l'agence vous promet des garanties (disponibilité, sécurité, conformité) mais refuse de vous montrer le contrat qui lie l'agence à l'hébergeur, cela signifie soit qu'elle n'a pas de contrat opposable (donc aucun moyen de se retourner contre l'hébergeur en cas de problème), soit que le contrat ne contient pas les garanties promises. Dans ce cas, exigez contractuellement que l'agence assume directement la responsabilité de ces garanties, et si elle refuse, envisagez de changer de prestataire.
Combien de temps faut-il conserver les sauvegardes d'une application métier ?
Cela dépend de vos obligations réglementaires et de votre tolérance au risque. En général, une rétention quotidienne sur 30 jours, hebdomadaire sur 12 semaines, et mensuelle sur 12 mois est un bon compromis pour une application métier. Si vous traitez des données soumises à des obligations d'archivage (comptabilité, santé, services financiers), vous devez conserver des sauvegardes archivées pendant la durée légale (10 ans pour la comptabilité au Maroc, par exemple). Vérifiez que votre contrat d'hébergement prévoit explicitement cette rétention, sinon l'agence peut supprimer les anciennes sauvegardes sans vous prévenir.