UBSI — leadership DevOps sur un SI multi-équipes
Workstream DevOps d'un SI de compagnie aérienne simulé par 50 participants : fournir le socle que les autres équipes utilisent.
Contexte
Une simulation d'urbanisation à 50 participants : le système d'information d'une compagnie aérienne miniature, découpé en plusieurs équipes applicatives qui doivent s'intégrer entre elles. Le risque évident est que chaque équipe construise dans son coin et que rien ne se parle à la fin.
Mon rôle
Je pilote le workstream DevOps. Je ne livre pas de fonctionnalité métier : je fournis le socle sur lequel les autres équipes construisent, et je m'assure qu'elles l'utilisent réellement. C'est un rôle transverse — l'adoption se gagne, elle ne se décrète pas.
Ce que j'ai fait
- Standards partagés : conventions d'API, format de logs, découpage des services — le vocabulaire commun qui permet à des équipes séparées de s'intégrer.
- CI/CD : chaîne GitLab CI/CD unique, reprise par chaque équipe applicative.
- Observabilité : socle Prometheus, Grafana et Loki, pour que le diagnostic ne dépende pas de qui a la console ouverte.
- Intégration : bus RabbitMQ entre services, avec les contrats de messages associés.
FastAPI · Python · PostgreSQL · RabbitMQ · Docker · Docker Compose · GitLab CI/CD · Prometheus · Grafana · Loki · Alembic · HTTPX
Résultat
Un socle commun imposé et effectivement adopté sur une simulation à 50 participants. [TODO: métrique] nombre d'équipes et de services intégrés au socle.
Ce que j'en retire
À 50 personnes, le goulot n'est plus technique. Un standard n'est adopté que s'il est plus rapide à suivre qu'à contourner, et la moitié du travail consiste à aller voir les équipes une par une plutôt qu'à écrire une meilleure documentation.