DEV Community: Mehdi Chilla

À partir de quand faut-il une équipe plateforme ? Ce que je ferais avec 20, 100 ou 500 développeurs, et pourquoi Kubernetes doit être pensé comme un service interne.

Mehdi Chilla — Wed, 21 Oct 2026 10:13:36 +0000

Mehdi Chilla

Oct 21

Kubernetes : et si le vrai problème n'était pas technique ?

#devops #kubernetes #platformengineering #architecture

14 min read

Kubernetes : et si le vrai problème n'était pas technique ?

Mehdi Chilla — Wed, 21 Oct 2026 10:03:30 +0000

Une équipe veut déployer une nouvelle API sur Kubernetes.

Le code est prêt, les tests passent. Mais avant de déployer, il reste quelques détails : demander un namespace, trouver comment injecter les secrets, adapter la pipeline CI/CD, ouvrir les bons flux réseau et comprendre où consulter les logs en cas de problème.

Rien d'insurmontable. Sauf que ces « quelques détails » reviennent à chaque nouveau projet.

C'est souvent à ce moment-là qu'on se demande s'il ne faudrait pas créer une équipe plateforme. Une équipe qui prendrait en charge Kubernetes, les pipelines et tout ce qui gravite autour.

L'idée se défend. Mais elle peut aussi conduire à déplacer le problème : au lieu de perdre du temps à configurer leur environnement, les développeurs en perdent à attendre une autre équipe.

Pour moi, la question n'est donc pas seulement « qui administre Kubernetes ? », mais « comment éviter que Kubernetes complique inutilement le travail des équipes ? »

Je vais prendre trois tailles d'organisation — 20, 100 et 500 développeurs — puis regarder ce qui change lorsqu'on traite la plateforme comme un produit interne. Ce sont des scénarios, pas des ratios à appliquer à la lettre.

Avant de parler d'équipe plateforme, parlons de ce qu'elle doit fournir

Un cluster à jour, des nœuds correctement dimensionnés, un réseau maîtrisé, une politique de sécurité cohérente : c'est indispensable. Quelqu'un doit s'en occuper.

Mais maintenir Kubernetes et fournir une plateforme de développement, ce n'est pas exactement le même métier.

Dans le premier cas, on s'assure que l'infrastructure fonctionne. Dans le second, on s'intéresse aussi à la façon dont les équipes l'utilisent : comment elles créent un service, le déploient, diagnostiquent un incident, récupèrent un secret ou appliquent une mise à jour.

Les deux sujets sont liés, et je ne vois aucun intérêt à les opposer. Une même équipe peut très bien porter les deux. En revanche, il faut être clair sur ce qu'on attend d'elle. Si son backlog ne contient que des montées de version de clusters, des demandes de droits et des interventions sur incident, on parle surtout d'exploitation. Pas encore d'une plateforme pensée pour ses utilisateurs.

La CNCF décrit les plateformes internes comme un ensemble de capacités mises à disposition d'autres équipes pour faciliter leur travail [1]. L'idée est simple : mutualiser ce qui a du sens, sans obliger chacun à comprendre toute la mécanique derrière.

Trois façons de s'organiser, avec des compromis différents

On présente parfois l'organisation en équipe plateforme comme l'aboutissement naturel de toute démarche DevOps. Je suis moins catégorique. Certaines entreprises n'en ont pas besoin, et d'autres auraient surtout besoin de simplifier leur fonctionnement avant de changer leur organigramme.

Premier modèle : chaque équipe se débrouille. Les développeurs maîtrisent leur application et une bonne partie de sa chaîne de déploiement. L'autonomie est forte. Avec peu d'équipes, c'est souvent efficace. Le revers apparaît quand chacun maintient ses propres templates Helm, ses variables CI et sa façon de gérer les secrets. Le même problème est résolu plusieurs fois, avec quelques variantes qui finissent par coûter cher.

Deuxième modèle : une équipe DevOps ou infrastructure centrale. Les compétences sont regroupées, les standards deviennent plus cohérents et la gestion des clusters est mieux maîtrisée. C'est souvent le modèle le plus pragmatique pour démarrer. Il a toutefois un défaut classique : si créer un environnement ou modifier une pipeline nécessite systématiquement un ticket, l'équipe centrale finit par limiter le débit de toutes les autres.

Troisième modèle : une équipe plateforme avec une logique produit. Elle ne se contente pas d'exécuter des demandes. Elle construit des services réutilisables : starters, pipelines, accès aux environnements, observabilité, déploiement en self-service. Les équipes applicatives utilisent ces capacités sans avoir à demander une intervention à chaque étape.

