Compétences
Le DevOps rassemble les pratiques qui rendent une modification reproductible depuis le dépôt de code jusqu'à son exploitation : intégration continue, tests, construction, déploiement, configuration, secrets, sauvegardes, surveillance et retour arrière. L'objectif n'est pas seulement d'automatiser une commande. Il faut réduire l'écart entre l'environnement testé et celui qui sert réellement les utilisateurs, puis disposer d'indices suffisants pour comprendre un échec.
Mon expérience se déroule principalement sur des plateformes gérées. Odoo.sh fournit les environnements de développement, staging et production, les sauvegardes et les builds de l'ERP ; Vercel prend en charge le déploiement des applications Next.js ; GitHub Actions exécute les contrôles du portfolio. Je sais utiliser et relier ces services, lire leurs journaux et préparer une bascule. Je distingue cependant cette pratique de l'administration profonde d'une infrastructure : je ne revendique pas encore une maîtrise avancée de Kubernetes, du réseau, de l'infrastructure as code ou de l'exploitation d'un cluster en production.
La sécurité de la chaîne logicielle fait partie de la compétence : versions d'images, dépendances, provenance, secrets et permissions du pipeline. Une sauvegarde n'est utile que si elle correspond à un état cohérent et peut devenir un point de restauration.
Docker présente les images durcies comme des bases minimales, continuellement corrigées et accompagnées de métadonnées vérifiables. Cette évolution replace la sécurité de la chaîne d'approvisionnement, les SBOM et la provenance des images au cœur des pratiques DevOps.
Consulter la source : DockerLa migration ERP utilisait les environnements Odoo.sh reliés au dépôt GitHub. J'ai effectué les adaptations sur des branches dédiées, lancé les builds, lu les journaux de migration et restauré des copies réalistes de la production pour les recettes. Avant la bascule, j'ai vérifié qu'une sauvegarde complète associait la base PostgreSQL et le filestore du même état, préparé l'ordre de remise en service des intégrations et défini le retour arrière vers le dernier état stable si une anomalie critique empêchait la reprise.
Résultat — La production a repris après l'interruption planifiée et aucun retour arrière n'a été nécessaire. Le scénario restait néanmoins prêt, ce qui a permis de traiter la bascule comme une opération contrôlée plutôt que comme un pari sur la réussite du premier démarrage.
Le site corporate est versionné sur GitHub et préparé pour un déploiement Vercel. J'ai intégré les variables d'environnement, les contrôles de qualité, les tests des composants et de l'API, ainsi que les parcours Playwright. Le choix de Vercel apporte une chaîne de prévisualisation et de production adaptée à Next.js, mais je conserve l'architecture suffisamment standard pour éviter qu'un besoin futur rende la plateforme impossible à quitter. La recette de la version candidate doit précéder la bascule et les services connectés doivent être vérifiés après déploiement.
Résultat — Le projet possède déjà une chaîne reproductible jusqu'aux prévisualisations, ainsi que des fondations de contrôle avant sa future production. Le choix de plateforme reste évalué selon son rapport coût-service plutôt que considéré comme définitif.
Le portfolio utilise plusieurs niveaux de tests : tests unitaires sous jsdom, tests de composants dans un navigateur Playwright, tests de régression visuelle et parcours de bout en bout. GitHub Actions exécute les contrôles afin qu'une modification ne dépende pas uniquement de mon environnement local. Les secrets de Resend, reCAPTCHA et Google Tag Manager restent fournis par variables d'environnement. Les dépendances externes sont simulées dans certains tests, limite que je documente au lieu de confondre une suite verte avec une validation complète du déploiement.
Résultat — Plus de 170 tests protègent aujourd'hui les comportements principaux et les relations de contenu. Cette automatisation accélère les changements, tout en laissant identifiés les contrôles réels encore nécessaires aux frontières avec les services externes.
Les éléments de preuve décrivent des épisodes précis. Cette synthèse les replace dans les études de cas complètes : le contexte, ma contribution et le résultat permettent d'observer ce que cette compétence a rendu possible, avec le niveau de prudence nécessaire sur chaque résultat.
Je conserve un niveau débutant, mais il s'agit d'un débutant ayant déjà préparé des déploiements et une migration critique sur des plateformes gérées. Je sais utiliser les pipelines, journaux, sauvegardes et variables d'environnement. Je manque encore d'expérience sur la construction et l'exploitation de l'infrastructure elle-même, notamment le réseau, l'observabilité distribuée et l'infrastructure as code.
Je conseille de préparer le retour arrière avant la mise en production, de vérifier les sauvegardes par leur cohérence et pas seulement leur présence, puis de lire les logs comme une donnée du produit. Les plateformes gérées réduisent le travail d'exploitation, mais elles ne suppriment ni la responsabilité des secrets, ni les tests, ni la compréhension de ce qu'elles automatisent.
Atteindre un niveau intermédiaire solide en sachant décrire et automatiser une infrastructure simple, mettre en place une observabilité exploitable et conduire un déploiement avec restauration testée au-delà d'une seule plateforme gérée.
Je poursuis mon apprentissage de Docker, des images minimales, des SBOM, des pipelines CI/CD et du monitoring. Mon futur outil de Business Intelligence auto-hébergé doit servir de terrain pour pratiquer les conteneurs, la persistance, les sauvegardes, les métriques et l'exploitation régulière d'un service.
