Brayan Oduro.

Backend d'une plateforme de voyance téléphonique à la minute, avec deux modes de facturation : forfait de minutes prépayées ou débit carte en temps réel. L'appelant choisit son mode, son conseiller, et est mis en conférence, la saisie de carte se fait vocalement via le connecteur Pay de Twilio, avec une pré-autorisation de 69 € pour valider la carte avant le début de l'appel. Le débit réel intervient en fin de session, arrondi à la minute supérieure. Le vrai défi : tout l'état de l'appel est porté par des webhooks Twilio asynchrones via des merges JSON incrémentaux dans Redis, sans marge d'erreur entre ce que Twilio suit, ce que Stripe facture et ce que WordPress stocke.

• ☎️ Redirection live via l'API Twilio : Les deux jambes d'une conférence active peuvent être redirigées vers de nouveaux flux TwiML en cours d'appel, via des mises à jour d'URL REST, sans couper la session. Utilisé pour basculer d'un forfait vers une facturation CB sans raccrocher.
• 💳 Saisie vocale de carte via Stripe : Numéro, expiration et CVC saisis à la voix via le connecteur Pay de Twilio. Une pré-autorisation de 69 € valide la carte en amont, jamais capturée, libérée par Stripe après 7 jours. Le débit réel (arrondi à la minute supérieure × tarif) n'intervient qu'en fin de session.
• 🗄️ État partagé entre webhooks : Toutes les transitions d'appel persistées dans Redis via des merges JSON incrémentaux, chaque webhook ne met à jour que sa portion d'état sans écraser le reste.
• 🔄 Réconciliation entre trois sources : Des crons quotidiens maintiennent Redis, Stripe et WordPress/MySQL en cohérence, en détectant et nettoyant les enregistrements orphelins, les cartes expirées et les débits échoués.

J'utilise Strava, Notion et une API domotique au quotidien, mais les données restaient silotées. J'ai construit cette API edge personnelle pour tout centraliser: un hub privé qui parle à mes services de fitness, de gestion de connaissance et de pilotage des lumières, normalise les données et les rend disponibles pour mes dashboards et automatisations. Un seul namespace KV fait à la fois office de coffre à tokens OAuth et d'index de déduplication. Un projet qui grandit avec mes besoins, et un vrai banc d'essai pour l'architecture edge en conditions réelles.

• ⚡ Edge sans cold start : Réponses immédiates partout dans le monde, zéro serveur permanent à maintenir.
• 🔐 Factory de middleware OAuth : Une seule factory produit un middleware par service, qui gère navigateurs et clients API différemment, redirection vers le flux OAuth pour les navigateurs, réponse JSON 401 pour les appels API. Un seul pattern, trois services.
• 📚 Documentation toujours à jour : Routing typé et schémas Zod, la doc Swagger reste synchrone avec le code, sans effort.
• 🔁 Traitement asynchrone via waitUntil : Un bouton Notion logue un repas, automatiquement lié au récapitulatif du jour, le webhook répond 200 immédiatement pendant que tout le travail s'exécute en arrière-plan. Les exceptions n'affectent jamais la réponse déjà envoyée.

J'avais des centaines de repos starred sur GitHub sans aucune organisation. Ce CLI OSS règle le problème : il analyse chaque repo avec Gemini 2.5 Flash, lui attribue une catégorie parmi 18 avec un score de confiance, puis crée et synchronise les listes directement sur GitHub. 200 repos en ~12 secondes et un workflow GitHub Actions maintient les listes à jour quotidiennement. La contrainte qui a tout structuré : classification zéro-shot pure, sans données d'entraînement, sans fine-tuning, et le mode thinking délibérément désactivé pour la vitesse.

• ✨ Classification zéro-shot, thinking désactivé : Le modèle attribue catégorie et score de confiance en un seul appel, sans exemples, sans données d'entraînement. Le mode thinking est explicitement désactivé : pour une tâche de classification aussi simple, les chaînes de raisonnement ajoutent de la latence sans améliorer la précision.
• 🚀 200 repos en 12 secondes : 40 workers Gemini en parallèle avec exponential backoff sur les 429. Les écritures GitHub GraphQL sont rate-limitées séparément à 2 mutations/sec, 10 repos groupés par mutation via des alias de champs GraphQL.
• 💾 Cache à deux niveaux : Liste starred (TTL 15 j) et analyses par repo (permanent), les relances ne hit l'API que pour les nouveaux repos. Couplé au workflow GitHub Actions quotidien, les re-runs sont quasi instantanés.
• 🖥️ Machine à états React dans le terminal : Ink rend le terminal comme un DOM. Le composant App transite entre les phases du pipeline, fetching, analyzing, syncing, done, piloté par un hook React, pas une chaîne de callbacks.

Plus de quatre ans en CDI dans une agence digitale, à intervenir sur des grands comptes en parallèle : Suzuki, Futuroscope, Panzani. Des marques avec des millions d'utilisateurs, des équipes internes exigeantes, et des produits en prod qu'on ne peut pas se permettre de casser. Nouvelles features, intégrations API, migrations, montées de version. À chaque fois, la même réalité : livrer proprement, dans les délais, que ce soit sur des codebases qu'on a construites ou héritées.

• 🛠️ Features & intégrations API : Sur des plateformes à fort trafic, avec une vraie responsabilité, et des équipes clients qui remarquent quand quelque chose déraille.
• 🌐 Applications web fullstack : Livraison de bout en bout, du cadrage technique à la mise en prod, avec la même exigence de finition à chaque étape.
• 🚀 Migration architecture : Migration de l'API core et du backoffice d'un monolithe vers des microservices headless (Next.js, Directus, GraphQL), sans interruption de service, sur une plateforme à +1M de téléchargements.
• 🎯 Pilotage multi-clients : Plusieurs marques en parallèle, chacune avec ses contraintes, sa stack et son rythme, et la même qualité de rendu entre elles.