Expertise Kubernetes : comment choisir son prestataire en 2026

À retenir

• Cinq modèles de prestation répondent « oui » à « faites-vous du Kubernetes ». Ils ne vendent pas la même chose, et trois d’entre eux se tromperont sur votre besoin.
• Le critère qui décide n’est ni le TJM ni la taille : c’est qui écrit réellement le code sur votre cluster, et si cette personne est celle rencontrée en avant-vente.
• Une seule question révèle l’alignement d’intérêts : « que se passe-t-il si nous reprenons l’exploitation dans deux ans ? »

Le marché ne manque pas de prestataires Kubernetes. Il manque de moyens de les distinguer, parce que cinq métiers différents se présentent sous le même mot — « expertise Kubernetes » — et qu’aucun ne vous dira spontanément lequel il exerce.

Ce guide décrit ces cinq modèles, ce que chacun vend réellement, et les questions qui séparent un discours d’une capacité. Il ne compare aucune entreprise nommément : le modèle est le bon niveau d’analyse, parce que deux cabinets du même modèle se ressemblent davantage entre eux que deux cabinets de la même taille.

Transparence : Edixos est un cabinet spécialisé cloud-native — le modèle 3 — et propose aussi une infogérance cloud. Nous relevons donc de deux des cinq modèles décrits, dont celui dont nous pointons le conflit d’intérêts. Posez-nous les mêmes questions qu’aux autres ; nous y répondons en fin d’article.

Les cinq modèles de prestation Kubernetes

1. L’ESN généraliste

Les grandes structures de conseil technologique, de plusieurs centaines à plusieurs milliers de personnes, couvrant cloud, data, cyber et mobile, avec des contrats-cadres chez la plupart des grands comptes.

Ce que vous achetez : de la capacité et de la couverture contractuelle. Si vous devez staffer quarante personnes au prochain trimestre, ou si vos achats n’autorisent que des fournisseurs déjà référencés, c’est le seul modèle praticable.

La contrepartie : un staffing pyramidal. L’architecte qui convainc en avant-vente n’est pas celui qui écrira vos contrôleurs — la marge vient précisément de cet écart. Sur un sujet où la profondeur prime sur le volume, l’écart se paie en mois de dérive.

2. L’infogérant cloud-native

Des acteurs qui construisent la plateforme et l’exploitent ensuite, avec astreinte 24/7 et parfois leur propre cloud souverain.

Ce que vous achetez : la disparition du problème. Pas d’équipe plateforme à recruter, pas d’astreinte à tenir, pas de montée de version à planifier. Pour beaucoup d’organisations c’est la bonne décision, et il faut le dire franchement : si Kubernetes n’est pas un actif stratégique chez vous, l’exploiter vous-même est une dépense sans retour.

La contrepartie : l’alignement des intérêts. Un prestataire dont le revenu récurrent dépend de l’exploitation n’a aucune raison économique de vous rendre autonome. Ce n’est pas de la mauvaise foi, c’est la structure du modèle — et elle se contractualise. Posez la question franchement : « que se passe-t-il, contractuellement et techniquement, si nous voulons reprendre l’exploitation dans deux ans ? »

3. Le cabinet spécialisé cloud-native

Des structures petites à moyennes dont Kubernetes et le platform engineering sont le métier, pas une ligne dans un catalogue de trente expertises.

Ce que vous achetez : de la profondeur et un transfert. Ces équipes écrivent des contrôleurs, publient du code, interviennent sur les CRD, Crossplane, le multi-tenant, le bare-metal — là où les généralistes s’arrêtent. Le livrable normal est une plateforme que vos équipes exploitent ensuite.

La contrepartie : la capacité. Dix personnes ne staffent pas quarante profils, ne passent pas un référencement exigeant trois ans de chiffre d’affaires, et ne couvrent pas votre besoin cyber en parallèle. Si votre contrainte dominante est le volume ou la procédure, ce modèle vous fera perdre du temps.

4. Le freelance

Un expert indépendant, souvent excellent, sans frais de structure.

Ce que vous achetez : une compétence précise, immédiatement. Pour un audit, un déblocage technique ou un renfort dans une équipe déjà constituée, c’est fréquemment le meilleur rapport qualité-prix du marché.

La contrepartie : le bus factor. Aucune continuité, personne pour relire. Un control plane conçu par une seule personne sans revue devient un actif que vous ne pouvez ni faire évoluer ni transmettre. Le risque n’est pas la compétence — elle est souvent au rendez-vous.

5. Le Kubernetes managé de fournisseur

GKE Autopilot, EKS, AKS, OVHcloud Managed Kubernetes, Scaleway Kapsule, avec le support de l’éditeur.

Ce que vous achetez : le plan de contrôle, exploité par le fournisseur, à un coût sans commune mesure avec une prestation humaine. Beaucoup d’organisations n’ont besoin de rien d’autre, et payer un cabinet pour ce qu’un service managé fait déjà est une erreur d’achat classique.

La contrepartie : le support s’arrête à la frontière du produit. Il ne concevra pas votre golden path, n’écrira pas vos abstractions, et ne dira pas non à une équipe qui déploie n’importe quoi. Tout ce qui décide de l’adoption d’une plateforme reste chez vous.

Le tableau de décision

Ce tableau décrit des modèles, jamais des entreprises nommées. Une même structure peut relever de deux modèles — Edixos compris, qui fait du conseil et de l’infogérance. Dans ce cas, demandez lequel des deux porte la marge.

Les sept questions à poser en avant-vente

