DEV Community: SIEWE SANTHE AUDREY CAMILA

Mon récap de la PyCon & UbunCon Cameroun 2026 - Jour 1

SIEWE SANTHE AUDREY CAMILA — Tue, 22 Sep 2026 08:50:01 +0000

« Try even scared. » C'est la phrase qui m'a le plus marquée au Jour 1 de la PyCon & UbuCon Cameroun 2026. Et la journée n'a fait que confirmer pourquoi.

Tout a commencé le lundi 14 septembre 2026. Je reçois une notification de Reckot, partenaire de la PyCon & UbuCon Cameroun 2026. Mon billet était confirmé.

Ce jour-là, ma joie débordait. Je n'aurais jamais cru pouvoir participer à un événement de cette ampleur. Il faut dire les choses comme elles sont : je n'y croyais pas vraiment.

Et si j'ai pu y être , c'est grâce à Paula Ali Wakabi, Miss Cloud, Cloud & DevOps Engineer et fondatrice de Women Innovating In Cloud Africa. Elle avait partagé une information dans le groupe WhatsApp de la communauté : les femmes présentes à Yaoundé qui n'avaient pas encore de ticket pouvaient avoir la chance d'obtenir un grant offert par Veliswa Boya. C'est comme ça que je me suis retrouvée à la PyCon. Je lui en serai reconnaissante longtemps.

La première keynote, avec Sarah Abderemane

La toute première journée a bien débuté, avec un accueil chaleureux et convivial des volontaires. Puis la première keynote est arrivée. Sarah Abderemane. Son thème : « La tech, je t'aime, moi non plus ».

Elle a parlé de son histoire. Celle d'une femme qui, plus jeune, rêvait de devenir hôtesse, et qui a appris à trouver sa place dans un écosystème parfois intimidant. Elle a découvert qu'avec les bons ingrédients, on peut non seulement s'y retrouver, mais y laisser sa marque. Elle a évoqué le syndrome de l'imposteur, ce problème auquel elle a dû faire face quand elle commençait à s'insérer dans le monde professionnel.

Et il y a une phrase qui m'a le plus inspirée durant sa présentation :

Determination is Key. Try even scared. Be the only one, is building confidence. Failures are opportunities to learn.

Ces mots m'ont donné une certaine motivation intérieure. Celle de ne jamais abandonner malgré les difficultés et les obstacles qui voudront me faire face dans l'accomplissement d'un travail, d'un projet ou d'un rêve.

À la fin de sa présentation, je suis allée vers elle. Je me suis présentée, puis je lui ai parlé de mon problème de procrastination. Elle m'a conseillé de concevoir une to-do list chaque jour, chaque mois, en y ajoutant des rappels réguliers qui me préviendront que telle tâche doit être réalisée avant telle heure, et que je dois commencer une autre à tel moment. Ensuite, je lui ai proposé qu'on échange nos contacts pour lui faire part de mes avancements dans ma lutte contre la procrastination.

La deuxième keynote, avec Adrien Sani

La deuxième keynote s'est déroulée sous la présentation d'Adrien Sani, un développeur Fullstack spécialisé en architectures backend modernes, APIs REST et microservices avec Django, FastAPI et React.

J'ai découvert des frameworks tels que Django, qui est le plus rapide mais impose une certaine structure, FastAPI, qui est léger mais rapide, et RabbitMQ. Il a aussi évoqué Docker Compose comme étant un outil utilisé pour assurer la communication entre plusieurs services et conteneurs.

J'ai retenu que les microservices sont performants grâce à leur latence et à leur stabilité, qu'ils ne se lancent pas à court terme, et qu'ils sont utilisés dans de grandes équipes de production.

Le workshop de Ndongmo Christian

Ensuite s'est déroulé le workshop de Ndongmo Christian, Senior Backend & DevOps Architect chez HooYia, qui a présenté une session intitulée : « Arrêter de cliquer dans AWS : Django + Terraform ».

