DEV Community: Mehdi Chilla

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