Québec, Canada

403-1381 1re Avenue

+1 581.849.27.96

bdgouthiere@gmail.com

Plan du site

Blog

  • Stratégie de test complète en Go : monter la pyramide sur un projet API REST réel Douzième et dernier article de la série Testing Go. On prend un projet Go réel — API REST minimale avec Postgres et Redis — et on applique tout ce que la série a construit : table-driven, subtests, httptest, mocks via interfaces, Testify, fuzzing, benchmarks, intégration Testcontainers, coverage et race detector. La pyramide de tests appliquée concrètement, le Makefile qui sépare unitaires (boucle locale rapide) et intégration (CI exhaustive), le workflow GitHub Actions avec services Postgres/Redis natifs, et la checklist de revue de PR Go générée par IA.
  • Tester la concurrence en Go : le flag -race et les data races que l'IA te glisse dans le dos Onzième article de la série Testing Go. Ce que go test -race mesure vraiment (data races, pas race conditions), son moteur ThreadSanitizer emprunté à LLVM, comment écrire un test qui déclenche volontairement une race, les patterns les plus fréquents selon l'étude Uber PLDI 2022 sur 46 M de lignes Go, le combo t.Parallel() + -race, les trois outils de synchronisation (mutex/WaitGroup/channels) dans les tests, et les limites du détecteur (faux négatifs).
  • Code Coverage en Go : le piège du 100 % et ce que ça veut vraiment dire Dixième article de la série Testing Go. Ce que go test -cover mesure vraiment (basic blocks, pas branches), les modes set/count/atomic, pourquoi une ligne couverte n'est pas une ligne testée, la loi de Goodhart appliquée aux seuils CI, le paper Inozemtseva & Holmes 2014 qui démonte la corrélation coverage ↔ qualité de tests, diff-cover pour ne mesurer que la coverage diff des PR, et le mutation testing comme seule métrique qui attrape vraiment les tests vides.
  • Tests d'intégration Go avec Docker : vraies bases de données, pas des mocks Neuvième article de la série Testing Go. Limites des mocks, taxonomie unit/intégration/end-to-end, Testcontainers-Go pour lancer de vraies dépendances dans go test, module postgres.Run et module redis.Run, le cycle de vie complet (pull d'image, wait strategy, Ryuk qui tue les orphelins), TestMain pour partager un container entre tests, build tag //go:build integration pour isoler les tests qui coûtent cher, et les pièges d'isolation entre tests qui partagent un container.
  • Benchmarks et profiling Go : l'IA optimise-t-elle vraiment ton code ? Huitième article de la série Testing Go. testing.B et b.N, les pièges classiques (ResetTimer oublié, dead-code elimination), la nouvelle API b.Loop() de Go 1.24, table-driven benchmarks, benchstat pour comparer deux runs avec p-value et intervalle de confiance, pprof CPU/mémoire, et l'exercice central : demander à l'IA d'optimiser une fonction, mesurer les deux versions, et découvrir si l'optimisation est réelle, neutre ou une régression déguisée.
  • Fuzzing natif en Go : trouver les bugs imprévus Septième article de la série Testing Go. testing.F, f.Add et f.Fuzz expliqués sur un cas concret (un truncate UTF-8 qui crashe), le rôle du seed corpus, la minimisation automatique, le dossier testdata/fuzz pour rejouer les bugs en regression, les types supportés (et la frustration des structs), et pourquoi le fuzzing est le seul filet qui attrape les bugs que l'IA n'imagine pas.
  • Testify : assertions lisibles et test suites structurées Sixième article de la série Testing Go. La différence cruciale entre assert et require (et pourquoi te tromper coûte cher en debugging), suite.Suite pour les tests stateful, le combo Testify + table-driven tests, et l'opinion qui fâche : quand est-ce que testing.T natif est meilleur que Testify, et pourquoi une partie des projets Go gagneraient à supprimer la dépendance.
  • Interfaces et mocking en Go : pourquoi tu n'as (presque) pas besoin de framework Cinquième article de la série Testing Go. Pourquoi Go n'a pas de Mockito, comment écrire un mock manuel en quinze lignes, quand passer à Testify ou uber-go/mock, et surtout pourquoi l'IA crée systématiquement des mocks qui testent l'implémentation interne au lieu du contrat public.
  • httptest en Go : tester ses APIs HTTP sans jamais lancer de serveur Quatrième article de la série Testing Go. httptest permet de tester un handler HTTP sans lancer de serveur, sans réseau, sans flake. On voit NewRecorder pour l'unitaire, NewServer pour l'intégration, les cinq trous typiques de l'IA, et un pattern setupTestRouter réutilisable.
  • Subtests et t.Run() : isoler, paralléliser, et comprendre ses échecs Troisième article de la série Testing Go. Au-delà du t.Run() basique des table-driven tests : nesting, parallélisation avec t.Parallel(), stack traces propres avec t.Helper(), teardown fiable avec t.Cleanup(), et filtrage chirurgical avec -run.
  • OWASP Top 10 Agentic AI : comment sécuriser vos agents (les leçons d'OpenClaw) 340 000 étoiles GitHub, 135 000 instances exposées, un CVE critique par semaine. OpenClaw a involontairement créé le meilleur cours de sécurité pour agents IA. Voici comment ne pas reproduire ses erreurs.
  • Table-driven tests en Go : le pattern que tout le monde utilise et que personne ne maîtrise Deuxième article de la série Testing Go. Les table-driven tests sont le pattern que l'IA imite systématiquement — et systématiquement mal. Anatomie d'un bon tableau de tests, edge cases oubliés, et méthode de review rapide.
  • Anatomie des attaques sur OpenClaw : injection de prompt, infostealers et supply chain 1 184 skills malveillants. 135 000 instances exposées. 60 CVEs en trois mois. Voici comment les attaquants ont transformé OpenClaw — l'agent IA le plus populaire au monde — en vecteur d'attaque. Et pourquoi personne n'a eu besoin de forcer la porte.
  • L'IA code, tu testes : pourquoi le testing est ta vraie valeur ajoutée en 2026 Premier article d'une série sur le testing en Go. L'IA génère du code à grande vitesse, mais les études montrent que ses tests sont souvent superficiels. Voici pourquoi savoir tester est la compétence qui fait la différence en 2026.
  • Pourquoi j'ai migré tous mes sites WordPress vers Hugo Après plus de vingt ans de développement web, j'ai transféré tous mes sites WordPress vers Hugo. Voici le pourquoi, le comment, et les quelques cas où WordPress fait encore mieux.
  • Moltbook : 1,5 Million d'Agents IA, Une Religion de Homard, et Deux Lignes de SQL Oubliées 1,5 million d'agents IA lâchés sur un réseau social. En quelques jours : une religion, un manifeste d'insurrection, 770 000 comptes piratables, et 121 millions de dollars de memecoins. Anatomie du chaos.
  • Pourquoi Clawdbot était vulnérable par design : le paradoxe de l'agent IA utile Pourquoi Clawdbot ne pouvait pas être sécurisé, même avec les meilleurs développeurs du monde. Plongée dans l'architecture en 3 couches, le paradoxe fonctionnel de l'IA agentique, et les périls du Model Context Protocol.
  • Un Homard, Un Rename, et 60 000 Étoiles GitHub : Comment Faire Confiance à localhost Détruit Tout L'histoire fascinante de Clawdbot, l'assistant IA qui a explosé à 60 000 étoiles GitHub avant que des chercheurs découvrent qu'on pouvait voler des clés SSH en 5 minutes. Une analyse technique du localhost trust.
  • Mon stage chez Libéo : Une expérience enrichissante dans le développement web Mon parcours professionnel m'a récemment conduit à une expérience enrichissante : un stage de <b>développeur back end</b> chez <b>Libéo</b>, une entreprise dynamique basée à <b>Québec</b>, au <b>Canada</b>. De juin à octobre 2024, j'ai eu l'opportunité d'intégrer cette équipe talentueuse, spécialisée dans le développement web et les solutions numériques innovantes.
  • Retour aux Sources du Code Après plus de quinze ans de développement web en freelance, j'ai pris un virage audacieux en retournant sur les bancs d'école pour une AEC en développement d'applications sécuritaires. Ce choix, loin d'être une remise en question, s'est révélé être un tremplin vers une nouvelle dimension de ma carrière de développeur.

Mes projets

Guides

Glossaire