La dette DevOps apparaît lorsque les moyens de construire, tester, déployer et exploiter une application ne suivent plus son développement. Le produit peut continuer à fonctionner, mais chaque livraison devient plus lente et plus risquée. Cette dette reste souvent invisible à la direction jusqu’au départ d’un développeur ou à un incident de production.
Voici dix signes qui doivent déclencher une remise à plat.
1. Une seule personne sait déployer
Si la mise en production dépend de la mémoire, du poste ou des accès d’une seule personne, l’entreprise possède un point unique de défaillance. La procédure doit être reproductible par une autre personne et, autant que possible, automatisée.
2. Les déploiements ont lieu rarement et tard le soir
Une mise en production exceptionnelle accumule davantage de changements, donc davantage de causes possibles en cas d’incident. Le soir ou le week-end ne rend pas le déploiement plus sûr ; il réduit souvent le nombre de personnes disponibles pour diagnostiquer.
Des livraisons petites, régulières et observables limitent le risque.
3. La préproduction ne ressemble pas à la production
Versions différentes, services manquants, données irréalistes ou configuration modifiée manuellement : les tests réalisés dans ces conditions apportent une fausse confiance. Les environnements n’ont pas besoin d’avoir la même puissance, mais ils doivent reproduire les mécanismes essentiels.
4. Les secrets circulent dans les messages ou le code
Mots de passe, certificats et clés d’API ne doivent pas être copiés dans une conversation ou stockés dans le dépôt. Ils doivent être centralisés, protégés, renouvelables et attribués avec des droits limités.
5. Personne n’a restauré les sauvegardes
Une sauvegarde non testée est une hypothèse. Il faut vérifier que les fichiers sont exploitables, que la procédure est connue et que le temps de restauration correspond aux besoins de l’activité.
6. Les migrations de base sont exécutées à la main
Les modifications de données doivent être versionnées, testées et liées à la version du code. Une commande improvisée en production crée des écarts impossibles à reproduire et complique tout retour arrière.
7. Il est impossible de revenir à la version précédente
Avant de livrer, l’équipe doit savoir comment revenir en arrière ou désactiver la nouvelle fonction. Cela inclut le code, mais aussi les migrations de données et les changements de configuration.
8. Les incidents sont signalés par les clients
Sans supervision des erreurs, de la disponibilité et des parcours essentiels, l’équipe découvre les problèmes trop tard. Une bonne alerte doit être actionnable : elle indique quel service est touché et évite le bruit permanent.
9. La CI/CD est rouge depuis des semaines
Lorsque les tests automatiques échouent en permanence, plus personne ne distingue un nouveau problème d’un ancien. L’équipe finit par ignorer l’outil. Il faut réduire le pipeline aux contrôles fiables, réparer progressivement le reste et interdire que le rouge redevienne normal.
10. L’infrastructure réelle n’est décrite nulle part
Des serveurs créés manuellement, des règles réseau inconnues et des tâches planifiées uniquement visibles en production rendent la reprise dangereuse. La configuration doit être documentée ou gérée comme du code, avec un historique et une revue.
Par où commencer ?
Il n’est pas nécessaire d’industrialiser tout le système en une fois. Priorisez selon le risque :
- sauvegardes et restauration ;
- accès, secrets et révocation ;
- build reproductible ;
- première CI fiable ;
- déploiement traçable et retour arrière ;
- supervision des parcours critiques ;
- convergence des environnements.
Chaque étape doit améliorer une opération réelle. Installer un nouvel outil sans changer la manière de livrer ajoute parfois une couche de dette supplémentaire.
Dette DevOps et reprise d’application
Lors d’une reprise, la chaîne de livraison doit être évaluée avant les nouvelles fonctionnalités. Notre checklist d’audit technique permet de l’intégrer à l’état des lieux. Le guide pour faire reprendre une application détaille ensuite le plan de stabilisation.
Chez MyTwiga, Farrago a repris simultanément le développement, les environnements et les déploiements afin de terminer les refontes et retrouver une cadence fiable. Consultez la réalisation MyTwiga.