Le DevOps n’est plus l’apanage des grandes entreprises tech. Des PME de 10 à 200 salariés adoptent ces pratiques pour livrer plus vite, avec moins d’erreurs, et dormir plus tranquillement la nuit. Mais l’adoption est rarement linéaire. Voici les 5 erreurs que je retrouve systématiquement chez mes clients PME, et les correctifs concrets à appliquer.
Erreur n°1 : Confondre “on a Docker” et “on fait du DevOps”
C’est l’erreur la plus répandue. Une PME déploie ses applications dans des conteneurs Docker, se dit “on est en DevOps”, et continue de… pousser les images en production à la main depuis le poste d’un développeur.
Docker, Kubernetes, ou n’importe quel outil de conteneurisation n’est pas une pratique DevOps — c’est un outil. Le DevOps, c’est avant tout une boucle de feedback : du code qui passe par des tests automatisés, une validation, puis un déploiement reproductible et traçable. Sans pipeline CI/CD, vous avez de la containerisation, pas du DevOps.
Le correctif : Commencez par le minimum viable : un pipeline GitHub Actions ou GitLab CI qui, à chaque push sur main, (1) lance les tests, (2) construit l’image Docker, (3) la pousse sur un registry, et (4) déclenche le déploiement. Même basique, ce pipeline change tout.
Erreur n°2 : Des environnements de développement qui ne ressemblent pas à la production
“Ça marche sur mon poste” — l’expression la plus coûteuse du développement logiciel. Elle naît d’une divergence entre l’environnement local du développeur et l’environnement de production.
Les causes typiques : des versions de dépendances différentes, des variables d’environnement hardcodées, un système d’exploitation différent (macOS en local, Linux en prod). Le résultat : des bugs qui apparaissent uniquement en production, difficiles à reproduire et coûteux à corriger.
Le correctif : Utilisez Docker Compose pour standardiser l’environnement de développement. Définissez les variables d’environnement dans des fichiers .env versionnés (avec .env.example commité et .env.local ignoré par Git). Et si possible, maintenez un environnement de staging identique à la production où tester avant chaque déploiement.
Erreur n°3 : Aucun monitoring, jusqu’au jour où tout s’arrête
Je demande souvent à mes nouveaux clients : “Comment êtes-vous alerté si votre serveur tombe à 3 h du matin ?” La réponse la plus fréquente : “Par un client qui nous appelle.”
L’absence de monitoring est une erreur de posture, pas un manque d’outil. Des solutions open source comme Prometheus + Grafana, Zabbix, ou Uptime Kuma (pour un monitoring simple de disponibilité) peuvent être déployées en quelques heures et ne coûtent rien.
Ce que vous devez monitorer au minimum :
- Disponibilité (uptime) de vos services exposés
- Ressources système : CPU, mémoire, disque (avec alertes avant saturation, pas après)
- Logs d’erreur : centralisés, interrogeables, avec alertes sur les patterns critiques
- Certificats SSL : une alerte 30 jours avant expiration évite les incidents embarrassants
Le correctif : Déployez Uptime Kuma en 10 minutes (Docker, une ligne de commande) pour la disponibilité. Ajoutez ensuite Prometheus + Grafana pour les métriques système. Configurez des alertes Slack ou e-mail. C’est un investissement d’une journée qui en épargne des dizaines.
Erreur n°4 : Des sauvegardes non testées
“Nous avons des sauvegardes” est une phrase qui cache souvent une réalité plus nuancée : des sauvegardes qui s’exécutent (peut-être), qui sont stockées quelque part (probablement sur le même serveur que les données), et qui n’ont jamais été testées en restauration (presque certainement).
Une sauvegarde non testée n’est pas une sauvegarde — c’est une espérance.
Les erreurs classiques :
- Sauvegardes sur le même volume que les données (si le disque lâche, tout disparaît)
- Aucune rétention définie (60 jours de sauvegardes ou 3 jours ?)
- Pas de test de restauration (des fichiers corrompus se sauvegardent très bien)
- Absence de chiffrement sur des données sensibles
Le correctif : Appliquez la règle 3-2-1 : 3 copies, sur 2 supports différents, dont 1 hors site (cloud, datacenter distant). Planifiez un test de restauration trimestriel et documentez le résultat. Des outils comme restic ou Borg Backup simplifient grandement cette mise en place.
Erreur n°5 : Des secrets et mots de passe dans le code source
Trouver une clé API AWS hardcodée dans un fichier config.py commité sur GitHub — c’est plus courant qu’on ne le croit. Et les conséquences peuvent être catastrophiques : des robots scannent GitHub en permanence à la recherche de secrets exposés.
Cette erreur survient souvent lors d’un prototype rapide (“juste pour tester”) qui finit inexplicablement en production.
Le correctif : Aucun secret ne doit jamais être committé. Les pratiques à adopter immédiatement :
- Variables d’environnement pour tous les secrets en local et en production
- Un gestionnaire de secrets pour les équipes : HashiCorp Vault, AWS Secrets Manager, ou simplement un gestionnaire de mots de passe avec partage sécurisé
- git-secrets ou gitleaks comme hook pre-commit pour bloquer les commits contenant des patterns de secrets
- Rotation immédiate de tout secret potentiellement exposé (on ne sait jamais si un dépôt a été cloné)
En résumé
Ces 5 erreurs ont quelque chose en commun : elles sont toutes le résultat d’une mise en œuvre précipitée, sans prendre le temps de structurer les pratiques de base. Le DevOps n’est pas un sprint — c’est un marathon d’amélioration continue.
La bonne nouvelle ? Corriger ces erreurs une par une, dans l’ordre de leur impact sur votre activité, suffit à transformer radicalement la fiabilité de votre production.
| Priorité | Correctif | Effort estimé |
|---|---|---|
| 🔴 Critique | Sauvegardes 3-2-1 testées | 1 à 2 jours |
| 🔴 Critique | Secrets hors du code source | 2 à 4 h |
| 🟠 Important | Monitoring + alertes | 1 jour |
| 🟡 Moyen | Pipeline CI/CD minimal | 2 à 3 jours |
| 🟡 Moyen | Parité dev/prod (Docker Compose) | 1 à 2 jours |
Vous reconnaissez certaines de ces situations dans votre environnement ? Contactez FRCX pour un audit de votre stack DevOps.