Blog

Ici, tu trouveras des contenus faits pour durer : des cadres de décision, des procédures reproductibles, et des retours de terrain sur ce qui casse quand un projet grossit.

Ce n’est pas une collection d’astuces. C’est une base de connaissance : on explique le pourquoi, on explicite les trade-offs, et on te donne des critères pour choisir (ou refuser) une option.

Explorer par thème #

Architecture logicielle #

Structurer, modulariser, limiter la dette, et garder un système lisible à mesure qu’il grandit.

  • séparation des responsabilités, découpage, couplage/cohésion
  • décisions réversibles vs irréversibles, ADRs, signaux de dette
  • refactoring guidé par contraintes (et pas par esthétique)

→ Aller à la section : Architecture

Hugo et plateforme de blog #

Construire une plateforme éditoriale maintenable : i18n, arborescence, pipeline, conventions utiles (pas décoratives).

  • organiser les contenus et ressources sans se tirer une balle dans le pied
  • i18n propre (FR/EN), résumés, sections, taxonomies
  • hygiène : templates, naming, cohérence éditoriale

→ Aller à la section : Hugo

JVM #

Kotlin/Java côté pratique : contraintes réelles, intégration, outillage, et choix qui tiennent dans le temps.

  • sérialisation, modèles de données, compatibilité
  • build/outillage (quand ça aide, quand ça ralentit)
  • choix de design orientés maintenabilité

→ Aller à la section : JVM

IDE et outillage (VS Code) #

Le poste de pilotage du dev moderne : workflow, automatisation, agents/outils, et limites à poser.

  • configuration qui change vraiment le quotidien (pas du tuning cosmétique)
  • intégration IA “utile” (tests, revue, doc, refactor) + garde-fous
  • routines : qualité, lint, CI, feedback loops

→ Aller à la section : IDE & Tooling

Comment lire ce blog #

  • Si tu veux aller vite, commence par le thème qui te fait le plus mal aujourd’hui.
  • Si tu veux mettre de l’ordre, lis d’abord architecture puis outillage (le reste suit).
  • Si tu veux industrialiser l’écriture, passe par Hugo : structure + i18n + pipeline.

Les conventions de contribution (structure des fichiers, archetypes, workflow de publication) doivent vivre dans une page dédiée “Contribuer”, pas ici.

Derniers articles

Kotlin 2.3 : 5 nouveautés vraiment utiles (et quoi activer tout de suite)

Kotlin 2.3.0 est une release de maturité : moins de “features tape-à-l’œil”, plus de garde-fous, de DX et de perf. Elle ne “change pas votre façon de coder” par magie — mais elle vous évite des classes entières de bugs et réduit du boilerplate si vous activez les bons interrupteurs. :contentReference[oaicite:0]{index=0}

TL;DR #

  • Détecter les valeurs de retour ignorées (opt-in) → moins de bugs silencieux. :contentReference[oaicite:1]{index=1}
  • Explicit backing fields (expérimental) → fin du duo _state / state et smart-cast sur field. :contentReference[oaicite:2]{index=2}
  • UUID v7 + parseOrNull (API UUID expérimentale) → IDs triables temporellement, parsing sans exceptions. :contentReference[oaicite:3]{index=3}
  • Kotlin/Native + Swift export → enums et vararg plus naturels côté Swift + builds release jusqu’à ~40% plus rapides. :contentReference[oaicite:4]{index=4}
  • Kotlin/Wasm → binaires jusqu’à ~13% plus légers + KClass.qualifiedName activé par défaut, grâce au stockage compact Latin-1. :contentReference[oaicite:5]{index=5}

Lire la suite →

VS Code : Agent Skills — capitaliser du savoir-faire sans saturer le contexte

