Le cloud que vous connaissez déjà.
La souveraineté qu'on vous a promise.

Cela signifie que la plateforme est construite et en fonctionnement — bare metal, stockage, calcul, réseau, Terraform, Kubernetes, services de données et usine à tenants sont tous en service dans nos propres centres de données — mais que l'accès est délibérément limité à un petit nombre de clients fondateurs pendant que nous montons en capacité. Vous obtenez un accès direct aux ingénieurs qui ont construit la plateforme, une influence sur nos prochaines priorités et des conditions commerciales préférentielles. Ce qui est limité, c'est le nombre de tenants que nous intégrons par mois, pas l'étendue des capacités.

Notre cloud privé est une plateforme dédiée, conçue, dimensionnée et exploitée pour une seule organisation. IG1 Cloud est un cloud public mutualisé et multi-tenant : en libre-service, piloté par API, facturé à la seconde, avec une capacité que vous consommez plutôt que vous ne provisionnez. Beaucoup de clients utiliseront les deux — une plateforme privée dédiée pour les charges régulées ou stables, et IG1 Cloud pour la capacité élastique, les environnements de développement et les nouveaux projets. Les deux sont reliés sur le même tissu réseau.

Votre structure, vos modules, vos pipelines et vos workflows se transposent directement ; les types de ressources changent, comme ils changeraient entre deux providers quelconques. En pratique, les migrations ressemblent à un changement de provider plus un exercice de correspondance sur les types d'instances, le réseau et les classes de stockage — un travail que nos équipes font avec vous plutôt qu'elles ne vous laissent en devoirs. L'état distant peut vivre sur notre propre point d'accès compatible S3, pour que votre code d'infrastructure cesse de dépendre du cloud dont vous cherchez précisément à devenir indépendant.

Cela signifie que la plateforme livre un serveur MCP exposant 149 opérations cloud comme des outils qu'un agent IA peut appeler — lister des instances, en créer, mettre un cluster à l'échelle, récupérer un kubeconfig, lire la dépense du mois. La sûreté ne repose pas sur la bonne conduite de l'agent. Chaque identifiant est émis à l'un de trois niveaux — lecture seule, opération ou destructif — et la plateforme applique ce niveau à chaque requête : un agent à qui vous avez donné une clé d'opération ne peut rien supprimer, quelle que soit la façon dont on le sollicite. Il ne peut pas non plus s'émettre une clé plus forte : forger un identifiant suppose de détenir déjà le niveau que l'on distribue. Les séquences multi-étapes sont limitées à une liste fixe d'opérations autorisées, jamais du code arbitraire ni un accès shell, et reviennent en arrière en cas d'échec. Chaque appel est écrit dans votre journal d'audit avec les paramètres fournis mais jamais leurs valeurs. Et comme le serveur MCP tourne dans notre périmètre et ne détient aucune identité propre — il transmet votre identifiant à chaque appel — aucun détail d'infrastructure n'est envoyé à un service tiers.

IG1 Cloud tourne sur des serveurs que nous avons achetés, dans des centres de données que nous louons et exploitons, reliés à des réseaux que nous gérons, avec un plan de contrôle et une organisation de support tenus par nos propres ingénieurs en France. Il n'y a pas de société mère étrangère, aucune entité hors UE dans la chaîne de traitement, et aucune dépendance à un hyperscaler pour la plateforme elle-même. C'est ce qui nous permet de dire que le CLOUD Act américain n'atteint ni vos données ni votre plan de contrôle — une affirmation qu'une région européenne d'un cloud américain ne peut pas faire, où que se trouvent physiquement les disques.

Oui, sans réserve. Nous sommes un opérateur agnostique au cloud depuis 25 ans et nous comptons le rester — notre pratique cloud public continue exactement comme avant. IG1 Cloud est une option supplémentaire pour les charges où la souveraineté, l'économie de la sortie de données ou la prévisibilité comptent le plus. Si AWS est la bonne réponse pour une charge donnée, nous continuerons à vous le dire ; posséder un cloud n'a pas changé notre façon de conseiller.

