← Réalisations / Réalisation 05

Présentation

Avant de connaître Ansible, j'avais un problème très concret : je gérais un grand nombre de machines virtuelles, aussi bien dans le cadre de mon alternance chez Valesys que dans mon lab personnel, et chaque nouvelle VM imposait une série de configurations initiales répétitives. Mise à jour du système, installation des utilitaires réseau, déploiement d'agents, configuration SSH, ajout d'utilisateurs, ces tâches identiques étaient réalisées manuellement, encore et encore.

Plutôt que de chercher immédiatement une solution existante, j'ai fait le choix délibéré de construire mon propre outil. Non par méconnaissance d'Ansible, dont j'avais entendu parler, mais par volonté de comprendre de l'intérieur ce que ce type d'outil fait réellement. C'est cette démarche qui a donné naissance au projet, dans une première version Bash + YAML utilisée chez Valesys, puis dans une réécriture Python publique nommée SQC (SSH Quick Config) hébergée sur mon GitHub.

Objectifs, contexte et enjeux

L'objectif était de disposer d'un outil léger, portable et flexible, capable de déployer automatiquement des configurations et des outils sur un ou plusieurs endpoints distants, en utilisant uniquement une connexion SSH comme prérequis. Pas d'agent à installer côté cible, pas de dépendance lourde, juste un binaire sur la machine de contrôle et un fichier de configuration.

