Beaucoup d’équipes savent qu’elles ont besoin d’un DevOps, mais peu savent vraiment ce que ça change concrètement dans leur quotidien. On entend souvent des phrases comme « on aimerait bien avoir un DevOps » ou « il nous faudrait quelqu’un pour s’occuper de l’infra », sans que personne ne sache vraiment à quoi ressemble le travail réel, jour après jour, une fois que cette personne est en place. Voici un tour d’horizon pratique, loin des discours marketing habituels.
1. Les points de contact au quotidien
Un DevOps qui fonctionne bien n’est pas une personne isolée qu’on sollicite en cas de problème, planquée dans un coin avec ses serveurs. Il est présent dans les rituels de l’équipe, exactement comme n’importe quel développeur :
- Stand-up quotidien : il participe pour rester informé des blocages liés à l’infra, aux déploiements, aux environnements. Il peut aussi signaler en amont des maintenances prévues, des mises à jour de sécurité à venir, ou des incidents résolus dans la nuit.
- Sprint planning : il aide à estimer les tâches qui touchent la CI/CD, l’infra, la sécurité — et il pousse pour que ces tâches soient explicitement dans le backlog, pas traitées « en douce » entre deux features, sans visibilité pour le reste de l’équipe ni pour le product owner.
- Rétrospective : il partage les incidents survenus, le temps perdu sur des problèmes d’infra, les améliorations en cours. C’est souvent lui qui apporte la vision « combien ça nous a coûté en temps ou en argent » que les devs n’ont pas toujours.
- Code review : il review les pull requests qui touchent les Dockerfile, les pipelines, les scripts de déploiement, l’Infrastructure as Code — pas le code métier en tant que tel, mais tout ce qui touche à « comment ça tourne et comment ça se déploie ».
Le point clé, et c’est probablement le plus important de tout cet article : il n’est pas à côté de l’équipe, il est dans l’équipe, avec un accès direct au board, au repo, aux discussions techniques, aux canaux Slack ou Teams du projet. Dès qu’un DevOps est traité comme un prestataire externe qu’on contacte par ticket, la collaboration se dégrade immédiatement.
2. Les livrables concrets qu’il produit
Contrairement à une idée reçue, le travail d’un DevOps n’est pas seulement de « faire tourner des serveurs ». Voici ce qu’on doit concrètement voir apparaître dans un projet où un DevOps est bien intégré :
- Des pipelines CI/CD fiables (GitLab CI, GitHub Actions, Jenkins…) qui automatisent tests, build et déploiement, avec des temps d’exécution optimisés et des retours rapides aux développeurs en cas d’échec
- De l’Infrastructure as Code (Terraform, Ansible, Pulumi) pour que l’infra soit versionnée, reproductible, et review-able comme du code — fini les configurations modifiées à la main sur un serveur, sans trace ni historique
- Des environnements cohérents entre dev, staging et prod (fini le « ça marche en local mais pas en prod », cette phrase qui coûte des heures de debug à chaque équipe qui ne maîtrise pas ce sujet)
- Des dashboards de monitoring (Grafana, Datadog, Prometheus) que les devs peuvent consulter eux-mêmes sans dépendre de lui pour comprendre l’état du système
- Un système d’alerting pertinent (pas 200 alertes par jour ignorées et noyées dans un canal Slack mort, mais les bonnes alertes au bon moment, envoyées aux bonnes personnes)
- Des runbooks et de la documentation technique réellement utilisée, testée, mise à jour — pas rangée dans un Confluence oublié depuis 8 mois
3. Qui décide de quoi — la répartition des responsabilités
C’est souvent le point flou dans les équipes, et la source de la majorité des tensions entre devs et DevOps. Une répartition qui fonctionne bien ressemble à ça :
| Domaine | Devs | DevOps |
|---|---|---|
| Code applicatif | ✅ Responsable | Review si impact infra |
| Choix d’architecture technique | Consulté | ✅ Responsable |
| Pipeline CI/CD | Contributeur | ✅ Responsable |
| Infrastructure cloud | Consulté | ✅ Responsable |
| Sécurité (secrets, accès) | Contributeur | ✅ Responsable |
| Monitoring / astreinte | Consulté | ✅ Responsable (ou partagé) |
L’idée n’est pas que le DevOps fasse tout, mais qu’il y ait un owner clair sur chaque sujet — pour éviter le fameux « je pensais que c’était toi qui gérais ça » au moment d’un incident en production, un vendredi à 18h, ce qui arrive dans énormément d’équipes qui n’ont jamais formalisé cette répartition.
4. Les signaux qu’un DevOps est bien intégré
- Les devs déploient eux-mêmes en autonomie (le DevOps a construit l’outillage, pas créé une dépendance à sa personne)
- Le temps entre « code mergé » et « code en prod » se compte en minutes, pas en jours
- Les incidents ont une vraie analyse post-mortem, avec des actions correctives suivies et vérifiées au sprint suivant
- Personne ne dit « il faut attendre que [DevOps] soit dispo » pour un déploiement standard
- La documentation infra permettrait à un nouveau développeur de comprendre l’architecture sans avoir à interroger quelqu’un
5. Les signaux que ça ne fonctionne pas
- Le DevOps est en dehors des rituels, sollicité uniquement en pompier quand tout part en flammes
- Il devient un goulot d’étranglement : rien ne se déploie sans lui, aucune décision infra ne se prend sans son feu vert immédiat
- Les devs ne comprennent pas l’infra sur laquelle tourne leur code, et n’y touchent jamais, par peur de « casser quelque chose »
- La documentation infra n’existe que « dans sa tête », ce qui est une bombe à retardement en cas de départ, congé ou simple absence
