De la publicité à l

*Ceci est le companion technique de mon introduction à DIALØGUE. Si tu n'as pas encore lu ce qu'est DIALØGUE et pourquoi je l'ai construit, commence par là !*

Le parcours : de professionnel de la publicité à ingénieur full-stack

Ok, adressons l'éléphant dans la pièce — oui, je viens de la publicité. Media plans et briefs créatifs, pas structures de données et algorithmes. Mais voilà ce qui est drôle : comprendre comment fonctionnent les systèmes, que ce soit un funnel marketing ou une architecture distribuée, requiert le même état d'esprit analytique. La différence ? En ingénierie, quand tu fais une erreur, l'ordinateur te le dit immédiatement. Pas besoin d'attendre les résultats de campagne haha.

Construire DIALØGUE a été… intense. Ce n'est pas juste écrire du code (bien qu'il y en ait eu beaucoup). C'est architécter un système complexe qui doit d'une façon ou d'une autre orchestrer plusieurs services IA, gérer des workflows asynchrones, et ne pas s'effondrer quand les utilisateurs font des choses inattendues. Laisse-moi partager ce que ce voyage m'a vraiment appris — le bon, le frustrant, et les moments "pourquoi personne ne me l'a dit ?".

Décisions d'architecture : pourquoi la complexité est l'ennemi

Voilà quelque chose que personne ne te dit quand tu débutes : la complexité n'est pas ton amie. Je l'ai appris à la dure. Genre, vraiment à la dure. Imagine-moi noyé dans les logs CloudWatch, essayant de comprendre pourquoi mon système si élégamment architecturé… ne fonctionnait pas. T.T

Architecture initiale (trop complexe)

J'ai commencé avec LangGraph pour l'orchestration. Pourquoi ? Parce que l'approche basée sur les graphes semblait si élégante ! Elle me donnerait de la flexibilité ! Elle s'adapterait magnifiquement !

Retour à la réalité : c'était douloureusement lent. Même en exécution locale. Même avec leur déploiement cloud. Toute cette belle abstraction n'était que… de la surcharge. Beaucoup, beaucoup de surcharge.

Architecture finale (pragmatiquement simple)

Après beaucoup d'introspection (et de débogage), voici ce qui fonctionne vraiment :

```
Frontend (Next.js) → API Gateway → Cloud Run Services → Cloud Workflows → Cloud Storage
                ↓
            Supabase (Auth + Real-time + PostgreSQL + Edge Functions)
```

Note : nous avons migré d'AWS Lambda/Step Functions vers GCP Cloud Run/Workflows en juillet 2025, obtenant une réduction des coûts de 92 % et une amélioration des performances par 10.

La grande révélation : quand j'ai basculé vers des requêtes Supabase directes au lieu d'emballer tout dans des API, j'ai obtenu une amélioration des performances par 10 (450 ms → 45 ms). Tout ce "bon" layering d'API ? Il ne faisait que tout ralentir. Cette architecture database-first est devenue le fondement de notre migration GCP.

Sélection du modèle IA : au-delà du battage médiatique

La réalité du paysage des modèles

