À propos
Le merge, c'est le milieu du travail, pas la fin.
Je suis basé à Yaoundé, au Cameroun, et formé comme ingénieur logiciel à l'IAI Yaoundé (un diplôme d'ingénieur des travaux informatiques et une licence en génie logiciel, tous deux obtenus avec mention Bien). L'essentiel de ce que j'ai construit depuis a été pour des clients institutionnels : une société immobilière nationale, des programmes d'observatoires numériques gouvernementaux en Afrique de l'Ouest et Centrale, et des autorités municipales gérant leurs propres données. Ce travail arrive rarement avec un cahier des charges fiable : il arrive avec un système existant, un client qui connaît le problème mieux que la technologie, et un délai fixé par le cycle budgétaire de quelqu'un d'autre.
J'ai piloté trois de ces missions de bout en bout - architecture, livraison, et le travail sur site de mise en place de l'infrastructure directement dans le datacenter du client plutôt que dans un cloud managé. Cela incluait la formation des personnes qui allaient réellement faire tourner le système après mon départ, et la rédaction de la documentation pour que le prochain ingénieur n'ait pas besoin de m'appeler. Je suis actuellement Architecte Logiciel Junior et ingénieur DevOps, ce qui veut dire en pratique autant de temps sur des manifests Kubernetes et des standards de revue de code que sur du code applicatif.
Une bonne partie de ce travail s'est révélée géospatiale - PostGIS, GeoServer, Elasticsearch, API cartographiques - parce que la plupart des systèmes qu'on m'a demandé de construire avaient une localisation en leur centre : où se situe un bien, où un service est rendu, où passe réellement une limite. Ce n'est pas une spécialisation que j'ai choisie au départ ; c'est la forme des problèmes qui revenaient sans cesse.
Je travaille en français (C1) et en anglais (B1), depuis l'UTC+1, qui chevauche l'essentiel de la journée de travail européenne et la matinée aux Amériques. Le travail distribué ne change pas ce qui fait un bon logiciel - ça retire juste l'option de clarifier une décision en allant voir quelqu'un à son bureau, donc j'écris plus et je suppose moins.
Méthode
Cinq règles qui tranchent les débats avant qu'ils commencent.
01
Résoudre le vrai problème avant d'ajouter de la complexité. La plupart des fonctionnalités sont le symptôme d'une question mal posée.
02
Une architecture claire et un code lisible survivent au code astucieux. Le prochain à ouvrir le fichier est le véritable utilisateur.
03
Le travail répétitif appartient à l'outillage, pas à la journée de quelqu'un. Si ça arrive deux fois, ça mérite un script.
04
Un système doit être observable, testable et ennuyeux en production. Une nuit mouvementée est un défaut de conception.
05
Un logiciel devient bon par le retour terrain, pas par la planification. Une hypothèse déployée vaut mieux qu'un document parfait.
Outils
Pas tout ce que j'ai touché ce vers quoi je vais réellement, dans l'ordre où j'y vais.
Certifications
Récentes et vérifiables.
DevOps & Cloud
Udemy
Août 2025
DevOps & Cloud
SkillUp / Simplilearn
Mai 2026
DevOps & Cloud
SkillUp / Simplilearn
Mai 2026
DevOps & Cloud
Udemy
Août 2025
Développement web & logiciel
Alison
Févr. 2025
Développement web & logiciel
Udemy
Avr. 2025
Développement web & logiciel
Udemy
Mars 2025
Développement web & logiciel
Udemy
Avr. 2025
Développement web & logiciel
CodeSignal
Févr. 2025
Développement web & logiciel
Udemy
Avr. 2025
Développement web & logiciel
Learn IT University
2025
Méthodologie & gestion
SCRUMstudy
Sept. 2025
Méthodologie & gestion
SMstudy
Sept. 2025
01 / 13
Contact
Les problèmes d'ingénierie qui méritent d'être résolus m'intéressent, tout comme les produits à construire correctement et les équipes où un ingénieur a le droit de porter une fonctionnalité de bout en bout.
Je réponds sous 24 heures.