Le troisième modèle n'est pas automatiquement meilleur. Il demande du temps, du recul et une vraie capacité à dire non à certaines fonctionnalités. Une équipe plateforme peut elle aussi produire beaucoup de YAML et très peu de valeur.

Les principes de Team Topologies aident à lire ce problème : les interactions entre équipes et la charge cognitive comptent autant que la répartition technique des responsabilités [3].

Ce que je ferais avec 20, 100 ou 500 développeurs

Trois organisations possibles. Les effectifs mentionnés sont des hypothèses de travail, pas des préconisations chiffrées de la CNCF.

Avec 20 développeurs : je ne créerais pas une équipe dédiée par principe

Imaginons deux ou trois équipes applicatives. Je commencerais par identifier un référent Kubernetes/DevOps, avec du temps officiellement réservé pour les sujets transverses, et surtout quelqu'un capable de prendre le relais.

Ce point mérite d'être souligné : « on a un développeur qui connaît bien Kubernetes » n'est pas un modèle d'exploitation. S'il doit gérer les incidents, les mises à jour et les demandes de toutes les équipes en plus de son travail habituel, le risque est de concentrer toute la connaissance sur une seule personne.

Je viserais une capacité de l'ordre de 0,5 à 1 ETP pour les besoins communs, à ajuster selon l'exposition en production, le support attendu et les contraintes de sécurité.

À cette taille, les bons investissements sont assez terre à terre : des pipelines réutilisables, un ou deux starters maintenus, de l'Infrastructure as Code, une gestion propre des secrets, quelques dashboards compréhensibles et une documentation que quelqu'un relit vraiment.

Si tout cela tient dans la forge logicielle et quelques dépôts bien organisés, je ne vois pas l'intérêt d'installer un portail supplémentaire.

Avec 100 développeurs : une équipe plateforme commence à avoir du sens

Une dizaine d'équipes produit, c'est déjà beaucoup d'occasions de refaire les mêmes choses. Le moindre changement transversal peut provoquer dix échanges, dix adaptations et dix façons différentes de contourner un problème.

C'est à ce niveau que je regarderais sérieusement une équipe de 3 à 5 personnes, avec des compétences Kubernetes, cloud, CI/CD et développement. Le rôle de Product Owner peut être assuré par le responsable de cette équipe, au moins au début. Les fonctions sécurité et architecture doivent être associées aux choix structurants, sans devenir une validation manuelle de chaque déploiement.

Je préfère une petite équipe capable de prendre en charge un parcours de bout en bout — créer une API, la tester, la livrer et l'observer — plutôt que trois spécialistes qui se renvoient les sujets selon l'outil concerné.

Il faut aussi être lucide sur la charge d'exploitation. Une équipe de quatre personnes ne garantit pas par magie une astreinte viable 24 h/24. Avant de promettre un service permanent, on doit définir les horaires de support, les responsabilités en incident et les engagements réellement tenables.

Avec 500 développeurs : je structurerais plusieurs capacités, sans tout centraliser

À cette échelle, il devient difficile de traiter Kubernetes comme un simple sujet d'administration de clusters. Les besoins se multiplient : réseau, IAM, capacité, CI/CD, politiques de sécurité, observabilité, coûts, environnements de test, accompagnement des équipes.

Je verrais plutôt un domaine Platform Engineering avec une responsabilité produit commune et plusieurs compétences identifiables :

Cloud & Kubernetes, pour les clusters et les fondations techniques ;
Developer Experience & Delivery, pour la forge, les starters, les pipelines et les golden paths ;
Observabilité & fiabilité des services communs, pour les capacités de diagnostic et les engagements de la plateforme.

Un Platform Product Lead assure la cohérence de l'offre et les arbitrages. La sécurité, l'architecture et le FinOps restent des partenaires réguliers, même s'ils n'appartiennent pas hiérarchiquement à ce domaine.

Un périmètre de 12 à 20 ETP peut servir de point de départ à la discussion, mais il serait trompeur d'en faire un ratio. Une entreprise très réglementée, multi-cloud et soumise à de fortes astreintes n'aura pas les mêmes besoins qu'une autre dont la majorité des applications utilisent quelques services managés standardisés.

Je ne chercherais pas non plus à faire entrer de force l'observabilité, l'API Management ou la sécurité dans une seule équipe géante. Des équipes expertes peuvent exposer leurs services dans un catalogue commun. Ce qui importe, c'est que les développeurs sachent où trouver le service et comment l'utiliser.

Développeurs	Organisation que j'envisagerais	Capacité indicative
20	Référent transverse et relais technique	0,5 à 1 ETP
100	Petite équipe plateforme dédiée	3 à 5 ETP
500	Domaine plateforme structuré, éventuellement fédéré	12 à 20 ETP

