Résumé
- CleverCloud doit être lu comme l'étiquette de répertoire de Clever Cloud SAS, une société par actions simplifiée française immatriculée à Nantes, plutôt que comme une garantie générique que chaque résultat de service est français, souverain, automatisé ou opérationnellement sûr.
- Les preuves de service public les plus solides sont la documentation de la plateforme de l'entreprise: déploiement d'applications, bases de données gérées, stockage d'objets, gestion CLI et API, rôles d'organisation, contrôles de facturation, observabilité, groupes réseau, service IP unique, options VPN, migration de zone et parcours d'assistance.
- Le signal de risque le plus utile n'est pas la revendication de la marque mais la frontière entre ce que Clever Cloud exécute, ce qu'il orchestre via des partenaires d'infrastructure, ce que les clients doivent configurer, et ce que les incidents ont montré à propos des zones de disponibilité de Paris, des opérations de déploiement, et de la dépendance envers les fournisseurs de centres de données et de réseau.
- Les acheteurs doivent traiter l'identité française, le langage ISO/HDS, les listes de centres de données et les engagements d'assistance premium comme des éléments d'examen, puis tester les preuves exactes de zone, de récupération, d'assistance, d'accès, de traitement des données, de facturation et de réseau dont leur propre application dépendrait.
La première chose utile à dire à propos de CleverCloud est que l'orthographe sur une carte de répertoire n'est pas la société opérationnelle. Le dossier juridique public derrière le nom de cloud est Clever Cloud SAS. Sa propre notice légale identifie l'entreprise comme une société par actions simplifiée française, immatriculée au registre du commerce de Nantes sous le numéro RCS Nantes B 524 172 699, dont le siège social est situé au 4 rue Voltaire à Nantes, avec un numéro de TVA FR 87 524 172 699.
C'est un point de départ plus solide qu'un slogan car il donne à l'acheteur une personne morale, une juridiction, une adresse d'entreprise et une surface de contact de support. Cela ne prouve pas en soi la résilience, la résidence des données, le contrôle du réseau ou la récupération spécifique au client. Cela donne à l'enquête un endroit où se tenir.
Cette distinction est importante car le marketing du cloud compresse souvent trois questions distinctes en un seul mot. Une question est l'identité: qui est l'entreprise contractante et responsable? Une autre est le périmètre de service: quelles fonctions techniques sont fournies par la plateforme et lesquelles sont laissées au client ou à une infrastructure tierce? Une troisième est la preuve opérationnelle: que montre le dossier public en cas de problème de déploiement, d'incident de zone de disponibilité, d'escalade de support, d'exigence de localisation des données ou de demande de liste blanche réseau?
Clever Cloud dispose de documents publics pour ces trois aspects, mais ces documents sont inégaux comme le sont la plupart des registres opérationnels. L'entreprise a une identité d'entreprise française claire et une surface produit substantielle. Elle s'appuie également sur des centres de données et des emplacements d'infrastructure cloud nommés, et ses documents d'incident montrent que la surface opérationnelle n'est pas isolée des événements d'alimentation, de fibre, de plan de contrôle ou d'hyperviseur du fournisseur.
L'entreprise se décrit comme un fournisseur européen de Platform as a Service qui aide les équipes de développement à mettre en production des applications et des services avec une scalabilité automatique et une tarification transparente. Sur son site public, elle présente la plateforme comme un moyen d'exécuter, d'automatiser, d'observer, de sécuriser et de gérer des environnements informatiques.
Le langage produit inclut des environnements d'exécution d'applications, des bases de données gérées, du stockage d'objets, de l'automatisation d'infrastructure, des logs, des métriques, des alertes, la gestion des identités et des accès, et plusieurs services gérés. Pour un développeur ou une équipe plateforme, c'est le centre pratique de l'entreprise. Clever Cloud ne se contente pas de vendre de l'espace rack sous un nom d'entreprise français.
Elle vend une couche gérée qui transforme le déploiement d'applications, le provisionnement de bases de données, la mise à l'échelle, la surveillance, la facturation et le support en une relation opérationnelle récurrente.
La promesse opérationnelle est attrayante précisément parce qu'elle supprime le travail répétitif des équipes qui autrement posséderaient plus de serveurs, de packages, de maintenance de bases de données, de sauvegardes, de contrôles d'accès et de colle de déploiement. La documentation décrit le déploiement d'applications via Git, l'interface en ligne de commande Clever Tools, l'accès API, les intégrations CI/CD et une console web.
Elle liste les environnements d'exécution pour les langages et frameworks, les add-ons pour bases de données et services, et les pages d'administration pour les domaines, la mise à l'échelle, les logs, la mise en réseau, les dépendances de service, l'accès SSH, la facturation et la gestion des organisations. C'est de l'automatisation de logiciel d'entreprise dans le sens ordinaire et de grande valeur: moins d'étapes de déploiement manuelles, plus de contrôles standardisés, et plus de travail déplacé vers une plateforme reproductible entre les équipes.
Pourtant, l'automatisation n'est pas l'absence de travail. Elle change l'endroit où se situe le travail. Une équipe utilisant Clever Cloud doit encore décider quelle zone utiliser, quels add-ons provisionner, quels rôles d'organisation accorder, comment configurer les hooks de déploiement, quoi surveiller, comment gérer la rotation des secrets, comment séparer la facturation par organisation, comment gérer les communications d'incident et comment tester la récupération. Le travail du fournisseur est de rendre ces actions plus simples et plus cohérentes.
Le travail du client est de s'assurer que la configuration correspond au risque de l'application. Les documents soutiennent une vision de Clever Cloud comme un service pouvant réduire les frottements opérationnels, mais pas une vision où les frottements disparaissent.
La preuve produit la plus solide réside dans l'étendue de la documentation pratique. Clever Tools est décrit comme une interface en ligne de commande pour créer et gérer des applications, bases de données, add-ons de stockage et accès API authentifié. Le matériel de démarrage rapide oriente les équipes vers le déploiement via Git et explique que le déploiement supprime le dossier Git côté serveur pour des raisons de sécurité. La liste des add-ons inclut PostgreSQL, MySQL, MongoDB, Redis, Elastic Stack, Pulsar, Keycloak, Matomo, Metabase, Jenkins, le stockage d'objets, les buckets de système de fichiers et d'autres services.
La page DBaaS décrit la commande de bases de données gérées depuis la plateforme et fait référence au support de personnalisations telles que la réplication leader/follower, les extensions et les configurations sur mesure. Ces documents ne prouvent pas que chaque charge de travail sera plus rapide, moins chère ou plus sûre sur Clever Cloud. Ils prouvent une véritable frontière produit au-delà d'une entrée de répertoire.
Pour les clients, la frontière produit est aussi une question de ce qui peut être inspecté. Une pile auto-gérée donne à une équipe un contrôle direct sur chaque machine mais lui confie aussi chaque mise à jour, correctif, incident et problème de capacité. Un PaaS géré cache une grande partie de ces détails en échange de reproductibilité et de support. La bonne question de diligence n'est donc pas de savoir si Clever Cloud automatise le déploiement. La documentation montre que c'est le cas. La question est de savoir si l'acheteur peut inspecter suffisamment cette automatisation pour lui faire confiance pour la charge de travail concernée.
Cela signifie examiner les logs, métriques, enregistrements de déploiement, procédures de sauvegarde et de restauration, politiques de version de base de données, historique de statut, rôles d'organisation, jetons API, détails de facturation et engagements de réponse de support.
La revendication de souveraineté des données nécessite la même attention. Clever Cloud déclare être une entreprise française opérant au sein de l'Union européenne et présente des engagements concernant la conformité RGPD, l'ISO 27001, l'HDS, la réversibilité et la protection contre certains risques juridiques extraterritoriaux. Sa page d'accueil indique qu'elle exploite ses propres centres de données en France et présente un argument fort en matière de souveraineté.
Sa page infrastructure liste des sites français dans ou autour de Paris et du nord de la France, notamment Nanterre, Paris, Aubervilliers, Saint-Ouen-l'Aumône, Roubaix, Gravelines, et une option Cloud Temple en France pour les besoins SecNumCloud. Ces faits sont significatifs pour les clients français et européens, en particulier le secteur public, la santé, les logiciels réglementés et les entreprises cherchant à réduire leur exposition au contrôle cloud non européen.
Mais la même page infrastructure liste également des emplacements non français ou partenaires, notamment Londres, Québec, Singapour, Sydney et Dubaï, aux côtés des sites français. La documentation de migration de zone utilise Paris à Montréal comme exemple de déplacement de services d'une zone à une autre. Cela n'affaiblit pas la revendication d'identité française; cela clarifie sa limite. Clever Cloud peut être un fournisseur français avec des options d'infrastructure françaises tout en exploitant une plateforme multi-zone comprenant des emplacements en dehors de la France.
Un acheteur ne peut pas déduire la résidence des données du nom de l'entreprise. L'acheteur doit inspecter la zone sélectionnée, le service applicable, les add-ons impliqués, l'accord de traitement des données, toute sous-traitance ou dépendance d'infrastructure, le parcours de support et les contrôles de migration.
Cette distinction est particulièrement importante pour les charges de travail sensibles dans les domaines de la santé, du public ou de la souveraineté. L'entreprise fait la publicité du langage ISO 27001 et HDS et décrit une zone SecNumCloud disponible via Cloud Temple sur demande. Ce ne sont pas des badges interchangeables. L'ISO 27001 concerne un système de management de la sécurité de l'information. L'HDS est pertinent dans les contextes français d'hébergement de données de santé.
SecNumCloud est un niveau élevé pour certains cas d'utilisation de cloud souverain français, et le langage public pointe ici vers une zone disponible sur demande via un partenaire, pas un statut universel appliqué à chaque produit dans chaque région. L'examen doit donc partir de la commande de service exacte, pas d'une page de conformité générale.
Les preuves réseau et de ressources sont utiles car elles résistent à l'abstraction. La documentation réseau de Clever Cloud indique que certains services externes nécessitent la mise en liste blanche des adresses IP source du client, tandis que les applications peuvent être déployées quelque part à l'intérieur de la zone choisie, rendant l'IP sortante difficile à prédire sans un arrangement dédié. L'entreprise décrit un service IP unique par région que le support peut configurer pour donner au trafic une adresse IP source fixe, avec un prix mensuel documenté au moment de la rédaction de la documentation.
Elle décrit également des options de service VPN, notamment WireGuard, IPSec et OpenVPN, pour les clients ou fournisseurs ayant besoin de liens chiffrés entre les régions Clever Cloud et un autre centre de données. Ce n'est pas une preuve tape-à-l'œil, mais c'est une preuve opérationnellement précieuse: les vrais clients ont besoin d'une sortie fixe, de VPN et de listes blanches, et le fournisseur doit dire comment ces cas fonctionnent.
Les groupes réseau étendent cette preuve. La documentation décrit les groupes réseau comme un moyen de créer une communication privée et chiffrée entre les ressources au sein de l'infrastructure Clever Cloud en utilisant WireGuard, avec la possibilité de connecter des ressources externes. Le modèle comprend des groupes réseau, des membres et des pairs. Il peut lier des applications et des add-ons afin qu'ils puissent communiquer sur un réseau privé. La documentation en ligne de commande montre la création, la liste, la liaison, le déliement et le ciblage des groupes réseau vers des organisations.
Cela indique à un acheteur que la plateforme ne se limite pas aux points de terminaison publics et au déploiement d'applications de base. Elle dispose d'une fonction d'isolation réseau visant les architectures distribuées, les environnements sensibles et les conceptions de services mixtes internes/externes.
Il y a aussi une limite ici. Les groupes réseau sont un contrôle produit, pas une preuve que Clever Cloud possède ou annonce un système autonome particulier, pas une preuve de résilience BGP, et pas une preuve que l'architecture d'un client est privée par défaut. Le large dossier public disponible pour cet examen n'a pas établi un ASN ou une politique de routage faisant autorité pour Clever Cloud qui pourrait être utilisé comme une garantie de service. L'interprétation la plus sûre est plus étroite: l'entreprise publie de la documentation pratique sur l'IP, la sortie unique, le VPN, le réseau privé et les zones.
Ces documents aident un acheteur à concevoir la connectivité du service. Ils ne remplacent pas une diligence réseau indépendante pour les systèmes réglementés, à haute disponibilité ou sensibles au peering.
Les enregistrements de statut et d'incident sont l'endroit où la promesse marketing rencontre la plateforme telle qu'elle est exploitée. La page de statut publique de Clever Cloud n'a enregistré aucun incident pour le 14 juillet 2026, mais elle a également montré un incident de performance de déploiement dégradé le 13 juillet 2026. Pendant cet incident, les déploiements ont été affectés et certaines applications en cours de redémarrage ont pu temporairement se désynchroniser et renvoyer des erreurs 503 pendant que les composants affectés étaient redémarrés.
La même page de statut a enregistré le 10 juillet 2026 une perte d'un lien réseau entre deux zones de disponibilité parisiennes, l'entreprise déclarant que son infrastructure avait suffisamment de redondance pour absorber la perte et qu'aucune perturbation de service n'avait été observée. Des mises à jour ultérieures ont attribué le problème de lien à une intervention manuelle du fournisseur sur l'infrastructure fibre et ont indiqué que les systèmes fonctionnaient normalement après la stabilisation du lien.
Ce sont des détails constructifs car ils montrent deux types différents d'enregistrement opérationnel. L'un était un problème de plan de déploiement avec des erreurs visibles pour certaines applications redéployées. L'autre était un problème de lien réseau où la redondance semble avoir absorbé l'événement. Aucun ne doit être exagéré. Une seule entrée de statut ne prouve pas une faiblesse générale de déploiement. Un seul incident fibre absorbé ne prouve pas que toutes les défaillances réseau seront absorbées.
Ensemble, ils montrent que l'histoire de confiance de la plateforme doit inclure les liens entre zones de disponibilité, les contrôleurs de déploiement, la coordination des fournisseurs et les communications avec les clients, pas seulement les mots « haute disponibilité » sur une page produit.
Le post-mortem du 3 mars 2025 est plus révélateur. Clever Cloud a décrit une panne d'alimentation électrique chez l'un de ses fournisseurs de centres de données qui a perturbé la zone de disponibilité PAR6 dans la région EU-FR-1. Elle a indiqué que le trafic réseau a été perturbé et que l'infrastructure a subi une pression d'E/S et de mémoire, entraînant des instabilités et des temps d'arrêt. Elle a également indiqué que les clients dépendant de la région Paris EU-FR-1 ont été affectés, ainsi que les zones distantes dépendant du plan de contrôle EU-FR-1 et certaines zones privées, tandis que les zones sur site n'ont pas été impactées.
L'impact produit comprenait la dégradation des performances des applications, des problèmes de trafic, des déploiements bloqués, des opérations de mise à l'échelle ascendante et descendante échouées, et une possible dégradation ou indisponibilité des bases de données sur les hyperviseurs affectés, tandis que le dossier indique qu'aucune perte de données ne s'est produite pour ces catégories de bases de données.
Ce post-mortem est un point de contrôle important pour cette entreprise. Il montre que le service a une culture réelle de statut et d'explication post-incident, ce qui est mieux que le silence. Il montre également la forme opérationnelle d'une défaillance PaaS: un événement d'infrastructure peut se propager à travers l'alimentation, le trafic réseau, la pression de l'hyperviseur, l'accessibilité de l'API de déploiement, le trafic d'exécution, les performances des bases de données et les actions de récupération des clients.
Pour les acheteurs, le post-mortem devrait conduire à des questions sur l'architecture de la région, la dépendance au plan de contrôle, l'indépendance des zones privées, les tests de sauvegarde, les attentes de basculement et l'escalade de support. La leçon n'est pas que Clever Cloud n'est pas fiable. La leçon est que la plateforme est suffisamment concrète pour échouer de manière concrète, et ces manières doivent être examinées avant qu'un client ne s'appuie sur la marque pour une charge de travail critique.
Le support est l'un des endroits où l'identité française de Clever Cloud devient plus qu'une juridiction. La notice légale donne un support technique à[email protected]et liste les heures de support du lundi au vendredi, de 9h à 18h CET/CEST. La documentation de support indique que le support de base est gratuit pour tous les utilisateurs, y compris les utilisateurs non payants, et que le support par e-mail doit répondre en quelques heures, ou dans un délai de deux jours ouvrables dans le pire des cas. Elle décrit également un centre de tickets console où les clients peuvent démarrer une conversation avec les ingénieurs, créant des fils pour des problèmes individuels, et note que les membres de l'organisation peuvent être ajoutés aux discussions de tickets par e-mail.
Ce modèle de support est important car les services cloud gérés remplacent une partie du travail interne par du travail du fournisseur. Un client n'achète pas seulement de l'automatisation; il achète une file d'attente, un ensemble d'ingénieurs, un processus de support et un niveau de confiance que les questions seront répondues par des personnes qui peuvent voir la plateforme. Le langage de support public de Clever Cloud est assez spécifique pour le support ordinaire, et la présence d'un chef de l'expérience de support nommé sur la page exécutive publique renforce que le support fait partie de l'histoire opérationnelle de l'entreprise.
Mais les heures de support standard ne sont pas les mêmes qu'un support critique. Les clients qui ont besoin d'engagements 24h/24 et 7j/7 doivent examiner l'offre et la politique Premium.
Le dossier Premium est suffisamment spécifique pour ancrer une revue commerciale. Clever Cloud Premium annonce une disponibilité annuelle de 99,99 % pour les services éligibles, une ligne d'urgence 24h/24 et 7j/7, un traitement prioritaire, des délais d'intervention et de résolution contractuels, et un suivi plus personnalisé. La page publique indique que les incidents critiques ou majeurs reçoivent un temps garanti d'intervention de quinze minutes via la ligne dédiée et un temps garanti de résolution de deux heures, tandis que les incidents mineurs ont des objectifs en heures ouvrables.
La page Premium indique également une formule de prix de 1,8 fois la consommation mensuelle plus 490 EUR HT par mois. La politique Premium lie la garantie de 99,99 % aux services pour lesquels le client a souscrit l'option.
Ce n'est pas un add-on anodin. Cela change le modèle de coût et de risque. Une petite équipe utilisant le support standard peut raisonnablement accepter un support en heures ouvrables si la charge de travail est à faible risque ou dispose de contrôles alternatifs. Un client réglementé ou dont les revenus sont critiques doit décider si le coût Premium est justifié par la ligne d'urgence, les temps de réponse, les crédits de service ou pénalités, et l'attention opérationnelle.
La clé est de comparer l'engagement Premium avec le propre coût d'indisponibilité du client, la disponibilité des ingénieurs, l'architecture de basculement et les obligations contractuelles envers ses utilisateurs. Le support Premium est une preuve de frontière de service; ce n'est pas un substitut à la conception de résilience.
La gouvernance des accès est un autre niveau pratique. La documentation organisationnelle de Clever Cloud décrit la séparation de l'espace personnel des organisations, l'ajout de collaborateurs et l'attribution de rôles. Elle liste les rôles tels qu'Admin, Manager, Developer et Accountant avec des droits différents, notamment l'ajout de membres, l'ajout d'applications, la suppression d'applications, la gestion des add-ons, l'édition ou la suppression d'organisations, l'accès aux factures et l'accès aux dépôts. La documentation de facturation décrit des factures mensuelles par organisation et une consommation détaillée des services.
La documentation de notifications explique les e-mails de résultat de déploiement et les webhooks. Ce sont des contrôles ordinaires, mais les contrôles ordinaires décident si une plateforme est utilisable dans une entreprise plutôt que seulement par un développeur individuel.
Pour un acheteur entreprise, les rôles d'organisation et les enregistrements de facturation aident à répondre à une question apparemment simple: l'entreprise peut-elle utiliser cette plateforme sans perdre la trace de qui a changé quoi, qui paie, qui reçoit les messages d'incident ou de déploiement, et qui peut supprimer des ressources critiques? Le matériel public de Clever Cloud fournit des éléments de base. Il ne montre pas la configuration réelle du client.
Un acheteur doit tester la séparation des rôles, la création et la révocation de jetons, les permissions de déploiement, la visibilité de la facturation, les notifications par défaut et la capacité des discussions de support à atteindre les bonnes personnes en cas d'incident. L'automatisation qui contourne la responsabilité crée un nouveau risque; l'automatisation liée à des rôles clairs peut le réduire.
La surface des bases de données gérées mérite une attention particulière car la commodité du PaaS cache souvent le risque lié à l'état. Clever Cloud commercialise des bases de données gérées telles que PostgreSQL, MySQL, MongoDB, Redis, Elastic Stack et ses propres services Materia. Sa documentation contient des mises à jour produit répétées autour de PostgreSQL, MySQL, Redis, Keycloak, Metabase, Otoroshi et d'autres add-ons. Cela montre une plateforme active, mais les services avec état ne peuvent pas être évalués par les seuls noms de produits.
L'examen des bases de données doit porter sur la politique de version, les avis de maintenance, les chemins de sauvegarde et de restauration, les options de réplication, le placement en zone, le périmètre du support, la disponibilité des extensions, les conditions de traitement des données et l'historique des incidents. Le post-mortem de mars 2025 est utile ici car il sépare la perte de données de la dégradation et de la disponibilité.
Le dossier indique qu'aucune perte de données ne s'est produite pour les catégories de bases de données listées lors de cet événement, mais il indique également que les clients sur les hyperviseurs affectés ont pu constater une dégradation ou une indisponibilité.
C'est le bon niveau de spécificité pour une liste de contrôle d'acheteur. Si l'application ne peut pas tolérer l'indisponibilité de la base de données, le client a besoin d'une conception plus solide qu'une simple case à cocher de base de données gérée. Si elle peut tolérer de brèves interruptions mais pas la perte de données, le client a besoin de preuves de sauvegarde, de restauration et d'incident. Si elle utilise des données de santé, des données du secteur public ou des données sensibles de clients, le client a besoin des informations exactes sur l'HDS, l'ISO, le DPA, la localisation et le périmètre de support.
Le matériel de Clever Cloud fournit des preuves de départ pour ces conversations. Il ne doit pas être étiré pour devenir une garantie globale.
L'interopérabilité et la réversibilité font également partie de l'histoire de la souveraineté. Clever Cloud déclare que l'interopérabilité et la souveraineté sont compatibles et présente des engagements autour de l'opération européenne, du RGPD, de l'ISO 27001, de l'HDS et d'une réversibilité contractuelle et technique claire. Son site public pointe vers Git, GitLab, Terraform, l'accès API et les outils CLI. Le risque de réversibilité dans une plateforme gérée n'est pas seulement de savoir si une application peut être déplacée en théorie.
Il s'agit de savoir si les données, les procédures de construction, les variables d'environnement, les domaines, le stockage, les bases de données, les logs et les dépendances peuvent être reconstruits sous pression temporelle. Les outils standard de la plateforme aident, mais un client doit maintenir ses propres preuves de sortie: définitions d'infrastructure, vidages de base de données ou stratégie de réplication, plan de migration de stockage d'objets, contrôle de domaine, inventaire des secrets et un runbook testé.
Ce mot « souveraineté » peut sinon faire trop de travail. Dans un usage, il signifie que le fournisseur est français et régi en France. Dans un autre, il signifie que les charges de travail peuvent s'exécuter dans des centres de données français. Dans un autre, il signifie qu'un client français ou européen réglementé peut satisfaire à un cadre juridique ou de sécurité spécifique. Dans un autre, il signifie qu'un client a suffisamment de contrôle pratique pour partir, récupérer ou prévenir l'enfermement. Clever Cloud a des preuves dans chaque domaine, mais les preuves ne sont pas identiques.
Une décision d'achat doit mapper chaque exigence à un contrôle concret: identité de l'entreprise à la notice légale et au contrat, localisation à la zone sélectionnée, conformité au périmètre du certificat et à la commande de service, réversibilité aux outils et aux tests, support aux conditions standard ou premium, et résilience à l'architecture et aux preuves d'incident.
Les références clients publiques sur le site de Clever Cloud valent la peine d'être lues comme des témoignages marketing, pas comme des preuves système. Elles parlent de productivité, de scalabilité, de protection des données et de confiance de la part de clients ou d'équipes nommés. Elles peuvent être utiles pour comprendre le positionnement sur le marché et les personas d'acheteur, en particulier les éditeurs de logiciels français, les organismes publics, les organismes de santé et les équipes technologiques qui veulent un fournisseur local. Mais les références ne sont pas des benchmarks.
Elles n'établissent pas la précision, la disponibilité, le temps moyen de récupération, les faux positifs ou le coût de migration pour un autre client. La méthode la plus fiable consiste à utiliser les témoignages pour façonner les questions, puis à demander au fournisseur des preuves de niveau de service, d'incident, d'architecture et de support pour la charge de travail réelle.
La question commerciale n'est donc pas « Clever Cloud est-il un fournisseur de cloud? ». Le dossier public soutient que oui. La question est de savoir si un abonnement réduit le risque opérationnel réel après que le client a pris en compte le travail de migration, la reconversion des développeurs, les limites de la plateforme, le coût du support premium, la tarification des add-ons, les besoins de sortie ou d'IP unique, l'examen de conformité et la nouvelle dépendance vis-à-vis du support et du plan de contrôle de Clever Cloud.
Pour une équipe qui lutte actuellement avec des serveurs non gérés, des habitudes de déploiement incohérentes, une surveillance faible et une maintenance de base de données ad hoc, la plateforme pourrait réduire les risques en standardisant le travail. Pour une équipe avec un réseau hautement spécialisé, des systèmes avec état inhabituels ou des exigences strictes d'indépendance entre régions, la plateforme peut encore aider, mais seulement après des tests plus approfondis.
Un acheteur devrait commencer par l'examen de l'identité et du contrat. Confirmer que la contrepartie est bien Clever Cloud SAS, que le contrat correspond au produit sélectionné, que le DPA couvre le rôle de traitement, que la zone sélectionnée satisfait aux exigences de localisation des données, et que les éventuels termes de support premium sont effectivement inclus. Passer ensuite à la preuve technique.
Déployer une application représentative, provisionner les add-ons requis, configurer les logs, métriques, alertes, rôles d'accès, hooks de déploiement, sauvegarde et restauration, sortie fixe ou VPN si nécessaire, et un groupe réseau si la communication privée fait partie de la conception. Tester non seulement le chemin heureux mais aussi un déploiement échoué, un ticket de support, une restauration de base de données, un changement de rôle, une révision de facture, un abonnement à la page de statut et une migration entre zones ou hors de la plateforme.
Le même acheteur devrait demander ce que la plateforme ne montre pas publiquement. Existe-t-il des listes détaillées de sous-traitants pour le service exact? Quels produits sont couverts par chaque certificat ou revendication d'hébergement réglementé? Quelle est la dépendance au plan de contrôle pour une zone privée ou distante? Quel est l'objectif de récupération pour le plan de base de données sélectionné? Comment les notifications clients sont-elles acheminées lors d'un incident de déploiement? Quels logs sont conservés et pendant combien de temps? Comment les jetons API sont-ils rotés et révoqués?
À quelle vitesse le service IP unique ou VPN peut-il être provisionné? Que se passe-t-il lorsqu'un fournisseur d'infrastructure signale un incident fibre ou électrique? Ces questions ne sont pas hostiles. Elles sont le coût normal de la transformation d'un nom de cloud public en une décision opérationnelle.
Une raison pour laquelle ces questions comptent est que la surface de service de Clever Cloud se situe entre la commodité pour le développeur et la responsabilité de l'infrastructure. Un développeur peut vivre la plateforme comme une cible de déploiement propre: connecter un dépôt, définir des variables, choisir un environnement d'exécution, attacher une base de données, surveiller les logs et laisser la plateforme faire le reste. Un responsable des opérations voit une image différente.
Le même service devient une chaîne d'enregistrements d'identité, d'identifiants de déploiement, de rôles d'organisation, de files d'attente de support, de notifications de statut, de choix de localisation des données, de politiques de stockage, de tests de sauvegarde et d'historiques d'incidents. La valeur d'un PaaS est que ces couches sont assemblées plus rapidement. Le risque est que l'assemblage peut sembler plus simple que la chaîne de dépendances en dessous.
C'est pourquoi les preuves doivent être lues en couches plutôt que comme un score unique. La couche juridique est suffisamment solide pour une identification de base: il y a une entreprise française nommée, une adresse, un numéro de registre du commerce, un numéro de TVA et un contact de support. La couche produit est suffisamment solide pour montrer une plateforme gérée réelle avec des environnements d'exécution d'applications, des add-ons, des contrôles CLI/API, des fonctionnalités de réseau privé, la facturation, les rôles et les canaux de support.
La couche infrastructure est mixte par conception: il y a de nombreux emplacements français et aussi des régions partenaires ou non françaises. La couche incident est utile mais limitée: les enregistrements publics de statut et de post-mortem montrent à la fois la transparence et des chemins de défaillance concrets. Un acheteur qui maintient ces couches séparées fera moins d'erreurs de catégorie.
L'accord de traitement des données appartient à cette lecture en couches. Il traite Clever Cloud comme un sous-traitant agissant sur les instructions du client pour les données personnelles, en utilisant des clauses contractuelles types européennes et des obligations concernant la finalité, les instructions et la sécurité. Cela a du sens pour un client qui doit documenter les rôles RGPD. Cela laisse aussi du travail au client.
Le client reste responsable de savoir quelles données sont traitées, quels tiers ou zones sont impliqués, si le service sélectionné est dans la région prévue, si les propres instructions du responsable du traitement sont licites, et si l'architecture correspond aux contrôles promis. La surface contractuelle soutient la diligence; elle n'effectue pas la diligence par elle-même.
Il en va de même pour la réversibilité. Le langage public de Clever Cloud insiste sur la réversibilité contractuelle et technique, et le dossier d'outillage donne aux clients plusieurs poignées utiles: déploiement Git, commandes CLI, accès API, références Terraform, documentation de base de données, services de stockage et guide de migration de zone. Mais la réversibilité n'est réelle que lorsque le client l'a répétée.
Un client qui n'exporte jamais sa base de données, n'enregistre jamais ses variables d'environnement en dehors de la console, ne teste jamais le basculement de domaine, ne documente jamais les dépendances des add-ons et ne valide jamais la restauration de sauvegarde peut découvrir trop tard que la sortie théorique est plus lente que ce que l'entreprise peut tolérer. Le fournisseur peut fournir des outils; le client doit préserver la piste de sortie.
Cette piste est particulièrement pertinente pour les équipes qui choisissent Clever Cloud parce qu'elles veulent une alternative européenne aux grands fournisseurs mondiaux. Les projets de souveraineté commencent souvent par une préférence juridique ou politique, mais ils réussissent ou échouent sur des détails opérationnels. Si une application est placée dans une zone française, attachée à une base de données gérée, protégée par un groupe réseau, facturée à la bonne organisation, surveillée via des logs et des métriques, et soutenue par un parcours d'escalade documenté, le choix du fournisseur français devient un contrôle opérationnel.
Si la même application dépend silencieusement d'une API externe non testée, d'un jeton non enregistré, d'une liste blanche codée en dur et d'un plan de support qui ne correspond pas à la sévérité de l'incident, l'étiquette de souveraineté ne sauvera pas le service.
Pour les petites équipes, l'attrait de Clever Cloud peut être différent. La comparaison pertinente n'est peut-être pas un contrat hyperscale d'entreprise. Cela peut être un petit groupe d'ingénieurs qui maintient actuellement des serveurs, des packages, des bases de données, des déploiements et une surveillance par habitude. Pour cet acheteur, l'automatisation de la plateforme peut remplacer un ensemble fragile de routines manuelles par un déploiement reproductible, des add-ons gérés, une facturation par organisation et un support visible.
Le risque est la surprise de coût, les limites de la plateforme et la dépendance à une file d'attente du fournisseur. L'examen doit donc être pratique: déployer un service réel, créer et restaurer une base de données, utiliser le CLI, ouvrir un ticket de support, examiner une facture et décider si la cohérence gagnée vaut la dépense récurrente.
Pour les grandes organisations, l'examen se déplace vers la cartographie des contrôles. La plateforme peut convenir à une équipe ou à une charge de travail, mais les achats, la sécurité, les finances, la protection des données et les opérations poseront chacun des questions différentes. La sécurité voudra l'identité, l'accès, la journalisation, la rotation des jetons, la segmentation réseau, la réponse aux vulnérabilités et le périmètre des certificats. Les finances voudront la facturation par organisation, le détail des factures et l'impact du prix premium.
La protection des données voudra le rôle de traitement, la région, la conservation et les transferts. Les opérations voudront la notification d'incident, l'escalade de support, les objectifs de récupération, l'historique de statut et les plans de migration. Le dossier public donne un matériel de départ pour chaque groupe, mais les groupes ne doivent pas substituer les réponses des uns et des autres.
Les enregistrements de statut de Clever Cloud de juillet 2026 montrent aussi pourquoi les opérations de déploiement doivent être testées séparément de la disponibilité de l'exécution. Une plateforme peut servir des applications en direct pendant que les opérations de déploiement sont dégradées, et cela compte toujours. Si un client dépend de versions fréquentes, de modifications de mise à l'échelle automatique, de correctifs d'urgence ou de rollback rapide, un incident de plan de déploiement peut devenir un incident métier même lorsque le trafic existant est majoritairement stable.
Inversement, un problème de lien réseau entre zones de disponibilité peut être absorbé par la redondance et mérite quand même un examen car il révèle la dépendance au fournisseur et la coordination du plan de contrôle. La disponibilité n'est pas une seule mesure. C'est l'interaction du trafic d'exécution, du contrôle de déploiement, de l'état de la base de données, des chemins réseau et des communications de support.
Le post-mortem de mars 2025 renforce ce point en séparant plusieurs formes d'impact. Les applications ont connu des problèmes de trafic et de performance. Les opérations de déploiement ont été bloquées par l'accessibilité de l'API. Les bases de données ont pu être dégradées ou indisponibles sur les hyperviseurs affectés. Les dépendances du plan de contrôle reliaient Paris aux zones distantes ou privées. Les zones sur site ont été décrites comme non affectées. Un acheteur ne doit pas effacer ces distinctions.
Elles aident à déterminer quelle architecture est plus sûre: une zone publique standard, une zone privée, un arrangement sur site, un plan de support premium, une conception multi-zone ou une charge de travail laissée ailleurs. Le post-mortem est précieux car il donne suffisamment de forme pour poser ces questions d'architecture.
Il y a aussi un signal culturel dans la documentation elle-même. Clever Cloud publie de nombreuses pages opérationnelles qui ne sont pas de simples textes de vente: les contraintes réseau et IP, les horaires de support, les rôles d'organisation, les détails de facturation, la migration de zone, les commandes de groupes réseau et les post-mortems. Ces pages rendent l'entreprise plus facile à évaluer car elles exposent de petites frictions et réserves. Un fournisseur mince cache ces détails jusqu'à l'achat. Un fournisseur plus évaluable permet aux acheteurs de trouver les bords ordinaires avant de signer.
Cela ne signifie pas que chaque bord est résolu. Cela signifie que l'examen peut passer d'une confiance vague à des tests spécifiques.
L'évaluation finale doit donc être rédigée comme un enregistrement de décision, pas comme un verdict. « PaaS français avec une documentation publique crédible et une surface de support » est une affirmation défendable. « Suffisamment souverain pour toute charge de travail française » ne l'est pas. « Automatisation utile pour le déploiement d'applications et les add-ons gérés » est défendable. « Aucun travail opérationnel laissé au client » ne l'est pas. « Les contrôles réseau incluent la sortie fixe, les options VPN et les groupes réseau privés » est défendable.
« Le dossier public prouve la propriété complète du réseau ou la résilience du routage » ne l'est pas. Cette discipline de vocabulaire est importante car l'achat de cloud est plein de noms attrayants. La décision opérationnelle doit vivre dans des verbes: déployer, restaurer, migrer, révoquer, notifier, escalader, basculer et partir.
Cet enregistrement de décision devrait inclure une revue de preuves datée, car les services cloud changent rapidement. La documentation de Clever Cloud montre une surface produit vivante avec des environnements d'exécution, des versions d'add-ons, des fonctionnalités de console, des fonctionnalités réseau et des mises à jour de sécurité changeants. C'est un signe positif pour un fournisseur de plateforme, mais cela signifie aussi qu'une revue ne peut pas être figée pour toujours.
Un client qui a approuvé une charge de travail l'année dernière devrait encore revoir la région sélectionnée, la version de la base de données, la couverture premium, les contacts de support, l'inventaire des jetons, le routage des alertes et le chemin de migration avant de renouveler une dépendance critique. Si la charge de travail a grandi, ajouté des données réglementées, changé la fréquence de publication ou est devenue plus sensible aux revenus, la revue originale peut ne plus correspondre à l'exposition. La question utile n'est pas de savoir si l'entreprise avait autrefois les bons documents publics.
C'est de savoir si la commande de service actuelle du client et les preuves opérationnelles actuelles correspondent toujours au risque que le client porte.
Pour toute cette prudence, le dossier est plus solide qu'une simple carte d'entreprise. Clever Cloud a une identité juridique française traçable, un produit PaaS documenté, des services de bases de données et de stockage gérés, des emplacements d'infrastructure publics, des conditions de support publiques, des engagements de support premium, un historique de statut, une culture de post-mortem et des contrôles adjacents au réseau. Les preuves soutiennent une entreprise qui peut être évaluée comme une plateforme opérationnelle.
Elles ne soutiennent pas le fait de traiter chaque revendication de souveraineté, d'automatisation, de fiabilité ou de support comme automatiquement satisfaite pour chaque client et chaque région.
La meilleure lecture de CleverCloud n'est donc ni promotionnelle ni dismissive. C'est un acteur de services cloud français dont la valeur réside dans le fait de rendre les opérations d'applications plus reproductibles tout en gardant une histoire juridique et de support locale proche de l'acheteur. Son risque réside au même endroit que toute plateforme gérée: contrôle partagé, contrats spécifiques au service, infrastructure partenaire, dépendances du plan de contrôle, choix de configuration et réponse aux incidents. Le travail de l'acheteur est de garder ces couches séparées. La marque peut ouvrir le dossier. Le dossier doit le fermer.