J'ai appris comment utiliser Terraform pour définir et provisionner une infrastructure de production de manière reproductible et évolutive. J'ai pu taper des commandes telles que terraform plan, qui représente l'étape de prévisualisation avant la construction. C'est à ce niveau que Terraform lit le code, compare avec celui qui existe déjà sur AWS/Azure/GCP, puis dit : voilà ce que je vais faire. Donc il vérifie, je ne vais pas casser la prod par erreur. Avant de lancer terraform apply, qui, lui, va vraiment construire. terraform apply prend maintenant le code .tf et il va créer, modifier ou supprimer les vraies ressources sur AWS, Azure, GCP, et demande une confirmation avant que l'infrastructure ne se déploie.

Ce fut une belle découverte pour moi qui me forme en DevOps.

Le talk de Claude Ndanda

Ensuite, c'est déroulé le talk de Claude Ndanda , Software Engineer, intitulé : « Construire son propre serveur MCP (Model Context Protocol) avec Python ».

C'était ma première fois d'entendre parler de la notion de MCP. J'ai découvert que c'est un protocole qui permet à un LLM de communiquer avec des outils externes de façon standardisée.

La partie qui m'a le plus fascinée lors de sa présentation était la démo live. À l'aide de FastMCP en Python et d'Ollama en local, Claude Ndanda est arrivé à contrôler un drone sans utiliser de télécommande, mais juste en se servant de l'agent AI custom qu'il avait conçu. Cette démo fut tout simplement fascinante.

Le talk de Linuce Demanou

Ensuite, Linuce Demanou, ML Engineer, a présenté un talk intitulé : « From Belief to Impact: Why Skills Alone Are Not Enough ». Une présentation où j'ai pu réaliser que les compétences seules ne suffisent pas pour réussir dans le monde de la tech, et que la conviction est le véritable point de départ de l'impact.

Le workshop de Sema Kumbela Fombutu

Et enfin, il y a eu un workshop de Sema Kumbela Fombutu
, qui nous a parlé de la gestion efficace du stress au travail. J'ai retenu que le stress est l'indicateur du corps, du cerveau, qui montre que nous sommes épuisés et qu'on a besoin de repos. Et également qu'un stress mal géré, mal soigné, nous mène tout droit sur le chemin du burnout.

Nous avons également fait de petits exercices pour faire sortir le stress, le chasser. Ces exercices consistaient à inspirer par la bouche pendant 4 secondes, puis retenir notre respiration pendant 4 secondes, et enfin relâcher tout ce qui a été emmagasiné par la bouche. Ce fut un moment plutôt relaxant et agréable.

Et c'est ainsi que s'est terminée la première journée
Entre une keynote qui m'a donné la force de continuer, des frameworks backend que je vais devoir explorer, du Terraform que j'ai pu taper en vrai, un drone contrôlé par IA, et des exercices de respiration pour chasser le stress, la journée était dense. Vraiment dense.

Et ce n'était que le jour 1.

Si tu étais aussi à la PyCon & UbuCon Cameroun 2026, ou si tu veux échanger sur Terraform, MCP ou la procrastination, viens en parler en commentaires.

J'ai procastiné Docker pendant un mois... Voici ce qui m'a débloquée

SIEWE SANTHE AUDREY CAMILA — Thu, 10 Sep 2026 22:29:14 +0000

Le 8 juillet, j'ai commencé un mentorat DevOps avec Endah. J'étais motivée, pleine de bonnes résolutions, prête à attaquer le Docker comme une pro.

Sauf qu'entre le 21 juillet et le 22 août, je n'ai rien publié. Mon dernier article ici datait du 29 juillet. Ce silence n'était pas de l'inaction : c'était la phase la moins visible de l'apprentissage, celle où on lit la documentation officielle, où on regarde des schémas d'architecture, où on essaie de comprendre pourquoi Docker existe avant de taper la première commande. Le déclic est venu quand j'ai arrêté de vouloir tout comprendre en théorie avant de commencer, et que j'ai accepté d'apprendre en construisant.

Si tu es en train de lire cet article en te reconnaissant un peu trop, reste. Ce texte est pour toi.

Le déclic : comprendre en construisant

Ce qui m'a débloquée, ce n'est pas un énième tutoriel. C'est une idée toute bête : créer un conteneur qui fait quelque chose, même minuscule, pour voir concrètement ce que Docker permet de faire. J'ai appelé le projet "boxeur" ; une image basée sur Alpine qui exécute en boucle un script Bash et écrit des logs.