Ces chiffres donnent un cadre de réflexion, pas un dimensionnement prêt à appliquer. Je regarderais d'abord le nombre de services, la criticité de la production, les interventions manuelles et les dépendances entre équipes.

Kubernetes comme produit interne : oui, mais pas comme prétexte pour créer un portail

Le point de départ d'une plateforme produit, ce sont les usages. Pas la liste des outils à installer.

Je suis convaincu de l'intérêt d'une approche produit, mais le mot « produit » est parfois utilisé un peu vite.

Créer un portail, baptiser quelqu'un Platform Product Owner et afficher une roadmap ne suffit pas. Il faut accepter de considérer les équipes de développement comme des utilisateurs avec des besoins parfois contradictoires.

Une équipe voudra davantage de liberté sur son déploiement. Une autre réclamera un parcours entièrement standardisé. La sécurité imposera certains contrôles. L'exploitation cherchera à limiter les variantes. Ce sont de vrais arbitrages, pas de simples tickets à classer.

Le Product Ownership consiste notamment à choisir ce qu'on ne va pas développer tout de suite.

Prenons un exemple. Une équipe demande une option avancée de déploiement dont elle est la seule utilisatrice. Dans le même temps, huit équipes passent régulièrement par le support pour comprendre leurs erreurs de pipeline. Il est tout à fait défendable de traiter d'abord la seconde demande : elle supprime une friction répétée et touche davantage de monde.

Et cela se voit dans la roadmap. « Mettre en place Backstage » ou « migrer vers Argo CD » sont des chantiers techniques ; ils peuvent être nécessaires, mais ils ne disent pas à eux seuls ce qui s'améliorera pour les développeurs.

Je préfère des objectifs formulés autrement :

permettre à une équipe de créer une API avec son pipeline et son observabilité sans intervention manuelle ;
rendre les erreurs de déploiement assez explicites pour être traitées par l'équipe applicative ;
réduire les demandes récurrentes d'accès ou de création d'environnement.

Ensuite seulement, on choisit les outils.

C'est également l'esprit des travaux de la CNCF sur le Product Thinking for Platforms et son modèle de maturité [2, 4]. Une plateforme, même interne, doit évoluer à partir des usages et des retours.

Un golden path, concrètement, ça change quoi ?

Exemple de parcours standard pour une nouvelle API. Il ne suppose pas de portail spécifique.

Prenons un développeur qui démarre une API Spring Boot.

Sans parcours commun, il peut passer du temps à retrouver un bon starter, recopier un .gitlab-ci.yml, identifier le registre d'images, comprendre les conventions de déploiement et retrouver l'équipe qui gère l'observabilité.

Avec un golden path bien conçu, il démarre d'un modèle maintenu. Le dépôt contient les conventions de développement ; les tests et analyses de sécurité sont déjà branchés ; la pipeline construit l'image, puis déploie sur un environnement autorisé ; les logs et les métriques sont disponibles au même endroit que pour les autres applications.

On n'a pas supprimé la complexité technique. On a évité de la faire redécouvrir à chaque projet.

Une solution comme Backstage peut fournir une interface intéressante grâce à ses Software Templates [6]. Mais un ensemble de starters GitLab, une CLI ou quelques templates bien documentés peuvent rendre le même service. Je ne commencerais pas par choisir le portail. Je commencerais par rendre le parcours fiable.

Le catalogue de services prend alors tout son sens : il explique ce qui est disponible, comment y accéder et qui en est responsable.

Capacité	Ce que l'équipe applicative peut faire
Starter API	Créer un projet conforme aux conventions
CI/CD standard	Tester, contrôler, construire et livrer
Déploiement Kubernetes	Déployer sur un environnement autorisé
Gestion des secrets	Consommer des secrets sans les mettre dans le code
Observabilité	Consulter logs, métriques, traces et tableaux de bord
Provisionnement de données	Obtenir une base ou une ressource selon une offre validée

Chaque entrée doit avoir une documentation utile, un propriétaire identifié et des règles de support claires. Sinon le « catalogue » devient vite une page de liens que plus personne ne consulte.

Je tiens aussi à un point : le golden path doit être le chemin recommandé, pas une impasse lorsqu'on a un besoin différent. Les exceptions peuvent être cadrées, documentées, voire soumises à validation. Mais si le standard impose de contourner la plateforme pour traiter tous les cas un peu particuliers, il manque quelque chose au produit.

Qui prend la responsabilité lorsque ça casse ?

Il faut distinguer le service plateforme du service applicatif, notamment pendant les incidents.

C'est un sujet qu'on règle trop souvent après le premier incident sérieux.

Quand une application ne répond plus, qui intervient ? L'équipe plateforme parce que le pod tourne sur Kubernetes ? L'équipe de développement parce qu'elle a écrit le code ? Les Ops parce que c'est la production ?