TL;DR #

  • Un LLM sans contexte n’est pas “mauvais” : il est généraliste. Les Agent Skills servent à injecter du savoir-faire procédural au bon moment, sans noyer la fenêtre de contexte.
  • Une skill = un dossier (portable) avec SKILL.md (YAML name + description obligatoires) + ressources (scripts, templates, exemples).
  • Chargement à la demande via déclenchement sémantique (match sur description) + divulgation progressive en 3 niveaux (métadonnées → instructions → ressources).
  • Dans VS Code 1.108, le support est expérimental et se pilote avec chat.useAgentSkills.1
  • Combinez Skills (le quoi) + Custom Agents (le qui) + Handoffs (le workflow) pour arrêter de “prompt-hacker”.

Lire la suite →

Articles plus anciens 10

VS Code : mettre en place un workflow d’ingénierie de contexte (instructions, agents, handoffs)

TL;DR #

  • Un assistant IA sans contexte n’est pas “bête” : il est aveugle. Et votre projet paie la facture (erreurs, tours de manège, décisions incohérentes).
  • L’ingénierie de contexte, ce n’est pas écrire de meilleurs prompts : c’est rendre le bon contexte disponible, au bon moment, de façon versionnée.
  • Dans VS Code, le workflow le plus robuste tient en 3 briques :
    1. instructions globales (.github/copilot-instructions.md)
    2. agent “Plan” (outils lecture seule) → produit un plan stable
    3. agent “Implementation” (édition + terminal) → exécute le plan
    • des handoffs pour passer de l’un à l’autre sans perdre le fil.

Lire la suite →

4 révélations qui vont transformer votre approche de la null-safety en Java (JSpecify + NullAway)

TL;DR #

  • JSpecify 1.0.0 met fin à la tour de Babel des @Nullable en standardisant 4 annotations stables.
  • @NullMarked inverse le défaut : non-null par défaut, @Nullable devient l’exception visible.
  • IDE et CI convergent : IntelliJ et NullAway se sont alignés (notamment sur les suppressions).
  • TYPE_USE rend la nullité “chirurgicale” (tableaux, génériques), mais il faut apprendre la grammaire.

Lire la suite →

La null-safety de Kotlin n’est pas de la magie — c’est un contrat écrit dans le bytecode

TL;DR #

La null-safety de Kotlin n’est pas une magie de l’IDE : c’est un contrat encodé dans le bytecode1. Le compilateur publie la nullabilité via @kotlin.Metadata et des annotations @NotNull/@Nullable, que l’IDE lit pour t’avertir23. Et si du code Java passe quand même null, Kotlin échoue immédiatement à la frontière avec Intrinsics.checkNotNullParameter(...), ce qui évite de propager un état corrompu plus profondément dans ton code.4

Lire la suite →

Kotlin ↔ Java : la null-safety, c’est un contrat (et comment Kotlin le fait respecter)

TL;DR #

En interop Kotlin ↔ Java, la null-safety n’est pas magique :

  • Kotlin→Java : le compilateur publie la nullabilité dans le bytecode (annotations @NotNull/@Nullable + @kotlin.Metadata), donc l’IDE voit le contrat.
  • Java→Kotlin : si Java passe quand même null là où Kotlin exige non-null, Kotlin fail-fast à la frontière via Intrinsics.checkNotNullParameter(...).
  • Le vrai point faible : quand Kotlin consomme des API Java non annotées → types “platform” (String!) = nullabilité inconnue → c’est là que les bugs se glissent.

Lire la suite →

AI & Java : passer des prompts au logiciel (vraiment) – mémoire, outils, JSON et Quarkus

Inspiré de la conf vJUG CONNECT “AI & Java: From Structured Prompts to Smarter Apps” (YouTube).

TL;DR #

Si tu retiens une seule idée : le “prompt engineering” n’est pas le sujet. Le sujet, c’est l’ingénierie du contexte et du contrat entre ton code et le modèle :

  • mémoire (court/long terme, cohérence, conflits),
  • outils (fonctions appelables par le LLM),
  • sorties structurées (JSON/records/enums au lieu de texte libre),
  • observabilité + timeouts + fallbacks (parce que “ça marche en démo” ne vaut rien en prod).

La conf le dit sans détour : ce n’est pas de la magie, c’est du logiciel.

Lire la suite →

«« « 1 2 » »»