Pas de grand plan au départ. Mais à mesure que j'avançais, les concepts clés de Docker se sont mis en place un par un : ce qu'est une image, ce qu'est un conteneur, comment ils communiquent, où vivent les données. Coder, lancer, observer ce qui casse, comprendre pourquoi c'est cette boucle qui m'a fait passer de "je regarde des vidéos sur Docker" à "je sais ce que je fais quand j'utilise Docker".

C'est là que j'ai compris un principe qu'Endah n'arrêtait pas de me répéter : sortir du tutorial hell. Regarder des vidéos, c'est confortable, mais ça reste passif. Taper docker run pour la première fois, lire l'erreur que ton terminal te renvoie, et comprendre ce qu'elle signifie, c'est ça qui construit une vraie compréhension du système.

Les galères (et ce qu'elles m'ont appris sur Docker)

Git 403 : mon premier mur

Avant même de toucher à Docker, j'ai buté sur Git. Un bête 403 Forbidden en essayant de pousser mon code. La solution : générer un Personal Access Token sur GitHub, parce que les mots de passe classiques ne suffisent plus pour l'authentification en ligne de commande. Ça m'a forcée à comprendre comment GitHub gère l'authentification aujourd'hui, pas juste à copier une commande.

Des logs qui n'existaient pas

docker logs boxeur... rien. Un terminal désespérément vide. J'ai mis un moment à comprendre pourquoi : mon script écrivait ses logs dans un fichier à l'intérieur du conteneur, pas sur la sortie standard. Or Docker ne capture que ce qui sort sur stdout c'est une distinction fondamentale entre "écrire un fichier de log" et "logger au sens Docker du terme".

J'ai donc utilisé une autre approche : lire le fichier directement depuis l'intérieur du conteneur.

docker exec boxeur_mentor cat /var/log/boxeur.log

![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/r5wywzvdwbrqmveq1gni.png)

Et là, les logs sont apparus. Cette galère m'a appris comment Docker capture réellement les flux de sortie, et pourquoi la convention "logguer sur stdout" existe dans l'écosystème des conteneurs.

Alpine n'est pas Ubuntu

J'ai voulu installer Nginx et j'ai tapé apt-get install nginx par réflexe. Erreur immédiate. Alpine n'utilise pas apt-get, mais son propre gestionnaire de paquets : apk.

apk add --no-cache nginx

Petit détail, grande leçon : chaque image de base a son propre système et son propre gestionnaire de paquets. Ça m'a poussée à comprendre ce qui différencie réellement les distributions Linux utilisées comme images de base, plutôt que de copier des commandes sans en connaître le contexte.

J'ai aussi bloqué sur un fichier nginx.conf mal écrit (une erreur dès la ligne 2), qu'il a fallu déboguer et réécrire proprement pour que Nginx accepte de démarrer.

La faute de frappe qui m'a coûté une heure

Au moment de pousser mon image sur Docker Hub, j'ai tagué mon image avec une majuscule : Dreatech/boxeur au lieu de dreatech/boxeur. Résultat, une erreur DNS aussi cryptique que frustrante :

lookup Dreatech on 127.0.0.53:53: server misbehaving

Docker Hub n'accepte pas les majuscules dans les noms de dépôt ; une convention de nommage héritée du système de registres de conteneurs. Une fois comprise, la correction était triviale :

docker tag boxeur:latest dreatech/boxeur:latest
docker push dreatech/boxeur:latest

Ce que je retiens vraiment

Au-delà des commandes, ce projet m'a permis de comprendre en profondeur plusieurs concepts fondamentaux de Docker :

Image vs conteneur : l'image est la recette figée ; le conteneur est l'instance qui tourne, vivante, modifiable, jetable. Cette distinction change la façon dont on pense l'architecture d'une application conteneurisée.
Docker Compose comme outil d'orchestration : en faisant communiquer mon "boxeur" et un "observateur" chargé de surveiller ses logs, j'ai compris comment Compose gère les dépendances entre services et le réseau interne qu'il crée automatiquement.
Les volumes et la persistance des données : un bind mount simple, mais qui illustre bien pourquoi la persistance est un problème à part entière quand les conteneurs sont par nature éphémères.
Le poids des images comme critère d'architecture : Alpine pèse environ 7 Mo contre une centaine de Mo pour une image basée sur Ubuntu. Comprendre cet écart m'a fait réaliser l'impact direct du choix d'image de base sur la vitesse de build et de déploiement.