La réponse dépend de la cause et du modèle d'exploitation, mais il faut se mettre d'accord avant l'incident. Une fuite mémoire dans l'application n'appelle pas la même réponse qu'une panne du réseau du cluster.

Voici une matrice RACI qui peut servir de base de discussion. Elle est volontairement simplifiée : R réalise, A porte la responsabilité finale, C est consulté, I est informé. R/A réunit réalisation et responsabilité finale.

Activité	Plateforme	Équipes produit	Sécurité	SRE / Ops	Direction IT
Cycle de vie des clusters	R/A	I	C	C	I
Politique de sécurité commune	R	C	A	C	I
Starters et golden paths	R/A	C	C	C	I
Déploiement applicatif	C	R/A	C	I	I
Fiabilité d'une application	C	R/A	I	C	I
Incident d'infrastructure	R/A	C	C	R	I
Roadmap de la plateforme	R/A	C	C	C	I
Arbitrage budgétaire majeur	R	C	C	C	A

Cette répartition ne remplace évidemment ni les contrats de service ni les astreintes. Elle aide surtout à rendre visibles les ambiguïtés.

La règle que je retiendrais : l'équipe plateforme est responsable de ses services communs ; les équipes applicatives restent responsables de leurs applications. Les deux doivent collaborer pour diagnostiquer ce qui se passe à la frontière.

Les métriques qui m'intéresseraient vraiment

La disponibilité des clusters, les consommations CPU et mémoire ou le coût de l'infrastructure restent utiles. Mais je me méfierais d'une équipe plateforme qui n'a que ces indicateurs à présenter.

J'aimerais savoir combien de temps il faut pour passer d'un nouveau dépôt à une première application déployée. Combien d'opérations courantes se font sans ticket. Combien d'équipes utilisent réellement les starters proposés. Et surtout, combien de temps elles perdent quand le chemin nominal ne fonctionne plus.

Il faut croiser ces données avec des mesures de fiabilité et de livraison, notamment celles popularisées par DORA [5, 7]. Et les compléter par des retours qualitatifs : un questionnaire court ou quelques échanges réguliers avec les développeurs peuvent révéler ce que les dashboards ne montrent pas.

Attention aux indicateurs faciles à embellir. Si l'utilisation du starter est obligatoire, afficher 100 % d'adoption ne démontre pas sa qualité. Si les tickets diminuent parce que les équipes ont abandonné l'idée de demander de l'aide, ce n'est pas davantage un progrès.

Une plateforme réussie n'est pas celle dont personne ne se plaint. C'est celle dont on comprend les problèmes et qu'on améliore en fonction de l'usage réel.

Par où commencer ? Une feuille de route sur six mois

Un premier parcours opérationnel vaut mieux qu'une plateforme complète encore inutilisable.

Je ne lancerais pas un grand programme de transformation avec dix chantiers parallèles. Je commencerais petit, avec une équipe volontaire et un cas d'usage fréquent.

Pendant les deux premiers mois, je regarderais le parcours réel d'une application : depuis la création du dépôt jusqu'à son premier déploiement, puis jusqu'à son diagnostic en cas de panne. Pas le processus théorique décrit dans la documentation. Le vrai, avec ses messages sur Teams, ses droits manquants et ses étapes connues uniquement de deux personnes.

Les deux mois suivants, je livrerais un premier parcours complet. Par exemple une API Java : starter, CI/CD, contrôles, image, déploiement sur Kubernetes, logs et métriques. Je chercherais quelques équipes pilotes prêtes à s'en servir sur un vrai projet, pas uniquement pendant une démonstration.

Les deux derniers mois, je corrigerais ce qui bloque, je vérifierais les usages et je déciderais seulement ensuite s'il faut ajouter un nouveau langage, un nouveau type d'application ou un nouveau service.

Ce n'est pas une promesse de calendrier valable partout. C'est une manière de limiter le risque de construire une grosse plateforme avant d'avoir prouvé qu'elle rend service. On retrouve ici l'idée d'une plateforme minimale utile, souvent associée aux pratiques de Thinnest Viable Platform [3, 5].

Alors, équipe dédiée ou pas ?

Je ne créerais pas une équipe Platform Engineering simplement parce que mon entreprise utilise Kubernetes.

Avec 20 développeurs, un référent outillé, un relais technique et quelques standards bien entretenus peuvent largement suffire. À 100, une petite équipe dédiée peut devenir un excellent investissement si les besoins se répètent. À 500, il paraît difficile de faire l'économie d'une vraie organisation des capacités communes, quitte à la fédérer entre plusieurs équipes.

Mais le nombre de développeurs ne dit pas tout. La criticité des applications, les exigences réglementaires, l'astreinte, les services managés disponibles et le niveau d'automatisation pèsent parfois bien plus lourd.

