Résumé

  • Deutsche Telekom et Codesphere préparent des essais sur T Cloud pour des applications exigeantes en souveraineté, en calcul et en stockage.
  • Une infrastructure interchangeable ne rend pas automatiquement interchangeable le logiciel qui organise son utilisation.

Pour vendre une nouvelle infrastructure, il peut être utile de ne pas demander au client de tout quitter. Le projet de Deutsche Telekom avec Codesphere suit cette logique : permettre à une entreprise de conserver plusieurs environnements, tout en rendant T Cloud plus facile à intégrer. L'enjeu commercial n'est pas seulement de savoir où les applications tourneront. Il est aussi de déterminer ce qui restera commun lorsqu'elles changeront de destination.

Dans son communiqué du 10 septembre, diffusé par Public Technologies, Deutsche Telekom indique que Codesphere fonctionnera sur T Cloud comme une couche technique reliant infrastructure souveraine, environnements des grands fournisseurs mondiaux et centres de données internes. Les partenaires comptent identifier des applications adaptées puis les tester sur T Cloud. Ils visent d'abord des besoins qui associent souveraineté élevée et capacités importantes de calcul et de stockage.

Le futur employé dans l'annonce compte. Aucun projet client achevé, tarif général ou tableau complet de compatibilité ne vient encore démontrer la portée opérationnelle de cette proposition. Un programme d'essais ne constitue pas une preuve de migration réussie à l'échelle d'un service métier.

Le mélange des infrastructures n'est d'ailleurs pas nouveau dans la stratégie de T Cloud. Sa présentation officielle de septembre 2025 associait déjà les infrastructures propres de Telekom, des offres de fournisseurs mondiaux et des services d'accompagnement à la migration. Codesphere apporte une réponse envisagée à la question suivante : comment exploiter les applications dans cet ensemble hétérogène sans reconstruire chaque fois les mêmes procédures ?

Sa documentation technique décrit des espaces de travail pour les applications, des ressources de calcul mutualisées et du stockage réseau. Elle mentionne des déploiements sur Kubernetes administré, machines virtuelles ou serveurs physiques, ainsi que plusieurs modes de gestion. Certains services administrés reposent sur des frameworks ouverts et des couches d'abstraction. Ce sont les capacités générales annoncées par le fournisseur, pas les résultats de validation de toutes les configurations du partenariat.

La standardisation peut réduire le travail nécessaire pour utiliser une deuxième infrastructure. Mais démarrer une application ailleurs n'est pas encore déplacer le service dont dépend une entreprise. Les données en cours, les droits d'accès, les connexions réseau et les procédures de reprise doivent suivre ou être réorganisés. La portabilité utile s'apprécie sur cet ensemble, pas sur la seule réussite d'un déploiement.

Un autre examen concerne le logiciel commun. Sur sa page consacrée à la souveraineté, Codesphere indique distribuer ses versions à support de longue durée sous une Source Available License ; l'ouverture de fonctionnalités en open source figure parmi ses projets futurs. Il serait donc incorrect de déduire des composants ouverts que toute la plateforme est déjà open source. L'accès au code ne suffit pas non plus à établir les droits de modification, de redistribution ou de maintenance autonome : il faut lire les conditions applicables.

La proposition peut ainsi élargir le choix d'infrastructure tout en renforçant l'importance de la couche d'exploitation partagée. Pour T Cloud, une entrée moins engageante pourrait faciliter l'adoption. Pour le client, le bénéfice dépendra de la capacité à distinguer ce qui se déplace réellement de ce qui reste attaché à un fournisseur de logiciel ou à une équipe de support.