Et puis, il y a eu ce moment précis :

docker run -d --name boxeur_mentor dreatech/boxeur:latest

Mon image, celle que j'avais mis du temps à comprendre et à construire, tournait enfin ; publiée, accessible, réelle.

Le rôle du mentorat

Rien de tout ça ne serait arrivé aussi vite sans l'accompagnement d'Endah, ma mentor dans le cadre du programme CloudHer, porté par Women Innovating In Cloud Africa (WIICA). Ses rappels réguliers m'ont poussée à sortir de la phase de lecture passive pour passer à la pratique ; pas en me donnant les réponses, mais en m'orientant vers les bonnes questions à me poser.

Un bon mentorat, ce n'est pas qu'on fasse le travail à ta place. C'est qu'on te rappelle que tu es capable de comprendre le sujet toi-même, même quand tu doutes d'y arriver.

Ce que je dirais à la moi d'il y a 30 jours

Si tu débutes en DevOps et que Docker te semble être une montagne :

N'attends pas de tout comprendre en théorie avant de commencer. Lance docker run hello-world, puis va lire pourquoi ça fonctionne comme ça a fonctionné.
L'erreur fait partie du chemin d'apprentissage. Un 403, un apk au lieu d'un apt-get, un tag mal écrit — chaque erreur t'oblige à comprendre un mécanisme que tu aurais pu ignorer sinon.
Construis quelque chose pour comprendre un concept, pas pour produire un résultat. Mon "boxeur" ne sert à rien de productif, mais c'est le projet qui m'a fait vraiment saisir ce que Docker fait et pourquoi.
Entoure-toi de quelqu'un qui challenge ta compréhension. Le mentorat m'a poussée à expliquer ce que je faisais, pas juste à le faire.

Pour finir

Mon image est disponible sur Docker Hub : dreatech/boxeur.

Le premier docker run, ce n'était pas difficile parce que la syntaxe est compliquée — mais parce qu'il faut accepter d'apprendre un système par la pratique, en tolérant de ne pas tout maîtriser dès le départ.

Si toi aussi tu as un projet qui prend la poussière depuis des semaines parce que tu attends de tout comprendre avant de te lancer : prends le temps qu'il faut pour bien saisir les bases, puis lance la première commande.

Tu es aussi en train d'apprendre Docker ou le DevOps ? Dis-moi en commentaire sur quoi tu bloques en ce moment;je serais ravie d'en discuter. Et si cet article t'a parlé, un partage aide énormément à faire connaître ce genre de retour d'expérience !

Mes premiers pas avec Linux et Git : comment j'ai préparé ma réunion CloudHer

SIEWE SANTHE AUDREY CAMILA — Wed, 29 Jul 2026 06:28:40 +0000

Il y a quelques jours, j'ai réalisé un truc qui m'a un peu stressée : ma réunion de la semaine 4 avec ma mentor Endah Bongo approchait, et le programme prévoyait Linux et Git. Sauf que... je ne maîtrisais pas encore les différentes commandes utilisées. Plutôt que de paniquer, j'ai décidé de prendre les choses en main et de tout pratiquer en direct, une commande à la fois, jusqu'à ce que ça fasse sens.

Voici ce que j'ai appris, dans l'ordre où je l'ai découvert.

Se repérer dans un terminal Linux

La toute première chose à comprendre avec Linux, c'est qu'on est toujours "quelque part" dans une arborescence de dossiers. Trois commandes suffisent pour s'orienter :

pwd (print working directory) affiche l'endroit exact où on se trouve
ls liste le contenu du dossier courant
cd permet de se déplacer d'un dossier à l'autre

Avec cd ~, on revient direct dans son dossier personnel. Une astuce toute simple, mais qui change la vie quand on découvre le terminal.