L'enjeu était double. D'un côté, gagner du temps sur des tâches répétitives et réduire les erreurs humaines liées aux configurations manuelles : sur 30 à 40 endpoints, la moindre commande oubliée se traduit par une incohérence qui ressort plus tard en incident. De l'autre, mieux comprendre les mécanismes sous-jacents à l'automatisation de déploiement (sessions SSH parallèles, idempotence, gestion d'erreurs en chaîne, format de configuration), ce qui s'est révélé particulièrement formateur pour la suite quand j'ai abordé Ansible et AWX avec une compréhension déjà solide des concepts.

Les risques propres à un tel outil sont nombreux et m'ont guidé dans les choix de conception. Une commande lancée sur plusieurs machines simultanément peut provoquer des dégâts multipliés par le nombre de cibles si elle est mal pensée. Une session SSH qui tombe en cours de déploiement peut laisser un système dans un état intermédiaire incohérent. Un script qui s'exécute différemment selon la distribution cible peut produire des résultats imprévisibles. Ces risques expliquent pourquoi le projet est resté volontairement limité à un usage personnel et à un lab, et n'a jamais été déployé sur des infrastructures critiques sans supervision directe.

Étapes de réalisation

Architecture de l'outil : entrées (CLI ou fichier de configuration), moteur central, et endpoints cibles via SSH.

endpoints:
 - host: srv-web-01.lab.local
  user: deploy
  actions:
   - apt_update
   - install_packages: [nginx, certbot, fail2ban]
   - ssh_hardening
   - add_user: { name: nicolas, ssh_key: ~/.ssh/id_ed25519.pub }

 - host: srv-monitoring-01.lab.local
  user: deploy
  actions:
   - apt_update
   - install_packages: [zabbix-agent, wazuh-agent]
   - configure_agent: { server: 192.168.10.5 }

Organisation et acteurs

Ce projet a été développé seul, dans le cadre de mon alternance chez Valesys et de mon lab personnel. La version originale Bash a été hébergée sur le GitLab interne de Valesys, auquel je n'ai plus accès aujourd'hui. Les utilisateurs directs de cette version originale étaient principalement moi-même, dans les deux contextes (entreprise et lab personnel).

La version publique Python SQC est hébergée sur mon GitHub avec 10 commits et 2 stars à ce jour. La traction publique reste modeste, mais le projet est vérifiable, ce qui le distingue de la version Valesys perdue. Cette différence de statut entre version privée et version publique est devenue chez moi une discipline : ce qui n'est pas accessible publiquement ne peut pas être considéré comme une réalisation portable.

Résultats

Pour Valesys et mon lab personnel, l'outil a permis de réduire significativement le temps de mise en place des configurations initiales sur les VM. Des tâches qui prenaient auparavant plusieurs dizaines de minutes par machine, répétées manuellement, sont devenues une affaire de quelques secondes une fois le fichier de configuration prêt. Sur les 30 à 40 endpoints déployés au total, le gain cumulé représente plusieurs journées de travail économisées sur la durée de mon alternance.

Pour moi, le résultat dépasse largement le gain de temps direct. Construire cet outil m'a permis de comprendre concrètement ce que signifie concevoir un outil destiné à être réutilisé et modifié dans le temps. La contrainte d'extensibilité que je m'étais fixée dès le départ a obligé à réfléchir à la structure du code différemment de ce que je faisais habituellement : interfaces stables, conventions partagées, séparation entre moteur et plugins. Ce sont exactement les concepts que j'ai retrouvés ensuite dans Ansible, et que j'ai pu m'approprier infiniment plus vite parce que je les avais déjà digérés à ma propre échelle.

Lendemains du projet

Regard critique

Mes apports concrets sur ce projet sont de trois ordres. D'abord la démarche assumée de réinventer la roue à des fins d'apprentissage, plutôt que de consommer un outil mature sans en comprendre les mécanismes. Cette approche n'est pas universellement recommandable, mais quand elle est faite consciemment et avec un objectif pédagogique clair, elle apporte une profondeur de compréhension qu'aucun tutoriel ne donne. Ensuite la conception extensible dès le départ, qui a structuré ma façon de penser le code bien au-delà de ce projet. Enfin la discipline de transparence open source sur le repo SQC public : assumer les limites actuelles dans le README plutôt que de les masquer est un choix qui m'a coûté en ego mais qui correspond à mes valeurs sur le partage de code.

Ma valeur ajoutée mesurable est double. Sur le plan opérationnel chez Valesys, des dizaines d'heures économisées en routine de déploiement sur 30 à 40 endpoints, sans erreur humaine introduite. Sur le plan personnel, une maîtrise accélérée d'Ansible et d'AWX ensuite, parce que les concepts d'inventory, de playbook, de modules et d'idempotence étaient déjà digérés à ma propre échelle. Cette accélération a été un véritable avantage compétitif quand je suis entré sur les sujets DevOps avancés chez Paritel.

Mes enseignements personnels sont nombreux et durables. Le plus important est probablement que réinventer la roue a parfois beaucoup de valeur, à condition de le faire consciemment et dans un objectif d'apprentissage. Je ne recommande pas de reconstruire Ansible pour une utilisation en production, ce serait absurde. En revanche, construire un outil similaire à plus petite échelle pour en comprendre les mécanismes est l'un des exercices les plus formateurs que j'aie faits dans ma jeune carrière. Le second enseignement est la nécessité d'investir dès le départ dans une gestion d'erreurs robuste et des logs lisibles. Ce sont les deux points qui ont montré leurs limites lorsque l'outil a commencé à être utilisé sur un nombre croissant de machines simultanément, et c'est exactement ce que les outils matures font très bien et qui justifie leur maturité.

Avec le recul, je vois aussi plusieurs limites importantes du projet. La perte de la version originale Bash hébergée sur le GitLab interne de Valesys est un point de fragilité que j'ai retenu : ce qui n'est pas hébergé sur ses propres ressources n'est pas une réalisation portable, peu importe sa qualité. La limitation aux distributions Debian-based de la version Python publique restreint son adoption potentielle. Le statut "spaghetti code" assumé dans le README est honnête mais montre aussi qu'un projet d'apprentissage ne devient pas automatiquement un projet de production : il faudrait un travail de refactor sérieux pour que SQC dépasse son statut actuel. Et enfin, Ansible et AWX restent objectivement plus performants et mieux maintenus, ce qui rend SQC pédagogiquement précieux mais opérationnellement secondaire. C'est une lucidité que j'assume pleinement.

Compétences rattachées

Ce projet mobilise principalement des compétences techniques transverses. Sur le volet technique, il illustre directement le Tooling & Scripting dans son aspect outil structuré et extensible (par opposition au script jetable), la Configuration Système par la connaissance fine des actions automatisées (apt, SSH, netplan, users, agents) et l'Administration Réseau par la maîtrise du protocole SSH comme socle d'orchestration. Sur le volet humain, il met en avant l'Autonomie nécessaire pour construire un outil de A à Z sans encadrement et la capacité à Faire preuve d'initiative, illustrée par le choix volontaire de construire avant d'utiliser pour comprendre de l'intérieur.