Des outils nés de la douleur d'exploitation

Tous les outils que nous construisons naissent de la même façon : une douleur d’exploitation récurrente qu’aucun produit existant ne résout correctement. Voici l’histoire de deux outils issus directement de missions d’infrastructure en production, et du workflow assisté par IA qui les a rendus possibles.

Le vide Centreon

Lors d’une mission précédente, l’équipe gérait sa supervision avec Centreon. Le seul provider Terraform disponible ciblait l’API legacy CLAPI, à l’arrêt depuis plus de cinq ans. Celui de l’API V1 manquait des fonctions indispensables pour une infrastructure moderne.

Il nous fallait de la supervision as code et l’outil n’existait pas. Alors nous l’avons construit.

terraform-provider-centreon a été notre premier projet Go, écrit de zéro pour l’API V2 de Centreon. La méthode : fournir la documentation OpenAPI à un assistant IA, générer le code d’intégration avec journalisation, tests unitaires et gestion d’erreurs, puis itérer jusqu’au niveau de production.

Résultat : un provider Terraform entièrement open source qui comble un vide de cinq ans dans l’écosystème Centreon. Sans CLAPI, sans dette legacy, natif API V2.

Stack : Go, Terraform Provider SDK V2, CI/CD GitHub Actions, releases sémantiques.

Le problème de la flotte SSH

Gérer les connexions vers des centaines de VM réparties sur plusieurs datacenters est le quotidien des équipes infrastructure. L’équipe utilisait Remote Desktop Manager (RDM), mais les licences coûtaient cher et chaque nouvel hôte exigeait une saisie manuelle en base. Diffuser une commande sur plusieurs sessions restait pénible.

N’ayant trouvé aucune alternative satisfaisante, nous avons construit SSHplex.

Les besoins étaient clairs :

Récupérer les hôtes dynamiquement depuis NetBox et l’inventaire Ansible, pas depuis une base manuelle
Diffuser des commandes sur plusieurs sessions SSH en simultané
Intégration tmux pour la persistance des sessions : fermer un terminal ne doit pas tuer une tâche de fond
Une interface terminal moderne, pas un vestige

SSHplex a été construit en trois phases : socle (configuration, connectivité NetBox, TUI de base, SSH simple), fonctions cœur (sélection multiple, gestion tmux, gestion d’erreurs) et finitions (diffusion de commandes, persistance des sessions, cache). La CI/CD a été mise en place tôt avec deux pipelines : tests à chaque PR et releases taguées vers GitHub et PyPI.

Stack : Python, framework TUI Textual, API NetBox, tmux, GitHub Actions.

Le workflow assisté par IA

Les deux projets partagent un fil conducteur : l’IA comme binôme de programmation, pas comme architecte.

Le workflow qui a fonctionné :

Les décisions d’architecture restent humaines. Nous définissons les frontières des modules, le flux de données, les interfaces.
Des prompts structurés, pas des suggestions au hasard. Exemple : « Créer une classe client pour l’API NetBox avec pool de connexions, retry automatique avec backoff exponentiel, gestion correcte des certificats SSL et traitement d’erreurs complet pour les requêtes devices et VM. »
Raffinement itératif. Partir de la structure globale, découper en tâches précises, utiliser le mode agent pour les passes de débogage.
La revue de code est obligatoire. Tout code généré passe par une revue manuelle et des tests en conditions réelles.

L’IA a excellé pour éliminer le boilerplate, sur les motifs d’intégration d’API, le scaffolding de tests et la cohérence entre modules. Ses faiblesses : perte de contexte sur les longues sessions, sur-ingénierie sur les premiers modèles (ère Claude 3.5) et quelques décalages sur la logique métier.

Bilan : environ 40 % de vélocité de développement en plus, intégrité architecturale intacte. Ces outils sont testés en production, ce ne sont pas des prototypes générés par IA.

La suite

Ces outils existent parce que l’infrastructure réelle en avait besoin. Les prochains projets suivent le même schéma : Gryph (agent SRE avec RBAC pour Grafana), des outils d’observabilité autour de Loki et Thanos, et de l’automatisation qui relie le git push au trafic réel.

L’open source n’est pas un projet annexe pour nous. C’est le prolongement du travail opérationnel : pratique, inspectable et utile au-delà de notre propre environnement.

Retrouvez tous les projets sur la page Travail .