1. « Qui, nommément, interviendra — et puis-je lui parler avant de signer ? » La seule question dont la réponse ne se prépare pas. Un refus poli, ou un « nous confirmerons le staffing après la signature », est déjà une réponse.

2. « Montrez-moi du code public. » Contrôleurs, opérateurs, providers Crossplane, contributions CNCF, charts Helm maintenues. Une expertise Kubernetes réelle laisse des traces publiques ; une expertise de slide n’en laisse aucune.

3. « Racontez-moi un incident de production que vous avez causé. » Question déloyale, et c’est le but. Une équipe qui a exploité des clusters en a une, la raconte précisément, et explique ce qu’elle a changé ensuite. Une équipe qui n’en a pas n’a jamais été de garde.

4. « Quel est le livrable exact, et à quoi ressemble la fin de mission ? » Une prestation plateforme sans jalon de sortie devient de la régie déguisée. Exigez le dépôt Git, la documentation, les runbooks, une session de reprise, et une date.

5. « Que se passe-t-il si nous reprenons l’exploitation dans deux ans ? » La question qui révèle l’alignement mieux que n’importe quelle clause de réversibilité.

6. « Sur quoi n’êtes-vous pas bons ? » Un prestataire qui prétend tout couvrir se disqualifie. Sur un périmètre aussi vaste que le cloud-native, l’absence de frontière avouée signifie l’absence de spécialité.

7. « Combien coûte le livrable, pas la journée ? » Un TJM isolé n’informe sur rien. Un profil moins cher qui met trois fois plus longtemps coûte davantage, et vous fait perdre un trimestre en plus. Le calcul complet est détaillé dans ce que chaque modèle coûte vraiment.

Cinq signaux d’alerte

• Un niveau de partenariat cloud présenté comme une expertise Kubernetes. Un partenariat mesure un volume de revente, pas une compétence d’ingénierie.
• Le CV du senior en annexe, sans engagement de staffing dans le contrat.
• Aucune trace publique : ni dépôt, ni conférence, ni écrit technique, ni post-mortem. Dans un écosystème aussi ouvert que la CNCF, c’est anormal.
• Une proposition qui commence par un outil — « nous allons déployer telle plateforme » — avant d’avoir compris votre golden path.
• Un devis sans phase de découverte. Personne ne chiffre une migration Kubernetes sans avoir regardé l’existant. Un chiffrage immédiat signifie qu’un avenant est déjà prévu.

Mener la sélection en trois temps

1. Qualifiez le modèle avant les entreprises. Une demi-journée en interne : avons-nous besoin de capacité, d’exploitation, de profondeur, d’un renfort, ou simplement d’un cluster managé ? Cette étape élimine les deux tiers du marché et vous évite de comparer des offres incomparables.
2. Achetez un audit avant d’acheter un projet. Deux à cinq jours d’audit d’architecture chez deux prestataires du même modèle coûtent une fraction du projet et montrent comment ils raisonnent. C’est le seul essai routier disponible.
3. Contractualisez la sortie dès le départ. Dépôt chez vous, documentation en livrable, session de reprise datée. Un prestataire aligné acceptera sans discuter.

Edixos face à sa propre grille

Nous sommes le modèle 3 : un cabinet restreint et senior, qui construit des control planes Kubernetes, des plateformes internes en golden path, des API Crossplane réutilisables et des agents SRE. Voici nos réponses aux sept questions, dans l’ordre.

• Qui interviendra ? Des ingénieurs nommés, avec parcours et certifications publiés sur la page équipe. Vous parlez dès le premier échange à la personne qui écrira le code : il n’y a pas de banc de profils derrière.
• Du code public ? Un provider Crossplane pour OVHcloud que nous maintenons, plus de 15 000 téléchargements, en production pour des ministères sociaux. Du travail de flotte sur Sveltos, des contributions à l’écosystème Tilt.
• Un incident de production ? Nos retours de terrain sur Talos et le bare-metal et sur une politique réseau eBPF restée obsolète sur GKE sont publiés, causes et corrections comprises.
• De l’ancienneté ? Kubernetes en production depuis la version 1.2, en 2015 — avant les CRD, avant les offres managées.
• Des systèmes réels ? Plus de mille applications migrées pour un constructeur automobile, plus de 150 CRD pour un PaaS sur mesure, des plateformes self-service en production.
• La fin de mission ? Dépôt, documentation et runbooks à vous depuis le premier jour, session de reprise datée au contrat.
• Sur quoi nous ne sommes pas bons ? Le volume. Nous ne staffons pas quarante profils, nous ne passerons pas un référencement achats lourd, et pour une exploitation à très grande échelle sur cloud souverain propriétaire, un autre modèle vous servira mieux. Nous le disons au premier rendez-vous plutôt que de vous coûter un trimestre.

Et pour répondre à notre propre question d’alignement : nous vendons aussi de l’infogérance, sous le nom Infogérance Cloud. Le conflit d’intérêts décrit au modèle 2 nous concerne donc aussi. Ce que vous pouvez vérifier au contrat plutôt que nous croire sur parole : elle est souscrite séparément, jamais comme la suite obligée d’une construction, et tout ce qu’il faut pour vous en passer vous appartient dès le premier jour.

La prochaine étape la moins risquée : un audit d’architecture de deux à cinq jours. Vous repartez avec un état des lieux exploitable même si vous ne travaillez jamais avec nous ensuite.

Réserver un échange · conseil cloud-native · platform engineering · Crossplane