Une politique publiée, et un build qui l'applique. De nouveaux points d'accès, champs, commandes et outils d'agents peuvent apparaître dans n'importe quelle version — vos appels existants continuent de fonctionner, car les clients sont censés ignorer ce qu'ils ne reconnaissent pas. Rien n'est jamais retiré qu'à une version majeure, et l'ancienne forme continue de servir pendant une version complète de recouvrement après l'annonce du retrait. Ce que la plupart des fournisseurs taisent, c'est que nos messages d'erreur sont eux aussi versionnés : le texte de refus sur lequel vos scripts et vos agents branchent ne change pas en silence. Et comme la ligne de commande, le provider Terraform et les SDK sont générés depuis la même description que sert l'API plutôt qu'écrits à la main contre elle, un changement qui les désynchroniserait fait échouer notre build avant de pouvoir vous atteindre.

L'intégration crée un projet réel et dédié avec ses propres quotas et sa propre identité — pas un bac à sable partagé avec une étiquette dessus. Ensuite, le projet sur lequel vos requêtes agissent est résolu par la plateforme depuis votre jeton, à chaque appel. Il n'existe délibérément aucun paramètre ni en-tête qu'un client puisse envoyer pour se pointer vers un autre projet, et un identifiant appartenant à un autre client répond « introuvable » plutôt que « interdit », si bien que la plateforme ne confirme jamais l'existence de la ressource d'un autre. Cette résolution se produit de notre côté de l'API, ce qui signifie qu'elle vaut à l'identique pour vos ingénieurs, vos pipelines et vos agents IA.

Les deux, depuis le 25 août 2026. La porte d'entrée publique est ouverte : une application publiée via l'edge est joignable depuis Internet, et un domaine qui vous appartient reçoit un certificat Let's Encrypt publiquement reconnu, commandé automatiquement dès que le nom résout chez nous — vous revendiquez le domaine, vous le prouvez par un enregistrement TXT, et alors seulement une requête est routée. Une frontière est délibérée et mérite d'être connue avant un proof of concept : le nom d'hôte que la plateforme vous génère est un nom interne portant un certificat interne, donc tout ce que vous voulez sur Internet public tourne sous votre propre domaine. Et votre parc lui-même — instances, sous-réseaux privés, clusters Kubernetes — se joint toujours par connectivité privée, un tunnel site à site depuis votre centre de données ou un VPN client pour les ingénieurs, ce qui est de toute façon la façon dont la plupart des clients fondateurs exploitent leur production. L'edge publie des applications ; ce n'est pas une porte vers votre réseau.

Voici la réponse honnête et actuelle, et elle n'est délibérément pas marketing. Vos données sont écrites trois fois sur trois machines distinctes et se réparent automatiquement, et vous pouvez prendre des instantanés de vos propres volumes depuis n'importe quelle surface — un disque en panne ou un serveur mort ne perd donc rien. Ce contre quoi trois copies ne protègent pas , c'est une suppression, une corruption ou un rançongiciel, car ceux-là se répliquent fidèlement. Le service de sauvegarde hors cluster — sauvegardes de volumes, réplication objet et sauvegardes de bases managées vers un stockage extérieur au cluster — est la phase où nous sommes, matériel chiffré et demandé. Entre-temps, l'état de la plateforme elle-même est sauvegardé deux fois par jour et fait l'objet d'un exercice de restauration hebdomadaire contre le système en production, et chaque tenant de la préversion sait exactement ce qui est protégé avant de poser quoi que ce soit sur la plateforme. Quand le service pour les données clientes arrivera, nous chronométrerons une reprise complète et publierons le chiffre mesuré plutôt qu'un chiffre souhaité.

L'objectif de livraison est de moins de quinze minutes entre l'appel d'API et un kubeconfig, avec le réseau de conteneurs, le contrôleur cloud et une classe de stockage adossée à Ceph déjà installés — un cluster dont les nœuds rejoignent mais ne passent jamais prêts est l'échec classique du libre-service, et c'est celui que nous avons éliminé par conception. Le plan de contrôle tourne comme un processus managé sur notre plateforme plutôt que comme des machines virtuelles que vous louez, ce qui rend un cluster d'entrée de gamme économique ; les workers sont des instances ordinaires dans votre propre projet, sur votre propre quota. Et la ligne de responsabilité est énoncée dans la conception plutôt que découverte pendant un incident : vous êtes cluster-admin sur vos workers, nous garantissons la plateforme, le réseau et la santé de la machine en dessous, et si votre propre changement casse un worker, ce que nous vous devons est un redéploiement rapide plutôt que la réparation d'un nœud que vous avez modifié.

