Développeur d'applications · Lomé & à distance
Service 02 — Infrastructure & mise en production
Mettre en production sans y passer les nuits
Chaque livraison est un événement, personne ne sait vraiment ce qui tourne en production, et les incidents vous sont remontés par vos utilisateurs. Je monte la chaîne qui emmène votre code du dépôt jusqu'à la production, et la supervision qui vous prévient en premier.
- Docker · Kubernetes
- GitLab CI · GitHub Actions · ArgoCD
- Prometheus · Grafana · Loki · Tempo
- GitOps
- ce qui est versionné dans Git est ce qui tourne en production
- 0
- mise en production manuelle : tout passe par le pipeline
- 100 %
- de l'infrastructure décrite dans un dépôt qui vous appartient
Ils m'ont fait confiance
Vos enjeux
Votre production tient-elle sur une seule personne ?
- 01
Le déploiement fait peur
Livrer prend une soirée, se fait à la main, et personne ne veut être celui qui appuie sur le bouton.
- 02
Les environnements divergent
Ça marche en local, pas en recette. Chaque serveur a été configuré à la main, à un moment que plus personne ne sait dater.
- 03
Vos utilisateurs vous préviennent
Vous apprenez les incidents par téléphone. Aucune métrique, aucun log centralisé, aucune alerte.
- 04
Un seul sachant
Une seule personne sait comment la production est montée, et l'infrastructure n'est écrite nulle part.
Périmètre
Ce que je mets en place
Conteneurisation & environnements
Des images propres et des environnements identiques du poste développeur à la production. Fini le « ça marchait chez moi ».
Pipeline d'intégration & de déploiement
Tests, analyse statique, build et déploiement automatisés. Chaque modification validée part en recette, chaque version taguée en production.
Kubernetes & déploiement GitOps
Le déclaratif dans Git fait foi : ArgoCD réconcilie le cluster avec le dépôt. Ce qui tourne est exactement ce qui est versionné, et un retour arrière est un commit.
Observabilité & alertes
Métriques, logs et traces centralisés, tableaux de bord lisibles et alertes qui réveillent la bonne personne — sur un seuil qui veut dire quelque chose.
Méthode
Comment se déroule une mission d'infrastructure
Étape 1 · 2 à 4 jours
État des lieux
Comment votre application est déployée aujourd'hui, ce qui est automatisé, ce qui ne l'est pas, et ce qui repose sur une seule personne. J'en sors une cible et un ordre de priorité.
Étape 2 · 1 semaine
Conteneurisation & recette
Images, variables d'environnement, secrets, et un environnement de recette qui ressemble à la production. C'est le socle de tout le reste.
Étape 3 · 1 à 2 semaines
Pipeline & déploiement
Intégration continue, déploiement automatisé, procédure de retour arrière testée pour de vrai — pas seulement décrite.
Étape 4 · 1 semaine
Supervision & transfert
Tableaux de bord, alertes calibrées et guide d'exploitation, puis passation à votre équipe pour qu'elle exploite sans moi.
Ce que vous recevez
Une infrastructure que vos équipes peuvent reprendre
Un dépôt d'infrastructure versionné
Manifestes, variables et secrets chiffrés : l'état de votre plateforme se lit dans Git, pas dans la mémoire de quelqu'un.
Des environnements alignés
Développement, recette et production configurés de la même manière, avec les seules différences qui doivent exister.
Des tableaux de bord et des alertes
Grafana branché sur vos métriques applicatives et système, avec des seuils d'alerte calibrés sur ce qui vous gêne réellement.
Un guide d'exploitation
Que faire quand ça casse : procédures de redémarrage, de restauration et de retour arrière, écrites pour être suivies sous stress.
Pourquoi travailler avec moi
Trois engagements que je tiens sur chaque mission
- 01
Vous parlez à celui qui code
Pas de commercial, pas d'intermédiaire, pas de profil junior placé sur votre projet après la signature. Celui qui cadre est celui qui livre.
- 02
Vous restez propriétaire
Code, infrastructure, comptes, documentation : tout est chez vous. Vous pouvez changer de prestataire sans repartir de zéro.
- 03
Je dis non quand il faut
Si votre besoin se règle avec un outil du marché ou trois jours de conseil plutôt qu'un développement, je vous le dis — même si ça me coûte la mission.
En pratique
Un exemple : MTN Bénin et le switch de la BCEAO
Sur l'intégration de MTN Bénin au Système de Paiement Instantané de la BCEAO, j'ai conçu la chaîne de déploiement Kubernetes en GitOps avec ArgoCD et l'observabilité de bout en bout — métriques, logs et traces, de la requête entrante jusqu'à la réponse de la Plateforme d'Interopérabilité.
Voir le projet →Questions fréquentes
Ce qu'on me demande avant de démarrer
Faut-il forcément passer à Kubernetes ?
Non, et c'est souvent une mauvaise idée. Une application unique qui tourne sur deux serveurs n'a rien à y gagner : Docker, un pipeline et une supervision correcte suffisent. Je propose Kubernetes quand la charge, le nombre de services ou les exigences de disponibilité le justifient.
Travaillez-vous sur notre hébergeur actuel ?
Oui. Serveur dédié, VPS, ou fournisseur cloud : je travaille sur ce que vous avez déjà. Si un changement se justifie, je le chiffre et vous décidez.
Que se passe-t-il après la mission ?
Tout est dans votre dépôt, avec un guide d'exploitation. Je peux rester en support ponctuel les premières semaines, mais l'objectif est que votre équipe exploite seule.
Combien de temps dure une mise en place ?
Comptez 3 à 6 semaines pour une chaîne complète — conteneurisation, pipeline, déploiement et supervision — sur une application existante de taille moyenne.
Décrivez-moi votre chaîne de déploiement actuelle
Je vous réponds sous 48 h avec les deux ou trois points que je traiterais en premier, et pourquoi.
Me contacter