Ok, parlons des modèles IA. Je les ai tous essayés. Vraiment essayés — pas juste joué avec pendant un après-midi. Après des mois de tests (et avoir brûlé plus de crédits API que je ne voudrais l'admettre), voici ce qui fonctionne vraiment quand tu construis quelque chose de réel :

Ma stack actuelle de référence :

- Claude (via Claude code) & Gemini 2.5 Pro (via Gemini CLI) : mon duo de développement de base. Ces deux modèles sont devenus si capables qu'ils ont essentiellement remplacé tout le reste dans mon workflow.

- Claude Sonnet 4 API : propulse la génération de scripts de DIALØGUE avec temperature 0 pour la fiabilité JSON

Ce que ma stack incluait auparavant :

DeepSeek : je comptais auparavant sur celui-ci pour déboguer des bugs difficiles, surtout lors de sessions de dépannage nocturnes. Mais une fois que Claude 4 et Gemini 2.5 Pro sont arrivés ? Ils gèrent ces cas limites tout aussi bien, sinon mieux. L'évolution des capacités des modèles a rendu les modèles de débogage spécialisés redondants dans mon workflow.

Ce qui fonctionne vraiment :

Voici où les choses deviennent intéressantes : chaque modèle est déjà incroyablement puissant en lui-même. Claude est brillant pour la pensée architecturale et le raisonnement complexe. Gemini 2.5 Pro ? Absolument phénoménal pour l'implémentation et le maintien du contexte à travers d'immenses codebases. Le saut de Gemini 2.0 à 2.5 était dingue — je pouvais littéralement sentir la différence. Réponses plus rapides, fenêtre de contexte de 1M tokens (oui, vraiment), et il comprend vraiment ce que j'essaie de construire.

Mais voici où la vraie magie opère : quand tu les fais critiquer mutuellement le travail de l'autre. Je vais avoir Claude concevoir une approche, puis demander à Gemini de la réviser et de suggérer des améliorations. Ou Gemini va générer une solution, et je vais avoir Claude l'analyser pour les cas limites ou les préoccupations architecturales. Ce va-et-vient, ce processus de critique collaborative — c'est là qu'on trouve les solutions breakthrough qu'aucun n'aurait atteint seul.

Ce qui n'a pas fonctionné (malgré le battage) :

• OpenAI o1/o3 : tout le monde en parle, mais pour le développement réel ? Trop lent, trop cher, et honnêtement pas tellement meilleur pour mes cas d'usage.
• GitHub Copilot Workspace : bonne idée, mais ces limites de tokens… je n'arrêtais pas de toucher le plafond dès que j'essayais de faire quelque chose de substantiel

L'insight réel : tu sais ce que personne ne te dit ? Les différents modèles échouent différemment. Le Gemini initial se bloquait dans des boucles étranges sur certaines erreurs — il ne parvenait juste pas à voir le problème. Claude le repérait immédiatement. Mais ensuite Claude sur-analysait des implémentations simples que Gemini réglait en quelques secondes. L'astuce n'est pas de trouver le "meilleur" modèle — c'est de savoir quand changer.

Développement full-stack : porter plusieurs casquettes

La stratégie des terminaux

Voici quelque chose de pratique qui a vraiment sauvé ma santé mentale : des fenêtres de terminal séparées pour différents contextes. Ça semble simple ? C'est un game-changer.

```bash
# Terminal 1 : Moi en tant que développeur Frontend
cd podcast_generator_frontend_v2
npm run dev
# C'est là que je réfléchis aux composants React et à l'expérience utilisateur

# Terminal 2 : Moi en tant que développeur Backend
cd gcp_services
./deploy/deploy-service.sh [service-name]
# C'est là que vivent les services Cloud Run (bien plus heureux que Lambda !)

# Terminal 3 : Moi en tant que DBA
supabase start --workdir supabase
# Supabase local pour les tests, production pour le vrai travail
```

Je sais que ça semble ridicule, mais le fait de changer physiquement de terminal aide mon cerveau à changer de contexte. Le moi frontend et le moi backend sont des personnes différentes, et ils ont besoin de leurs propres espaces.

Communication cross-stack

Travailler seul sur du full-stack, c'est bizarre. Tu te retrouves essentiellement à avoir des conversations avec toi-même. Alors j'ai commencé à laisser des notes :

```
// Note de Moi Frontend à Moi Backend
/**
 * BACKEND TODO :
 * - Besoin d'endpoint GET /api/podcasts/:id/segments
 * - Doit retourner : { segments: Array<{id, title, status, content}> }
 * - Doit gérer : 404 (non trouvé), 403 (non autorisé)
 * - Mises à jour en temps réel via abonnement Supabase serait idéal
 * - Le moi futur te remerciera pour la gestion des erreurs !
 */
```

```
## Résumé Backend Developer pour l'intégration Frontend
État actuel :
- Endpoints implémentés : POST /podcasts, GET /podcasts/:id
- Authentification : Bearer token via Supabase JWT
- Temps réel : canal Supabase "podcast-updates"

Prochaines tâches Frontend :
1. Implémenter le formulaire de création de podcast
2. S'abonner aux mises à jour en temps réel
3. Gérer les états d'erreur (401, 403, 404, 500)
```

Ces petites notes ? Des bouées de sauvetage absolues quand je reviens au code après une semaine et que je n'ai aucune idée de ce à quoi je pensais.

Principaux enseignements techniques

1. La pensée systémique transcende les domaines

Mon parcours en publicité m'a appris à penser en systèmes — parcours utilisateurs, funnels de conversion, modèles d'attribution. Ces modèles mentaux se traduisent directement en :

• Conception de systèmes distribués
• Flows d'expérience utilisateur
• Optimisation des performances
• Stratégies de gestion des erreurs

2. Mentalité production-first

# Ce que j'ai appris à prioriser

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Le parfait est l'ennemi du bien

3. La compétence full-stack est réelle

Construire DIALØGUE a requis :

• Frontend : React 19, Next.js 15, TypeScript, abonnements en temps réel, gestion WebSocket (memory leaks corrigés !)
• Backend : Python 3.12, Cloud Run (14 microservices), Cloud Workflows, PostgreSQL (via Supabase)
• Infrastructure : GCP (migré depuis AWS), API Gateway, Cloud Storage, Vercel pour le frontend
• IA/ML : Claude 4.0, Perplexity API, OpenAI TTS, optimisation temperature (0 pour JSON)
• DevOps : containers Docker, Cloud Build, monitoring, sécurité JWT (migration P-256)
• Base de données : PostgreSQL avec RLS, Edge Functions, opérations atomiques pour la prévention des race conditions

4. L'importance de la formation classique

Avoir une formation formelle en ingénierie logicielle (conception de systèmes, structures de données, algorithmes) s'est révélé inestimable. Il ne s'agit pas seulement d'obtenir que l'IA écrive du code — c'est de savoir quoi demander et comment l'architécter.

Réflexions finales

Voilà où j'en suis après tout ça : construire DIALØGUE a complètement changé la façon dont je me vois professionnellement. J'étais celui qui gérait des équipes techniques. Maintenant ? Je peux vraiment construire à leurs côtés. Et honnêtement, ça, c'est plutôt génial. :D Cette évolution a continué quand j'ai commencé à construire une appli iOS native sans connaître Swift — il s'avère que les compétences publicitaires (le goût, la direction créative, savoir ce que "bon" signifie) comptent plus que les compétences en codage.

Le voyage de la publicité à l'ingénierie ne se résume pas à apprendre la syntaxe ou les frameworks. C'est recâbler ton cerveau pour penser en systèmes, déboguer de façon méthodique, et accepter que parfois tu passeras 3 heures sur un point-virgule manquant (ok, TypeScript les attrape, mais tu vois l'idée).

Tu sais ce qui est drôle ? La pensée analytique de la publicité — comprendre les parcours utilisateurs, optimiser les funnels de conversion, tout ça — se traduit directement en ingénierie. La différence, c'est qu'en code, quand quelque chose ne fonctionne pas, l'ordinateur te le dit immédiatement. Pas d'attente pour les rapports de campagne. Juste un feedback immédiat, brutal.

Le "produit" est en ligne sur podcast.chandlernguyen.com. Ça fonctionne. Ce n'est pas parfait, mais c'est le mien. Et chaque correction de bug, chaque ajout de fonctionnalité, chaque moment "aha !" — ils font tous partie de ce voyage continu.

As-tu déjà fait un grand pivot de carrière — d'un domaine vers quelque chose de complètement différent ? J'adorerais entendre ce qui t'a le plus surpris dans la transition. Dis-moi !

Cordialement,

Chandler

P.S : En parlant d'apprendre les choses à la dure — tu veux savoir comment un tout petit changement de paramètre IA m'a coûté 54 $/mois ? Lis Un seul paramètre IA m'a coûté 54 $/mois. C'est une histoire édifiante sur ce qui arrive quand tu fais confiance à des assistants IA pour du code de production sans être explicite sur les contraintes de production. Spoiler : "faire en sorte que ça marche" et "faire en sorte que ce soit prêt pour la production" sont des requêtes très différentes.

P.P.S : Je suis encore en train de comprendre tout ce truc d'ingénierie, un bug à la fois. En ce moment je construis des applications alimentées par l'IA et j'essaie de ne pas casser la production. Reviens sur ce blog plus tard pour la suite.