Je retiens surtout ceci : une équipe plateforme ne devrait pas devenir l'équipe qui fait Kubernetes à la place de tout le monde. Elle devrait rendre les tâches courantes simples, sûres et reproductibles, tout en laissant aux équipes applicatives la maîtrise de leurs produits.

Si, après la mise en place d'une équipe plateforme, il faut toujours ouvrir trois tickets pour déployer une API, on a peut-être amélioré l'organigramme. Pas encore l'expérience développeur.

C'est à ce résultat-là que je jugerais la démarche.

Sources et références

Les références ci-dessous éclairent les principes de Platform Engineering, d'organisation et de Developer Experience. Les effectifs proposés pour 20, 100 et 500 développeurs, ainsi que la matrice RACI, sont mes propres scénarios illustratifs, et non des ratios ou modèles officiels issus de ces publications.

CNCF TAG App Delivery — Platforms White Paper. Définition et objectifs d'une plateforme interne. https://tag-app-delivery.cncf.io/whitepapers/platforms/
CNCF TAG App Delivery — Platform Engineering Maturity Model. Modèle de maturité : adoption, interfaces, opérations et valeur. https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
Team Topologies — Team Interaction Modeling with Team Topologies. Interactions entre équipes, charge cognitive et conception organisationnelle. https://teamtopologies.com/key-concepts-content/team-interaction-modeling-with-team-topologies
CNCF TAG App Delivery — Product Thinking for Platforms (2024). Plateforme envisagée comme un produit avec ses utilisateurs. https://tag-app-delivery.cncf.io/blog/product-thinking-for-platforms/
DORA — Capabilities: Platform Engineering. Golden paths, plateforme interne, autonomie et qualité des capacités proposées. https://dora.dev/capabilities/platform-engineering/
Backstage — Software Templates. Exemple d'outillage pour créer des composants et automatiser leur initialisation. https://backstage.io/docs/features/software-templates/
DORA — State of AI-assisted Software Development 2025. Travaux sur les capacités organisationnelles et le rôle de la qualité des plateformes. https://dora.dev/research/2025/dora-report/

Schémas et illustrations créés pour cet article.

La vérité sur les outils DevOps : ce qui apporte vraiment de la valeur

Mehdi Chilla — Wed, 04 Feb 2026 08:59:05 +0000

👉 Question simple :

Votre plateforme aide-t-elle les devs… ou leur met-elle des bâtons dans les roues ?

Mythe n°1 : « On a les bons outils, donc on fait du DevOps »
Installer Git, une CI/CD moderne et Kubernetes ne transforme rien par magie.

Un outil sans usage clair devient une contrainte.
Un outil imposé devient un outil contourné.

Mythe n°2 : « Plus on a d’outils, plus on est mature »

Retour terrain :

10 outils installés
3 vraiment utilisés
1 maintenu correctement
0 compris dans leur ensemble

Résultat :

pipelines illisibles,
responsabilités floues,
incidents impossibles à diagnostiquer.
La complexité est le tueur silencieux du DevOps.
Les outils qui apportent vraiment de la valeur

Spoiler : ils sont peu nombreux. Et rarement les plus “à la mode”.

1️⃣ Un SCM simple et central

La plateforme importe peu.
Les conventions, elles, changent tout.