Par défaut, rien — tant que vous ne l'avez pas approuvé. L'accès inter-tenant était jusqu'ici ce qu'il est chez tout fournisseur de cloud : permanent, unilatéral et invisible. Nous l'avons supprimé et reconstruit comme un réglage qui vous appartient. Vous choisissez l'un de trois modes : chaque demande approuvée par un propriétaire de votre côté (le mode par défaut), un accès permanent avec une portée et une expiration que vous fixez si vous préférez que nous gérions simplement les choses, ou un refus pur et simple — un choix légitime, dont nous annonçons la conséquence d'emblée : nous ne pourrons pas investiguer un incident à l'intérieur de votre tenancy. Les autorisations sont bornées dans le temps. Le bris de glace coûte délibérément cher : refusé d'emblée sous le mode « refusé », bien plus court qu'une autorisation approuvée, et il exige un motif et une référence de ticket avant de s'annoncer à vous alors qu'il est encore actif. Chaque étape est publiée sur une piste d'audit estampillée à votre tenancy, que vous pouvez lire sans rôle d'administrateur. Au titre du RGPD, vous êtes le responsable de traitement et nous sommes un sous-traitant agissant sur instructions documentées ; voici cette phrase transformée en interrupteur dans votre console. Les travaux d'infrastructure qui désignent un hôte physique plutôt qu'un tenant — santé des nœuds, état de l'hyperviseur, santé du stockage — restent hors du périmètre de consentement, parce que le consentement gouverne vos données, pas notre salle machine.

Pas encore, et nous préférons le dire plutôt que laisser un schéma le sous-entendre. IG1 Cloud sert aujourd'hui depuis Equinix PA6 en région parisienne, où chaque octet est écrit trois fois sur trois machines distinctes : un disque en panne ou un serveur perdu est donc un non-événement. Une seconde zone de disponibilité à OPCore PAR3 — un site qu'IG1 exploite déjà pour le cloud privé et l'infrastructure managée — est la phase de construction qui transforme un site résilient en une région résiliente, avec placement et réplication inter-zones. Si une charge a besoin de résilience multi-site avant cette échéance, dites-le tôt : nos pratiques de cloud privé et d'infrastructure managée tournent déjà sur nos trois sites parisiens, et la réponse honnête pour cette charge aujourd'hui peut être l'une d'elles plutôt qu'IG1 Cloud.

Oui aux deux, et c'est la partie que la plupart des alternatives souveraines laissent de côté. Un projet est ici ce qu'un compte est sur AWS : ses propres quotas, son propre réseau, sa propre isolation. Vous les créez vous-même jusqu'au plafond de votre palier — vérifié contre votre décompte réel avant toute existence, et refusé plutôt qu'autorisé si ce plafond ne peut pas être lu. Vous les organisez ensuite en arborescence et y attachez des politiques de refus qui héritent vers le bas : un niveau de privilège maximal qui se compose par la valeur la plus stricte, des refus qui s'accumulent, et une branche qui peut resserrer ce qu'elle a hérité mais jamais l'élargir. C'est la sémantique d'AWS Organizations sans la facture AWS. Deux détails délibérés : supprimer un projet n'est pas un appel d'API client, parce que cela détruit tout ce qu'il contient et mérite un humain ; et n'importe quel identifiant, y compris en lecture seule, peut demander sous quel niveau il se trouve effectivement et quelle politique l'a modifié — un garde-fou que vos ingénieurs ne peuvent pas inspecter est un garde-fou qu'ils contourneront.

À cause de la façon dont elle est construite, qui est le seul argument qui vaille à ce stade. Rien ne compte comme terminé ici parce que ça a compilé ou parce que les tests sont passés : c'est terminé quand c'est déployé et qu'un contrôle automatisé a relu la plateforme en fonctionnement et confirmé le comportement — les tableaux de bord verts peuvent mentir, une relecture en direct, non. Il y a des centaines de contrôles automatisés, une voie hors ligne d'environ deux mille tests figée pour qu'elle ne puisse pas rétrécir en silence, et plus de trente gardes anti-dérive dont l'unique rôle est d'affirmer que deux copies du même fait concordent toujours. Chaque leçon durement acquise devient un post-mortem numéroté — symptôme, cause racine, correctif, règle — et les récurrents sont promus en gardes automatisés pour que la même erreur ne puisse pas se reproduire deux fois en silence. Toute la plateforme se reconstruit depuis son dépôt, et elle a été reconstruite plusieurs fois, ce qui est la seule vraie preuve qu'une plateforme est automatisée plutôt qu'assemblée à la main. Et la discipline est visible dans ce que nous publions : tout sur cette page est relevé depuis le système en production, et ce qui n'est pas prêt y est nommé.