Créer et organiser des fichiers

Une fois qu'on sait se déplacer, l'étape suivante c'est de manipuler des fichiers et dossiers :

mkdir crée un nouveau dossier
touch crée un fichier vide
ls -la permet de tout voir en détail, y compris les fichiers cachés et les permissions

C'est là que j'ai découvert les permissions Linux (ce fameux -rw-r--r-- qu'on voit à côté de chaque fichier), qui déterminent qui peut lire, écrire ou exécuter un fichier.

Entrer dans le monde de Git

Une fois les bases Linux en poche, place à Git. Première étape : configurer son identité, une seule fois pour toutes les utilisations futures.

git config --global user.name "Ton nom"
git config --global user.email "ton_email@exemple.com"

Ensuite, j'ai transformé mon dossier de test en dépôt Git avec git init, puis j'ai découvert le cycle de base que tout développeur utilise au quotidien :

Modifier un fichier
git add pour l'ajouter à la zone de préparation (staging)
git commit -m "message" pour valider les changements

Entre les deux, git status est devenu mon meilleur ami : il indique en permanence ce qui est suivi, modifié, ou prêt à être validé.

Les branches, pour ne pas tout casser

La partie qui m'a le plus parlé, c'est le principe des branches. Avec git branch nom-de-branche puis git checkout nom-de-branche, on peut travailler sur une fonctionnalité sans toucher au code principal (master). Une fois le travail terminé et validé, git merge permet de fusionner les changements.

C'est un principe simple sur le papier, mais qui prend tout son sens quand on l'exécute soi-même dans le terminal.

Direction GitHub

Dernière étape : connecter mon dépôt local à un dépôt GitHub, pour que le code existe aussi en ligne.

git remote add origin https://github.com/mon-utilisateur/mon-repo.git
git push -u origin master

git remote add crée le lien entre le dépôt local et son adresse en ligne, et git push envoie les commits vers GitHub. Simple sur le principe, mais ça m'a fait comprendre concrètement la différence entre travailler "en local" et publier son travail pour de vrai.

Ce que je retiens

Cette session improvisée m'a appris une chose essentielle : on ne comprend vraiment un outil qu'en le pratiquant, commande par commande, jusqu'à ce que chaque résultat affiché à l'écran ait un sens. Je suis arrivée à la réunion avec Endah bien plus à l'aise, capable d'expliquer le cycle complet modifier → add → commit → push, et prête à aller plus loin.

Prochaine étape : approfondir les scripts et automatiser certaines de ces tâches. À suivre !

Et toi, c'est quoi ta première commande Git ou Linux qui t'a vraiment fait "cliquer" ? Ou si tu débutes toi aussi, quelle est la partie qui te fait le plus peur pour l'instant ? Dis-le-moi en commentaire, je suis curieuse de savoir si mon parcours ressemble au tien 👇

Mes débuts dans le Devops avec Cloudher

SIEWE SANTHE AUDREY CAMILA — Tue, 21 Jul 2026 06:45:20 +0000

Je m'appelle Audrey, étudiante en L2 Informatique (Systèmes & Réseaux) à Université de Yaoundé I , au Cameroun. Il y a quelques semaines, j'ai rejoint CloudHer, un programme de mentorship DevOps sur 12 semaines, et j'ai décidé de documenter ce parcours ici.

Pourquoi le DevOps ?
Après une réflexion sur mon orientation entre Systèmes & Réseaux et Génie Logiciel, j'ai choisi de me spécialiser vers la cybersécurité et le DevOps — un mélange d'infrastructure, d'automatisation et de sécurité qui me passionne.

Où j'en suis?
Avec ma mentor Endah Bongo , on a commencé par les fondamentaux : mise en place de mon profil technique (GitHub, LinkedIn), premiers pas en Linux, et bientôt scripting/Git, Docker, cloud (AWS), jusqu'à Kubernetes en semaine 8.

Ce que je vais partager ici
Mes apprentissages semaine après semaine, mes galères et mes petites victoires, et les projets que je construis en parallèle (une LMS en PHP/MySQL, un scanner de ports, une app d'analyse de données en Python...).
À bientôt pour la suite !