branches:
  main: production
  develop: intégration
  feature/*: nouvelles fonctionnalités
  hotfix/*: correctifs urgents

Si personne ne comprend votre stratégie de branches, vous avez déjà perdu.

2️⃣ Une CI rapide, lisible, honnête

Une CI doit répondre à une seule question :

Puis-je déployer ce code en confiance ?

stages:
  - build
  - test

build:
  script: docker build -t myapp:$CI_COMMIT_SHA .

test:
  script: docker run myapp:$CI_COMMIT_SHA pytest

Pas besoin de 25 jobs pour dire “oui” ou “non”.

3️⃣ Une registry immuable (et respectée)

Si vous utilisez encore latest en production, on doit parler.

image:
  name: registry.example.com/myapp
  tag: "1.4.2"

Pouvoir dire exactement ce qui tourne en prod n’est pas un luxe.

4️⃣ Une observabilité minimale mais exploitable

Avant les dashboards, assurez-vous que vos logs racontent une histoire.

logging:
  level: info
  format: json
  fields:
    service: myapp
    env: prod

Si un dev ne comprend pas un log à 3h du matin, le problème est là.

Les outils surévalués (ou mal utilisés)
Kubernetes par défaut

Kubernetes est excellent.
Mais aussi exigeant.

replicas: 2
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"

Si personne ne comprend ce YAML, Kubernetes n’apporte pas de valeur — il ajoute du stress.

La sécurité sans stratégie

Les scanners sont utiles.
Les alertes non priorisées ne le sont pas.

security:
  fail_on:
    - critical
    - high

Moins d’alertes.
Mais des alertes qui comptent.

La vraie valeur n’est pas dans l’outil

Elle est dans :

des règles simples,
des conventions partagées,
des pipelines lisibles,
des responsabilités claires.

Un mauvais process avec de bons outils reste un mauvais process.

Un bon process avec peu d’outils ?
Étonnamment efficace.

Avant d’ajouter un outil DevOps, posez-vous cette question

Quel problème concret cet outil résout-il pour les équipes ?

Si la réponse est floue ou
“parce que tout le monde l’utilise”…

👉 N’installez rien.

✅ Checklist DevOps (à garder sous la main)

Avant d’ajouter un outil, vérifiez :

⬜ Le problème à résoudre est clair

⬜ Les équipes en ont fait la demande

⬜ L’outil simplifie un usage existant

⬜ Le pipeline reste lisible

⬜ Les règles sont compréhensibles

⬜ Le feedback est rapide

⬜ Les alertes sont priorisées

⬜ Quelqu’un est responsable de l’outil

⬜ Le rollback est simple

⬜ L’outil peut être supprimé sans douleur

Si plusieurs cases restent vides…
ce n’est probablement pas le bon outil.

Pour conclure

DevOps n’est pas une collection d’outils.
C’est une discipline d’ingénierie et de collaboration.

Les meilleures plateformes que j’ai vues :

avaient moins d’outils,

mais mieux choisis,

mieux expliqués,

réellement utilisés.

Le meilleur outil DevOps est celui que les équipes utilisent vraiment.

💬 À vous

Quel outil DevOps avez-vous retiré… et qui a amélioré votre plateforme ?

(Oui, retiré. Pas ajouté.)

Mock Me If You Can : Guide de Survie des Tests Logiciels

Mehdi Chilla — Sun, 08 Jun 2025 15:44:17 +0000

🧪 Mock Me If You Can : Guide de Survie des Tests Logiciels

Ah, les tests. Ce mot magique qui peut transformer un commit innocent en un feu d'artifice rouge dans ton pipeline CI.

Tu pensais avoir tout compris ? Détrompe-toi, camarade développeur chevronné.

Voici un tour d'horizon (un peu) technique, (légèrement) sarcastique et (probablement) pertinent des principaux types de tests logiciels :

✅ Tests unitaires (mockistes vs classicists)
🔌 Tests d'intégration
🧪 Tests end-to-end (E2E)
🔥 Tests de charge

La fameuse pyramide des tests : moins tu montes, mieux tu dors.

🎬 Bonus : Notre Talk "La Légende des Gardiens du Code"

🗣️ Tu préfères regarder plutôt que lire ? On t'a couvert !

Le 06 juin 2024, avec mon acolyte Jeremy Bernard, on a donné un talk au DevQuest sur ce sujet brûlant : les types de tests et la CI/CD qui va avec.

🎥 Le Talk en Vidéo

📺 Regarder "La Légende des Gardiens du Code" sur YouTube

📊 Les Slides de la Conférence

💾 Télécharger le PowerPoint de la conférence

Spoiler alert : On y raconte comment les tests sont les vrais gardiens de votre code... et pourquoi sans eux, c'est l'anarchie totale en production ! 🔥

🧩 Tests Unitaires : Mockistes vs Classicists — Le Match de Boxe

"Un bon test unitaire isole. Un test unitaire parfait n'existe pas."

— Un développeur qui a perdu 3 jours à débugger un mock

🥊 Camp 1 : Les Mockistes (a.k.a. London School)

Tu veux tout contrôler ? Tu adores faire semblant ? Bienvenue chez les mockistes.

Ici, chaque dépendance est simulée. Tu ne veux pas tester si fetchData() accède à une vraie BDD, tu veux juste qu'il croie qu'elle existe.

✅ Avantages

Hyper rapide
Super précis : tu sais exactement ce qui est cassé
Isolation complète du code testé

❌ Inconvénients

Fragile comme un test PCR dans une boîte chaude
Teste souvent l'implémentation plus que le comportement
Maintenance élevée des mocks

🧘‍♂️ Camp 2 : Les Classicists (a.k.a. Detroit School)

Tu préfères tester sans te casser la tête à tout mocker ? Tu es classicist.

Tu laisses les vraies dépendances s'exécuter dans leur contexte logique.

✅ Avantages

Teste des comportements réels
Moins de maintenance liée aux mocks

❌ Inconvénients

Moins rapide
Plus sujet aux tests flakies
Risque de mauvaise séparation des responsabilités

🤯 Le Vrai Dilemme ?

Les mockistes valident les interactions
Les classicists valident les résultats

👉 Choisis ton camp, mais reste cohérent.

🔌 Tests d'Intégration : Là où les Bugs naissent

"Ça marche en local, mais en prod c'est l'apocalypse ? Tu fais pas de tests d'intégration, hein ?"

Le test d'intégration, c'est le café serré du TDD.

Il ne teste pas chaque grain, mais la machine complète.

✅ Avantages

Révèle les vrais bugs (ceux qui pètent en prod)
Valide les comportements transverses : transactions, configs, etc.

❌ Inconvénients

Lents, très lents
Fragiles si dépendances instables
Requiert souvent un environnement spécifique ou des outils comme Testcontainers, WireMock, etc.

🔧 Schéma 1: Test d'Intégration Multi-Couches

"Quand toutes les couches doivent jouer ensemble... sans se disputer"

┌─────────────────────────────────────────────────────────────┐
│  🖥️  COUCHE UI (Frontend)                          ✅ UI répond │
├─────────────────────────────────────────────────────────────┤
│  • Formulaire de commande                                   │
│  • Saisie produit: "Licorne en peluche"                    │
│  • Quantité: 42 (pourquoi pas ?)                           │
│                                                             │
│  form.submit()  // Pray it works 🙏                        │
└─────────────────────────────┬───────────────────────────────┘
                              │ ⬇️ Test vérifie la transmission
┌─────────────────────────────▼───────────────────────────────┐
│  ⚙️  COUCHE API (Backend)                        ✅ API traite │
├─────────────────────────────────────────────────────────────┤
│  • Endpoint REST /orders                                    │
│  • Validation des données                                   │
│  • Calcul du prix (licornes = €€€)                         │
│                                                             │
│  POST /api/orders                                           │
│  status: 201                                                │
└─────────────────────────────┬───────────────────────────────┘
                              │ ⬇️ Test vérifie la persistance
┌─────────────────────────────▼───────────────────────────────┐
│  🗄️  COUCHE BASE DE DONNÉES                      ✅ DB persiste │
├─────────────────────────────────────────────────────────────┤
│  • Tables: products, orders, customers                      │
│  • Transaction ACID                                         │
│  • Contraintes respectées                                   │
│                                                             │
│  INSERT INTO orders  -- Magic happens here ✨              │
└─────────────────────────────┬───────────────────────────────┘
                              │ ⬇️ Test vérifie l'appel externe
┌─────────────────────────────▼───────────────────────────────┐
│  💳 SERVICES EXTERNES                        ✅ Paiement OK │
├─────────────────────────────────────────────────────────────┤
│  • Service de paiement Stripe                              │
│  • Tokenisation carte                                      │
│  • Débit de 1337.42€                                       │
│                                                             │
│  stripe.charge()  // 💸 Bye bye money                      │
└─────────────────────────────────────────────────────────────┘

🎉 Résultat du Test d'Intégration

✓ Formulaire → API : PASS
✓ API → Base de données : PASS  
✓ API → Service paiement : PASS
✓ Cohérence des données : PASS

🤓 "Un test d'intégration, c'est comme un chef d'orchestre :
   il faut que tous les musiciens jouent la même partition...
   sinon ça donne du jazz expérimental !"

🧪 Tests End-to-End (E2E) : Le Grand Frisson de l'Automatisation

"Si le bouton ne clique pas, le client ne paie pas."

Les tests E2E sont là pour simuler un vrai utilisateur.

Tu veux tester tout le flow : login, achat, logout ? C'est ici.

🛠️ Outils populaires :

✅ Avantages

Simule le parcours utilisateur complet
Détecte les régressions UI ou frontend/backend

❌ Inconvénients

Lents. Très lents.
Fragiles. Très fragiles.
Maintenance élevée (un QA engineer peut y passer sa vie)

🤖 Schéma 2: E2E Testing vs Human Testing

"Même parcours, même vérifications, mais qui gagne ?"

L'Affrontement Épique

┌─────────────────────────────┐    ⚔️ VS ⚔️    ┌─────────────────────────────┐
│     👨‍💻 L'HUMAIN TESTEUR      │                │       🤖 LE TEST E2E        │
├─────────────────────────────┤                ├─────────────────────────────┤
│                             │                │                             │
│         🧑‍💼                  │                │            🤖               │
│                             │                │                             │
│ 💭 "Bon, on va tester       │                │ 💭 "BEEP BOOP. Exécution   │
│     cette app... encore...   │                │     du scénario 1337..."    │
│     pour la 47ème fois..."   │                │                             │
│                             │                │                             │
│ ACTIONS:                    │                │ CODE:                       │
│                             │                │                             │
│ 1. 🖱️ Ouvre le navigateur    │                │ cy.visit('localhost:3000')  │
│    *soupir* Firefox ou      │                │                             │
│    Chrome aujourd'hui ?     │                │ cy.get('[data-testid=form]')│
│                             │                │   .should('be.visible')     │
│ 2. ⌨️ Tape l'URL             │                │                             │
│    localhost:3000... enfin  │                │ cy.get('#email')            │
│    j'espère que c'est ça    │                │   .type('test@example.com') │
│                             │                │                             │
│ 3. ⏳ Attend le chargement   │                │ cy.get('button[type=submit]')│
│    Hmm... c'est long là...  │                │   .click()                  │
│    ça marche ?              │                │                             │
│                             │                │ cy.contains('Success!')     │
│ 4. 👀 Regarde l'interface   │                │   .should('be.visible')     │
│    "Tiens, ce bouton a      │                │                             │
│    bougé de 2px..."         │                │                             │
│                             │                │ ⚡ Temps d'exécution: 0.3s  │
│ 5. 📝 Remplit le formulaire │                │ 🎯 Précision: 100%         │
│    Email: test@test.com     │                │ 🔄 Répétable: ∞ fois       │
│    (encore et toujours)     │                │ 📊 Rapports: Automatiques  │
│                             │                │                             │
│ 6. 📤 Clique sur Submit     │                │                             │
│    *croise les doigts*      │                │ 💭 "BEEP BOOP. Test terminé│
│                             │                │     Prêt pour les 999       │
│ 7. ✅ Vérifie le résultat   │                │     autres scénarios..."    │
│    "Success!" - Ouf, ça     │                │                             │
│    marche... cette fois     │                │                             │
│                             │                │                             │
│ 💭 "Bon, maintenant il faut │                │                             │
│     que je teste avec un    │                │                             │
│     autre email... et sur   │                │                             │
│     mobile... et Safari😵"  │                │                             │
└─────────────────────────────┘                └─────────────────────────────┘

🏆 Verdict du Match

Critère	👨‍💻 Humain	🤖 Robot	Gagnant
Vitesse	3 minutes	0.3 secondes	🤖 >>> 👨‍💻
Précision	"Oups, cliqué à côté"	Chirurgicale	🤖 > 👨‍💻
Répétabilité	"Pas un lundi matin..."	24h/24, 7j/7	🤖 >>> 👨‍💻
Créativité	"Et si je clique là ?"	Suit le script	👨‍💻 >>> 🤖
Détection de bugs bizarres	"En diagonale ça plante"	Ne sort jamais du script	👨‍💻 >>> 🤖

🤝 La Vérité

L'E2E teste comme un humain très discipliné qui n'aurait jamais de lundi matin...

Mais qui ne trouvera jamais le bug bizarre qui arrive seulement "quand on fait ça en diagonale" 🤷‍♂️

🔥 Tests de Charge : T'as Pas Crashé, Donc T'as Gagné

"Tu peux scaler ton app à 1 million d'utilisateurs ? Moi non plus. Mais j'ai un test qui dit que peut-être."

Tu veux savoir ce que devient ton API sous pression ? Tu fais des tests de charge.

🛠️ Outil testé:

Gatling

✅ Avantages

Identifie les goulets d'étranglement
Fournit des metrics (latence, taux d'erreur, throughput)
Essentiel en préprod sur les services critiques

❌ Inconvénients

Difficiles à calibrer et interpréter
Peuvent donner un faux sentiment de sécurité
Nécessitent une vraie stratégie d'analyse

⚖️ Résumé Comparatif

Type de test	Vitesse 🚀	Fiabilité 🛡️	Portée 🎯	Complexité 🧠
Unitaire (mock)	Ultra rapide	Moyenne	Petite	Moyenne
Unitaire (classic)	Rapide	Bonne	Moyenne	Basse à moyenne
Intégration	Moyenne	Moyenne	Moyenne à large	Moyenne à haute
End-to-End (E2E)	Lente	Moyenne	Large	Haute
Charge	Variable	Bonne (si bien fait)	Large	Haute

👋 Conclusion : Teste intelligemment, pas aveuglément

Les tests ne sont pas là pour faire joli sur un dashboard.

Ils sont là pour te sauver le c*l à 2h du matin quand la prod tombe.

✅ Reste pragmatique

✅ N'overengineere pas tes tests

✅ Utilise le bon test pour le bon usage

Et surtout :

Si tu commites sans tests, assume quand tout pète. 😈

📌 Tu veux plus d'articles techniques ?

Suis-moi ici sur dev.to, ou viens troller (gentiment) en commentaires.

#DevOps #TDD #Testing #SoftwareCraftsmanship #TestezVosProds