https://pages-content.github.io/ JBake Bootstrap Template en-gb Tue, 12 May 2026 19:45:21 +0000 Tue, 12 May 2026 19:45:21 +0000 https://pages-content.github.io//blog/2026/0123_knowledge_graph_moteur_recommandation_articles_connexes_post.html Tue, 12 May 2026 00:00:00 +0000 blog/2026/0123_knowledge_graph_moteur_recommandation_articles_connexes_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#la_scène_mardi_12_mai_17h30">1. La Scène : Mardi 12 Mai, 17h30</a></li> <li><a href="#le_diagnostic_trois_types_de_relations_quaucun_template_ne_voit">2. Le Diagnostic : Trois Types de Relations Qu’Aucun Template Ne Voit</a></li> <li><a href="#la_solution_un_pipeline_gradle_pas_un_appel_llm_à_chaud">3. La Solution : Un Pipeline Gradle, Pas un Appel LLM à Chaud</a> <ul class="sectlevel2"> <li><a href="#larchitecture_bakery_importe_graphify_pas_engine">3.1. L’Architecture : Bakery Importe Graphify, Pas Engine</a></li> <li><a href="#le_pipeline_scan_graphe_template">3.2. Le Pipeline : Scan → Graphe → Template</a></li> <li><a href="#fallback_chronologique">3.3. Fallback Chronologique</a></li> </ul> </li> <li><a href="#lontologie_émergente_quand_les_articles_se_regroupent_sans_se_connaître">4. L’Ontologie Émergente : Quand les Articles Se Regroupent Sans Se Connaître</a></li> <li><a href="#le_contrat_dag_qui_importe_qui">5. Le Contrat DAG : Qui Importe Qui</a></li> <li><a href="#ce_quon_gagne_et_ce_quon_ne_gagne_pas">6. Ce Qu’on Gagne (Et Ce Qu’on Ne Gagne Pas)</a></li> <li><a href="#perspectives_le_blog_comme_knowledge_graph_public">7. Perspectives : Le Blog Comme Knowledge Graph Public</a></li> <li><a href="#conclusion_le_système_de_fichiers_sait_ce_que_le_template_ignore">8. Conclusion : Le Système de Fichiers Sait Ce Que le Template Ignore</a></li> <li><a href="#références">9. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 14 minutes</div> <p>Vous lisez un article sur l’intégration de pgvector avec LangChain4j. En bas de page, JBake vous suggère « Articles connexes ». Vous cliquez. C’est un article sur…​ la configuration de Kitty Terminal. Le seul point commun entre les deux ? Ils ont été publiés à moins de quinze jours d’écart. Ce n’est pas une recommandation. C’est un calendrier déguisé en éditorial.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_scène_mardi_12_mai_17h30">1. La Scène : Mardi 12 Mai, 17h30</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je relis un de mes articles — <a href="0106_knowledge_graph_outil_comprehension_codebase_post.html">celui sur le Knowledge Graph comme outil de compréhension de codebase</a>. Le contenu est dense : nœuds, arêtes, communautés, PlantUML, onboarding. Un article technique de 15 minutes de lecture qui mobilise <code>graphify-gradle</code>, <code>plantuml-gradle</code>, et les concepts de topologie de graphe.</p> </div> <div class="paragraph"> <p>En bas de page, les « Articles connexes » me proposent :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Un article sur Firebase Contact Form (0113)</p> </li> <li> <p>Un article sur le mécanisme Eager/Lazy (0108)</p> </li> <li> <p>Un article sur la migration Gradle script → plugin (0102)</p> </li> <li> <p>Un article sur le cumul d’abonnements Ollama Pro (0120)</p> </li> </ol> </div> <div class="paragraph"> <p>Trois de ces quatre articles n’ont <strong>aucun</strong> rapport avec le Knowledge Graph. Ils sont là parce qu’ils sont les derniers publiés — voisinage temporel, pas voisinage sémantique.</p> </div> <div class="paragraph"> <p>Je regarde le template <code>post.thyme</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-xhtml hljs" data-lang="xhtml"><!-- Articles connexes (liens internes SEO) --> <th:block th:each="post,postStat : ${published_posts}"> <th:block th:if="${!post.uri.equals(content.uri) and postStat.index lt 4}"> ... </th:block> </th:block></code></pre> </div> </div> <div class="paragraph"> <p><code>published_posts</code> est une liste chronologique. <code>postStat.index lt 4</code> prend les quatre premiers qui ne sont pas le post courant. C’est tout. Aucune logique de similarité. Aucune notion de contenu. Juste une boucle <code>for</code> déguisée en recommandation.</p> </div> <div class="admonitionblock warning"> <table> <tr> <td class="icon"> <i class="fa icon-warning" title="⚠️"></i> </td> <td class="content"> <div class="paragraph"> <p>Ce n’est pas un bug de JBake. C’est le comportement par défaut de tout générateur de site statique : la liste des posts est plate et ordonnée par date. Le template fait ce qu’il peut avec ce qu’il a.</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>Mais ce n’est pas une raison pour l’accepter.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_diagnostic_trois_types_de_relations_quaucun_template_ne_voit">2. Le Diagnostic : Trois Types de Relations Qu’Aucun Template Ne Voit</h2> <div class="sectionbody"> <div class="paragraph"> <p>Mon corpus d’articles — 23 posts en 4 mois — a une structure riche que le template chronologique écrase complètement :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Références explicites</strong> : j’utilise <code>xref:</code> massivement dans mes articles. L’article 0122 référence 0106 (knowledge graph) et 0116 (compartimentage épistémique). Ces liens sont du <strong>hard linking</strong> éditorial — j’ai délibérément décidé de connecter ces concepts.</p> </li> <li> <p><strong>Tags partagés</strong> : chaque article a des <code>:jbake-tags:</code>. L’article sur Graphify + PlantUML (0105) a <code>gradle, graphify, plantuml, knowledge-graph</code>. L’article sur le Knowledge Graph (0106) a <code>knowledge-graph, graphify, plantuml</code>. Trois tags en commun sur sept — 43% de recouvrement.</p> </li> <li> <p><strong>Entités nommées co-occurrentes</strong> : « pgvector », « RAG », « embedding » apparaissent ensemble dans quatre articles différents. « LangChain4j », « Ollama », « plugin Gradle » dans six autres. Ce ne sont pas des tags déclarés — ce sont des <strong>patterns émergents</strong> du corpus que seul un NLP peut détecter.</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="./images/trois-couches-relation-articles.svg" alt="trois couches relation articles" width="1110" height="239"> </div> </div> <div class="paragraph"> <p>Aujourd’hui, mon site n’utilise <strong>aucune</strong> de ces trois couches. Il utilise la couche zéro : l’ordre d’insertion dans une liste Java.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_un_pipeline_gradle_pas_un_appel_llm_à_chaud">3. La Solution : Un Pipeline Gradle, Pas un Appel LLM à Chaud</h2> <div class="sectionbody"> <div class="paragraph"> <p>La première tentation serait d’appeler un LLM au moment du bake : « Pour cet article, trouve les trois articles les plus similaires dans le corpus. » Ne faites pas ça.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Un appel LLM à chaque <code>./gradlew bake</code> coûte du temps, de l’argent, et introduit de la non-déterminisme dans votre build. La réponse du LLM peut changer entre deux builds sans que le contenu ait changé. Votre CI devient non reproductible, vos tests deviennent flaky.</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>La solution est déterministe : un pipeline Gradle qui pré-calcule le graphe de similarité et le stocke dans <code>graph.json</code>. Le template lit le résultat — jamais il ne déclenche un calcul.</p> </div> <div class="sect2"> <h3 id="larchitecture_bakery_importe_graphify_pas_engine">3.1. L’Architecture : Bakery Importe Graphify, Pas Engine</h3> <div class="paragraph"> <p>C’est le point d’architecture le plus important. La tentation serait de câbler la collaboration dans <code>engine/build.gradle.kts</code> : engine applique graphify pour le scan, bakery pour le bake, et engine fait le pont entre les deux.</p> </div> <div class="paragraph"> <p>C’est un anti-pattern. Engine est un <strong>terminal consommateur</strong> — il applique des plugins, il n’implémente pas de logique métier. La règle est : <strong>la charge de la preuve est sur le plugin propriétaire.</strong></p> </div> <div class="imageblock"> <div class="content"> <img src="./images/bakery-import-graphify.svg" alt="bakery import graphify" width="489" height="439"> </div> <div class="title">Figure 1. Architecture correcte — Bakery importe Graphify</div> </div> <div class="paragraph"> <p>Le contrat DAG est respecté : bakery (N2) importe graphify (N0), N2 > N0, aucune violation. Engine (N3) importe bakery (N2), N3 > N2, OK.</p> </div> <div class="paragraph"> <p>Engine n’a <strong>aucune</strong> ligne de code qui référence <code>graph.json</code>, <code>relatedPosts</code>, ou toute autre notion de similarité. Il applique bakery, point. La collaboration est interne à bakery.</p> </div> </div> <div class="sect2"> <h3 id="le_pipeline_scan_graphe_template">3.2. Le Pipeline : Scan → Graphe → Template</h3> <div class="paragraph"> <p>Voici le pipeline complet en trois étapes :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Scan</strong> (graphify) : <code>graphify-plugin</code> scanne le workspace. Dans sa forme actuelle, il détecte déjà les <code>xref:</code> entre <code>.adoc</code> et les expose dans <code>graph.json</code> comme des edges de type <code>reference</code>.</p> <div class="paragraph"> <p>On l’enrichit pour le contenu éditorial : * Parse les métadonnées JBake (<code>:jbake-tags:</code>, <code>:jbake-description:</code>) de chaque <code>.adoc</code> du blog * Calcule les co-occurrences de tags → edges <code>tag_cooccurrence</code> avec poids * Extrait les entités nommées des descriptions via TF-IDF → edges <code>entity_overlap</code> * Injecte une section <code>blog_articles</code> dans le <code>graph.json</code> existant</p> </div> <div class="paragraph"> <p>+</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// Extrait de l'enrichissement graphify pour le blog fun enrichBlogSection(graphJson: File, blogDir: File): GraphJson { val articles = blogDir.listFiles { f -> f.extension == "adoc" } .map { parseJbakeMetadata(it) } val nodes = articles.map { ArticleNode(it.slug, it.title, it.tags) } val edges = mutableListOf<GraphEdge>() // Couche 1 : xref (déjà fait par scanWorkspace) // Couche 2 : co-occurrences de tags for (a in articles) { for (b in articles) { if (a.slug == b.slug) continue val common = a.tags.intersect(b.tags) if (common.isNotEmpty()) { edges.add(GraphEdge( source = a.slug, target = b.slug, type = "tag_cooccurrence", weight = common.size.toDouble() / (a.tags.size + b.tags.size) )) } } } return graphJson.copy( blogArticles = BlogSection(nodes, edges) ) }</code></pre> </div> </div> </li> <li> <p><strong>Bake</strong> (bakery) : au moment du <code>./gradlew bake</code>, <code>BakeryPlugin</code> lit <code>graph.json</code> et résout les articles connexes pour chaque post.</p> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// BakeryPlugin — résolution des articles connexes fun resolveRelatedPosts( currentSlug: String, graph: GraphJson, maxResults: Int = 4 ): List<RelatedPost> { val edges = graph.blogArticles.edges .filter { it.source == currentSlug || it.target == currentSlug } return edges .sortedByDescending { it.weight } .take(maxResults) .map { edge -> val relatedSlug = if (edge.source == currentSlug) edge.target else edge.source graph.blogArticles.nodes.first { it.slug == relatedSlug } } }</code></pre> </div> </div> </li> <li> <p><strong>Template</strong> (<code>post.thyme</code>) : le modèle JBake reçoit maintenant une map structurée au lieu d’une liste chronologique plate.</p> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-xhtml hljs" data-lang="xhtml"><!-- Articles connexes basés sur le Knowledge Graph --> <th:block th:if="${relatedPosts != null and !relatedPosts.empty}"> <section class="mt-5 pt-4 border-top"> <h2 class="h4 mb-3">Articles connexes</h2> <th:block th:each="related : ${relatedPosts}"> <div class="mb-2"> <a th:href="${content.rootpath} + ${related.uri}" th:text="${related.title}" class="fw-semibold"></a> <br/> <small class="text-muted"> <th:block th:each="reason,iterStat : ${related.reasons}"> <span class="badge bg-light text-dark" th:text="${reason}"></span> </th:block> </small> </div> </th:block> </section> </th:block></code></pre> </div> </div> </li> </ol> </div> <div class="paragraph"> <p>Le template est le même — il ne sait pas <strong>d’où</strong> viennent les données. Seul le contrat entre bakery et JBake a changé : <code>published_posts</code> (liste chronologique) devient <code>relatedPosts</code> (map pondérée par le graphe).</p> </div> <div class="exampleblock"> <div class="content"> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> Le badge « raison » (ex: <code>xref 0122</code>, <code>tag:gradle</code>, <code>cluster:pgvector-rag</code>) explique au lecteur <strong>pourquoi</strong> cet article est connexe. Ce n’est pas juste de la transparence — c’est de la pédagogie sur la topologie de votre propre contenu. </td> </tr> </table> </div> </div> </div> </div> <div class="sect2"> <h3 id="fallback_chronologique">3.3. Fallback Chronologique</h3> <div class="paragraph"> <p>Si <code>graph.json</code> est absent (build local sans scan préalable, premier déploiement, CI qui n’a pas encore intégré le scan graphify), le template doit dégrader gracieusement :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">fun resolveRelatedPosts(currentSlug: String, graph: GraphJson?): List<RelatedPost> { if (graph != null && graph.blogArticles != null) { return resolveFromGraph(currentSlug, graph) } // Fallback chronologique — même comportement qu'aujourd'hui logger.warn("[bakery] graph.json absent — fallback chronologique") return resolveFromChronology(currentSlug) }</code></pre> </div> </div> <div class="paragraph"> <p>Le comportement par défaut est identique au comportement actuel. Le moteur de recommandation est une <strong>amélioration progressive</strong> — pas un breaking change.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="lontologie_émergente_quand_les_articles_se_regroupent_sans_se_connaître">4. L’Ontologie Émergente : Quand les Articles Se Regroupent Sans Se Connaître</h2> <div class="sectionbody"> <div class="paragraph"> <p>La couche la plus intéressante est la troisième : l’ontologie émergente. Des articles qui ne se citent pas, qui n’ont pas les mêmes tags, mais qui <strong>parlent de la même chose</strong> sans le savoir.</p> </div> <div class="paragraph"> <p>Prenons un exemple concret. Trois articles de mon corpus :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>0119 — Benchmark DGX Spark vs Cloud Abonnement LLM</p> </li> <li> <p>0121 — Plugin Gradle Piloter Deux Instances Ollama Pro</p> </li> <li> <p>0122 — Ratio Efficacité 27x 45x Flotte Experts IA</p> </li> </ol> </div> <div class="paragraph"> <p>Ces trois articles n’ont <strong>aucun</strong> xref entre eux. Leurs tags ne se recoupent qu’à 20% (« ollama », « llm » communs). Mais un NLP léger sur les descriptions révèle un cluster évident : « coût », « abonnement », « cloud », « GPU », « API key », « Ollama Pro », « efficacité », « ratio ».</p> </div> <div class="paragraph"> <p>Ils forment un cluster ontologique : <strong>l’économie du LLM self-hosted vs cloud</strong>. Ce cluster n’est déclaré nulle part. Il émerge du corpus.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/cluster-ontologique-exemple.svg" alt="cluster ontologique exemple" width="697" height="405"> </div> </div> <div class="paragraph"> <p>Ce cluster ontologique devient un edge composite dans <code>graph.json</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-json hljs" data-lang="json">{ "source": "0119-benchmark-dgx-spark", "target": "cluster:economie-llm", "type": "entity_cluster", "weight": 0.73, "metadata": { "clusterLabel": "Économie LLM Self-Hosted vs Cloud", "commonEntities": ["coût", "GPU", "abonnement", "Ollama Pro", "ratio"], "articlesInCluster": [ "0119-benchmark-dgx-spark", "0121-ollama-pro-deux-instances", "0122-ratio-efficacite-flotte-experts" ] } }</code></pre> </div> </div> <div class="paragraph"> <p>Le NLP est volontairement léger — TF-IDF + cosine similarity sur les descriptions. Pas besoin de BERT, pas besoin de modèle de langage. Le corpus fait 23 articles, la matrice de similarité tient dans un fichier JSON de 50 Ko.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> <div class="paragraph"> <p>La puissance du NLP ne vient pas de la sophistication de l’algorithme, mais de la <strong>taille du corpus</strong> et de la <strong>qualité des descriptions</strong>. Une <code>:jbake-description:</code> bien écrite de 150 caractères contient plus de signal pour TF-IDF qu’un article entier de 3000 mots.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="le_contrat_dag_qui_importe_qui">5. Le Contrat DAG : Qui Importe Qui</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’est le point où la discipline architecturale paie. Le DAG N0→N3 défini dans <code>engine/build.gradle.kts</code> donne une règle simple : aucun projet n’importe un projet de niveau supérieur.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 27.2728%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Plugin consommateur</th> <th class="tableblock halign-left valign-top">Plugin importé</th> <th class="tableblock halign-left valign-top">Niveau consommateur</th> <th class="tableblock halign-left valign-top">Niveau importé</th> <th class="tableblock halign-left valign-top">Valide ?</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">bakery-gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">graphify-gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N0</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ N2 > N0 — OK</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">engine</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">bakery-gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ N3 > N2 — OK</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">engine</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">graphify-gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N0</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Technique OK, mais <strong>conceptuellement faux</strong> — la collaboration est interne à bakery</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Engine applique bakery. Bakery applique graphify. C’est tout. Si un jour je veux ajouter le vector store codebase (N1) pour de la recherche sémantique cross-corpus, bakery l’importe aussi. Engine ne change pas.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Le pattern est : <strong>le plugin N2 est le hub de ses propres dépendances</strong>. Engine N3 n’est pas un hub — c’est un terminal qui applique des hubs.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="ce_quon_gagne_et_ce_quon_ne_gagne_pas">6. Ce Qu’on Gagne (Et Ce Qu’on Ne Gagne Pas)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le gain principal est éditorial, pas technique :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 50%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Avant</th> <th class="tableblock halign-left valign-top">Après</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Articles connexes = 4 derniers posts</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Articles connexes = top 4 par poids dans le Knowledge Graph</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Lecteur lit du RAG → recommandation Kitty Terminal</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Lecteur lit du RAG → recommandation pgvector, chunking, vector store</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Zéro transparence sur le pourquoi</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Badge <code>xref 0122</code>, <code>tag:gradle</code>, <code>cluster:rag</code> visible</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">JBake standard, zéro effort, zéro valeur</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pipeline Gradle déterministe, reproductible, testable</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucune courbe d’apprentissage pour le lecteur</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le lecteur découvre la <strong>topologie</strong> de mon contenu</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Ce qu’on <strong>ne</strong> gagne pas : * Ce n’est pas un « vrai » moteur de recommandation (pas de collaborative filtering, pas d’A/B testing, pas de feedback loop) * La qualité dépend de la richesse des métadonnées JBake — si vos descriptions sont vides, TF-IDF ne voit rien * Le NLP est offline — les nouveaux articles ne sont clusterisés qu’au prochain scan (c’est bien : le build reste déterministe)</p> </div> </div> </div> <div class="sect1"> <h2 id="perspectives_le_blog_comme_knowledge_graph_public">7. Perspectives : Le Blog Comme Knowledge Graph Public</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette fonctionnalité ouvre une perspective plus large : et si <code>cheroliv.com</code> devenait lui-même un <strong>knowledge graph navigable</strong> ?</p> </div> <div class="paragraph"> <p>Les articles sont des nœuds. Les tags sont des communautés. Les xref sont des arêtes. Le lecteur ne lit plus un article isolé — il navigue dans un <strong>graphe de connaissance</strong> dont l’article courant est le point d’entrée.</p> </div> <div class="paragraph"> <p>Imaginez une page d’accueil qui affiche non pas la liste chronologique des derniers posts, mais une <strong>carte du corpus</strong> : clusters ontologiques, articles pivots (ceux avec le plus d’arêtes), chemins de lecture recommandés (« Si vous avez aimé l’article sur Graphify, lisez ensuite celui sur le Knowledge Graph comme outil de compréhension »).</p> </div> <div class="paragraph"> <p>Ce n’est plus un blog. C’est un <strong>atlas sémantique</strong>.</p> </div> <div class="paragraph"> <p>Et ce n’est pas de la science-fiction. Le <code>graph.json</code> existe déjà. Il ne lui manque que l’interface de navigation.</p> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_le_système_de_fichiers_sait_ce_que_le_template_ignore">8. Conclusion : Le Système de Fichiers Sait Ce Que le Template Ignore</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce que j’ai conçu ce mardi soir, c’est le remplacement d’une heuristique paresseuse (l’ordre chronologique) par une représentation fidèle de la structure de mon corpus (le Knowledge Graph).</p> </div> <div class="paragraph"> <p>Le template <code>post.thyme</code> ne change pas. Ce qui change, c’est ce qu’on lui donne à manger. Avant : une liste Java ordonnée par <code>date</code>. Après : un graphe pondéré issu de trois couches d’analyse — xrefs, co-occurrences de tags, et ontologie émergente par NLP.</p> </div> <div class="paragraph"> <p>La boucle est bouclée. graphify scanne le workspace. Bakery lit le graphe et nourrit le template. Le lecteur voit des recommandations pertinentes. Et engine — le chef d’orchestre — ne sait même pas que tout ça existe.</p> </div> <div class="paragraph"> <p>C’est ça, la bonne architecture. Chaque plugin fait une chose. Et le terminal consommateur n’a pas besoin de savoir comment.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="références">9. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="0105_integrer_graphify_workflow_gradle_post.html">Article 0105 — Intégrer Graphify dans un workflow Gradle</a></p> </li> <li> <p><a href="0106_knowledge_graph_outil_comprehension_codebase_post.html">Article 0106 — Le Knowledge Graph comme outil de compréhension</a></p> </li> <li> <p><a href="0117_granularisation_oss_css_repositorie_workspace_post.html">Article 0117 — La Granularisation OSS/CSS</a></p> </li> <li> <p><a href="0121_plugin_gradle_piloter_deux_instances_ollama_pro_post.html">Article 0121 — Plugin Gradle Piloter Deux Instances Ollama Pro</a></p> </li> <li> <p><a href="0122_ratio_efficacite_27x_45x_flotte_experts_ia_vs_claude_gpt_post.html">Article 0122 — 27× à 45× plus efficace : flotte d’experts IA</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0122_ratio_efficacite_27x_45x_flotte_experts_ia_vs_claude_gpt_post.html Mon, 11 May 2026 00:00:00 +0000 blog/2026/0122_ratio_efficacite_27x_45x_flotte_experts_ia_vs_claude_gpt_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_problème_pourquoi_le_fine_tune_et_pas_le_rag">1. Le problème : pourquoi le fine-tune et pas le RAG ?</a></li> <li><a href="#lidée_une_flotte_dexperts_pas_un_seul_modèle">2. L’idée : une flotte d’experts, pas un seul modèle</a></li> <li><a href="#la_codebase_sous_la_loupe_7_900_fichiers_144_000_lignes">3. La codebase sous la loupe : 7 900 fichiers, 144 000 lignes</a> <ul class="sectlevel2"> <li><a href="#détail_du_dataset_par_type_dexpert">3.1. Détail du dataset par type d’expert</a></li> </ul> </li> <li><a href="#le_choix_des_modèles_100_moe_zéro_dense">4. Le choix des modèles : 100% MoE, zéro dense</a> <ul class="sectlevel2"> <li><a href="#pourquoi_jabandonne_les_modèles_denses">4.1. Pourquoi j’abandonne les modèles denses</a></li> </ul> </li> <li><a href="#estimation_du_training_811_h100_heures">5. Estimation du training : 811 H100-heures</a> <ul class="sectlevel2"> <li><a href="#micro_experts_moe_légers_3_3_8b_activés">5.1. Micro-experts MoE légers (3-3.8B activés)</a></li> <li><a href="#exécutifs_v4_flash_13b_activés_292b_stockés">5.2. Exécutifs V4-Flash (13B activés / 292B stockés)</a></li> <li><a href="#tarifs_gpu_qui_loue_quoi_en_mai_2026">5.3. Tarifs GPU : qui loue quoi en mai 2026</a></li> <li><a href="#wall_clock_combien_de_temps_pour_tout_entraîner">5.4. Wall-clock : combien de temps pour tout entraîner ?</a></li> </ul> </li> <li><a href="#linférence_23_modèles_sur_ollama_cloud_à_partir_de_17mois">6. L’inférence : 23 modèles sur Ollama Cloud à partir de 17€/mois</a> <ul class="sectlevel2"> <li><a href="#on_démarre_à_17mois_on_scale_si_besoin">6.1. On démarre à 17€/mois, on scale si besoin</a></li> <li><a href="#le_routing_en_pratique">6.2. Le routing en pratique</a></li> </ul> </li> <li><a href="#la_comparaison_qui_fait_mal_claude_gpt_gemini_grok_vs_ma_flotte">7. La comparaison qui fait mal : Claude, GPT, Gemini, Grok vs ma flotte</a> <ul class="sectlevel2"> <li><a href="#anthropic_claude_tarifs_mai_2026">7.1. Anthropic — Claude (tarifs mai 2026)</a></li> <li><a href="#openai_gpt_tarifs_mai_2026">7.2. OpenAI — GPT (tarifs mai 2026)</a></li> <li><a href="#google_gemini_tarifs_mai_2026">7.3. Google — Gemini (tarifs mai 2026)</a></li> <li><a href="#grok_xai_tarifs_mai_2026">7.4. Grok — xAI (tarifs mai 2026)</a></li> <li><a href="#microsoft_azure_openai_tarifs_mai_2026">7.5. Microsoft — Azure OpenAI (tarifs mai 2026)</a></li> <li><a href="#le_tableau_comparatif_final">7.6. Le tableau comparatif final</a></li> </ul> </li> <li><a href="#le_facteur_defficacité_5_8_vs_utiliser_v4_pro_seul">8. Le facteur d’efficacité : 5-8× vs utiliser V4-Pro seul</a> <ul class="sectlevel2"> <li><a href="#scénario_a_v4_pro_seul_pour_tout">8.1. Scénario A : V4-Pro seul pour tout</a></li> <li><a href="#scénario_b_flotte_moe_orchestrée">8.2. Scénario B : Flotte MoE orchestrée</a></li> </ul> </li> <li><a href="#le_budget_complet_un_investissement_one_shot_un_forfait_ridicule">9. Le budget complet : un investissement one-shot, un forfait ridicule</a> <ul class="sectlevel2"> <li><a href="#le_calcul_de_rentabilité">9.1. Le calcul de rentabilité</a></li> </ul> </li> <li><a href="#les_limites_de_lexercice">10. Les limites de l’exercice</a></li> <li><a href="#conclusion_le_fine_tune_est_devenu_un_luxe_accessible">11. Conclusion : le fine-tune est devenu un luxe accessible</a></li> <li><a href="#modèles_fine_tunés_de_la_flotte">12. Modèles fine-tunés de la flotte</a></li> <li><a href="#ressources">13. Ressources</a> <ul class="sectlevel2"> <li><a href="#modèles_open_weight_sur_huggingface">13.1. Modèles open-weight sur HuggingFace</a></li> <li><a href="#sources_des_tarifs_mai_2026">13.2. Sources des tarifs (mai 2026)</a></li> <li><a href="#annonces_officielles">13.3. Annonces officielles</a></li> </ul> </li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 22 minutes</div> <p>Quand on utilise un LLM pour du développement logiciel au quotidien, on finit toujours par butter sur le même mur : le modèle ne connaît pas <strong>votre</strong> codebase. Il ne sait pas que vous utilisez tel pattern de <a href="https://fr.wikipedia.org/wiki/Graphe_orient%C3%A9_acyclique">DAG</a>, telle convention Gradle, telle stratification épistémique dans vos <a href="https://fr.wikipedia.org/wiki/AsciiDoc"><code>.adoc</code></a>. Alors on lui injecte du contexte, on répète, on corrige, on itère. Et le temps — et l’argent — passent.</p> </div> <div class="paragraph"> <p>J’ai donc posé la question brutalement : combien coûterait une équipe de modèles fine-tunés sur mon workspace, capables de cracher du code <strong>dans mon style</strong> sans avoir besoin qu’on leur explique à chaque fois ? Et surtout : comment cette approche se compare-t-elle aux solutions propriétaires classiques — Claude, GPT, Gemini, Grok ?</p> </div> <div class="paragraph"> <p>La réponse m’a surpris. Beaucoup moins que ce que j’imaginais. Et le rapport coût/efficacité face aux géants du secteur est indécent. Voici le détail complet.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_problème_pourquoi_le_fine_tune_et_pas_le_rag">1. Le problème : pourquoi le fine-tune et pas le RAG ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le RAG, c’est bien. <a href="0106_knowledge_graph_outil_comprehension_codebase_post.html">Mon knowledge graph</a> et <a href="0116_compartimentage_epistemique_automatise_llm_post.html">mon compartimentage épistémique</a> fonctionnent. Mais le RAG a un défaut fondamental : à chaque requête, tu dois réinjecter le contexte pertinent. Ton prompt s’allonge, ta latence explose, et le modèle n'<strong>intériorise</strong> jamais tes patterns — il les lit à chaque fois comme un document externe.</p> </div> <div class="paragraph"> <p>Le fine-tune, lui, c’est la mémoire musculaire. Le modèle <strong>sait</strong> que tu écris <code>build.gradle.kts</code> avec des tâches enregistrées via <code>tasks.register</code>, que tes <code>AGENTS.adoc</code> suivent une syntaxe standardisée, que ton workspace est structuré en boroughs. Il n’a pas besoin qu’on lui rappelle.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> Le fine-tune n’est pas un remplacement du RAG. C’est une couche complémentaire. Le RAG reste pertinent pour les données qui changent souvent (logs, tickets, commits récents). Le fine-tune est pour la connaissance <strong>structurelle</strong> et <strong>stylistique</strong> de long terme. </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="lidée_une_flotte_dexperts_pas_un_seul_modèle">2. L’idée : une flotte d’experts, pas un seul modèle</h2> <div class="sectionbody"> <div class="paragraph"> <p>Un seul modèle fine-tuné sur tout mon workspace, c’est déjà bien. Mais c’est sous-optimal. Mon workspace couvre des domaines très différents :</p> </div> <div class="ulist"> <ul> <li> <p>Gradle plugins (Kotlin, convention plugins, composite builds)</p> </li> <li> <p>Moteur DAG (Kotlin, planification, exécution)</p> </li> <li> <p>Agents LLM (Python, LangChain4j, RAG)</p> </li> <li> <p>Documentation architecturale (AsciiDoc, gouvernance)</p> </li> <li> <p>Infra/DevOps (Docker, GitHub Actions, CI/CD)</p> </li> </ul> </div> <div class="paragraph"> <p>Un modèle unique devrait être bon partout, excellent nulle part. La solution ? Une <strong>flotte de modèles spécialisés</strong>, avec un orkestrateur qui route chaque requête vers le bon expert.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/fleet-architecture.svg" alt="fleet architecture" width="871" height="462"> </div> </div> <div class="paragraph"> <p>La flotte totale : <strong>1 orkestrateur + 22 experts = 23 modèles</strong>. Et le coût d’inférence mensuel ? <strong>17€/mois</strong> en abonnement Ollama Pro annual — extensible par cumul de comptes si les quotas sont dépassés, comme démontré dans <a href="0120_cumuler_deux_abonnements_ollama_pro_docker_post.html">ma méthode Docker multi-comptes</a>. On part de 17€, on ajoute 20€ par palier selon le besoin réel. Pas de gaspillage.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_codebase_sous_la_loupe_7_900_fichiers_144_000_lignes">3. La codebase sous la loupe : 7 900 fichiers, 144 000 lignes</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant d’estimer le coût du training, il faut savoir quoi entraîner. J’ai audité mon workspace en excluant rigoureusement tout ce qui est ignoré par Git :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">build/ out/ node_modules/ runtimes/ .gradle/ dist/ target/ venv/ __pycache__/ .cache/ .tox/</code></pre> </div> </div> <div class="paragraph"> <p>Voici le résultat pour les fichiers trackés uniquement :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 50%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Métrique</th> <th class="tableblock halign-left valign-top">Valeur</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Fichiers source trackés</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>7 896</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Lignes de code (LOC)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>143 805</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Repositories Git</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>26</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Principaux langages</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Kotlin (1 903), AsciiDoc (2 765), Python (5 029)</p></td> </tr> </tbody> </table> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> Ces 5 000+ fichiers Python incluent les <code>runtimes/</code> des notebooks et scripts utilitaires. Le cœur applicatif (plugins Gradle, moteur DAG, agents) est principalement en Kotlin et AsciiDoc. </td> </tr> </table> </div> <div class="paragraph"> <p>À partir de cette masse, j’estime pouvoir générer un dataset synthétique de <strong>~170 millions de tokens</strong> via un LLM instructeur (distillation de la codebase en paires instruction/réponse).</p> </div> <div class="sect2"> <h3 id="détail_du_dataset_par_type_dexpert">3.1. Détail du dataset par type d’expert</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">Dataset maître (généraliste V4-Flash) : 50M tokens Expert Gradle/Build : 15M tokens Expert Kotlin/DAG : 15M tokens Expert AsciiDoc/Gouvernance: 15M tokens Expert Agent/LLM/Python : 15M tokens Expert Infra/CI-CD : 15M tokens Micro-experts Qwen/Gemma : ~5M tokens chacun</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_choix_des_modèles_100_moe_zéro_dense">4. Le choix des modèles : 100% MoE, zéro dense</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’est là que l’architecture devient vraiment efficiente.</p> </div> <div class="paragraph"> <p>Un modèle <strong>dense</strong> active tous ses poids à chaque token. Un modèle <strong>MoE</strong> (Mixture of Experts) n’active qu’une fraction de ses paramètres. Le coût d’inférence — et de fine-tuning — est proportionnel aux paramètres <strong>activés</strong>, pas aux paramètres <strong>stockés</strong>.</p> </div> <div class="paragraph"> <p>Regardons ce que le marché propose en MoE aujourd’hui sur Ollama Cloud :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 27.2727%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 9.0909%;"> <col style="width: 27.2728%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Total params</th> <th class="tableblock halign-left valign-top">Activés</th> <th class="tableblock halign-left valign-top">Activation</th> <th class="tableblock halign-left valign-top">Ollama Cloud</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">DeepSeek V4-Pro</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1.6T</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">49B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3.1%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ natif</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">DeepSeek V4-Flash</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">292B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">13B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4.5%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ natif</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemma 4 26B-A4B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">26B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3.8B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">14.6%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ natif</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Qwen3.6-35B-A3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">35B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8.6%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ (pas encore intégré)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Qwen3.5-35B-A3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">35B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8.6%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ natif</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Qwen3.5-27B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">27B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">27B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">100% dense</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">éliminé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Qwen3.5-4B/9B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4B/9B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4B/9B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">100% dense</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">éliminé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Gemma 4 31B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">31B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">31B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">100% dense</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">éliminé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">🧪 Gemma 4 E2B/E4B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5B/8B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5B/8B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">100% dense</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">validation pipeline</p></td> </tr> </tbody> </table> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> Le ratio d’activation est le critère discriminant. Un Gemma 4 26B-A4B n’active que 3.8B de ses 26B de paramètres — c’est 7× moins qu’un dense 27B, pour des performances de coding agent comparables (77.1% vs 80% sur LiveCodeBench v6). </td> </tr> </table> </div> <div class="sect2"> <h3 id="pourquoi_jabandonne_les_modèles_denses">4.1. Pourquoi j’abandonne les modèles denses</h3> <div class="paragraph"> <p>L’exception : les Gemma 4 E2B et E4B. Ces deux modèles, sous Apache 2.0, sont parfaits pour tester et valider un pipeline de training à moindre coût. Un run de 2-3h sur un E2B coûte moins de $5 — si le dataset ou les hyperparamètres sont foireux, on le sait pour une poignée de dollars. Une fois le pipeline rodé, ils peuvent même servir pour les ultra-micro-tâches (reformatage trivial, classification binaire). Mais pour les experts de la flotte principale, je reste sur du MoE. Voici pourquoi :</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> <div class="title">Mais pas que : les Gemma 4 E2B/E4B, experts de l’anonymisation fine</div> Google a conçu ces petits modèles comme compétitifs en tool calling natif — ils savent appeler des fonctions, manipuler des regex, chercher des motifs. Une fois fine-tunés sur des exemples d’anonymisation (emails, tokens, UUIDs, chemins de fichiers), ils deviennent des <strong>anonymiseurs de dataset</strong> ultra-rapides. On leur file un bloc de texte brut, ils appellent <code>sed</code>/<code>regex</code> via un tool call et retournent le bloc nettoyé. Le coût d’inférence est dérisoire : 5B activés, ça tient sur une seule GPU d’entrée de gamme. Ces modèles ne sont pas des experts métier — ce sont des <strong>ouvriers spécialisés</strong> dans la chaîne de production du dataset. </td> </tr> </table> </div> <div class="ulist"> <ul> <li> <p>Sa VRAM d’entraînement (même en QLoRA) est proportionnelle aux <strong>27B totaux</strong></p> </li> <li> <p>Son temps de training est proportionnel aux <strong>27B activés</strong></p> </li> </ul> </div> <div class="paragraph"> <p>Comparons avec un Qwen3.6-35B-A3B (MoE) :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 33.3333%;"> <col style="width: 22.2222%;"> <col style="width: 22.2222%;"> <col style="width: 22.2223%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"></th> <th class="tableblock halign-left valign-top">Qwen3.5-27B (dense)</th> <th class="tableblock halign-left valign-top">Qwen3.6-35B-A3B (MoE)</th> <th class="tableblock halign-left valign-top">Ratio</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">VRAM QLoRA</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~55 GB</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~35 GB</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1.6×</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPU-heures (8M tok)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~12h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~4h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>3×</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coût par fine-tune</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~$24</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~$8</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>3×</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">SWE-bench Verified</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">75.0%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">73.4%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">comparable</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le MoE coûte 3× moins à entraîner pour des performances agent-coding à 5% près. Sur 22 experts, l’écart se chiffre en milliers d’euros.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="estimation_du_training_811_h100_heures">5. Estimation du training : 811 H100-heures</h2> <div class="sectionbody"> <div class="paragraph"> <p>J’ai ventilé le coût de training modèle par modèle, en QLoRA 4-bit, avec les datasets décrits plus haut.</p> </div> <div class="sect2"> <h3 id="micro_experts_moe_légers_3_3_8b_activés">5.1. Micro-experts MoE légers (3-3.8B activés)</h3> <div class="paragraph"> <p>Ces modèles nécessitent 1 H100 (80 GB) par run. La VRAM du modèle en Q4 est d’environ 13-18 GB, laissant large pour les états d’optimiseur LoRA et les activations.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 36.3636%;"> <col style="width: 18.1818%;"> <col style="width: 27.2727%;"> <col style="width: 18.1819%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Nb de runs</th> <th class="tableblock halign-left valign-top">GPU-h/run</th> <th class="tableblock halign-left valign-top">Total GPU-h</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemma 4 26B-A4B-FT</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">6</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3.5 h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>21 h</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Qwen3.6-35B-A3B-FT</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4.0 h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>20 h</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Qwen3.5-35B-A3B-FT</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4.0 h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>20 h</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Sous-total micro</strong></p></td> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>61 h</strong></p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="exécutifs_v4_flash_13b_activés_292b_stockés">5.2. Exécutifs V4-Flash (13B activés / 292B stockés)</h3> <div class="paragraph"> <p>Le DeepSeek V4-Flash est un cas particulier. Même si seuls 13B sont activés par token, le modèle complet en Q4 pèse ~142 GB — tous les experts doivent être en VRAM pendant le training. Il faut donc <strong>3× H100</strong> par run pour être confortable.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 28.5714%;"> <col style="width: 14.2857%;"> <col style="width: 21.4285%;"> <col style="width: 21.4285%;"> <col style="width: 14.2859%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Dataset</th> <th class="tableblock halign-left valign-top">GPUs</th> <th class="tableblock halign-left valign-top">Heures</th> <th class="tableblock halign-left valign-top">Total GPU-h</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">V4-Flash-Base généraliste</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">50M tok</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3× H100</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">50 h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>150 h</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">V4-Flash expert ×5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">15M tok</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3× H100</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">40 h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>600 h</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Sous-total exécutifs</strong></p></td> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>750 h</strong></p></td> </tr> </tbody> </table> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 33.3333%;"> <col style="width: 16.6667%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>TOTAL</strong></p></td> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>811 H100-h</strong></p></td> </tr> </tbody> </table> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> À titre de comparaison, un full fine-tune du V4-Flash (sans QLoRA, tous les poids) coûterait ~4 000 H100-h rien que pour les 6 modèles. Le QLoRA divise le coût par 5. C’est le seul moyen de rendre le projet économiquement viable à cette échelle. </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="tarifs_gpu_qui_loue_quoi_en_mai_2026">5.3. Tarifs GPU : qui loue quoi en mai 2026</h3> <div class="paragraph"> <p>J’ai benchmarké les principaux loueurs de H100. Le prix au compteur, pour 811 heures.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 33.3333%;"> <col style="width: 22.2222%;"> <col style="width: 22.2222%;"> <col style="width: 22.2223%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Loueur</th> <th class="tableblock halign-left valign-top">$/H100·h</th> <th class="tableblock halign-left valign-top">Total 811h</th> <th class="tableblock halign-left valign-top">Fiabilité</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Vast.ai spot</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1.60</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$1 298</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★☆ interruptible</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Crusoe Cloud</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2.00</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$1 622</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★★★ datacenter fiable</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">FluidStack</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1.98</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 606</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★★</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">TensorDock</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1.80</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 460</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★☆</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">RunPod</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2.29</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 857</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★★ bon compromis</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">CoreWeave</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2.25</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 825</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★★★ entreprise</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Lambda Labs</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2.49</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2 019</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">★★★★ premium</p></td> </tr> </tbody> </table> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> Vast.ai spot est le moins cher mais tes runs peuvent être interrompus à tout moment. Pour du training, c’est risqué. Crusoe à $2.00/h est le meilleur rapport fiabilité/prix. Le surcoût de $324 vs Vast vaut la tranquillité d’esprit. </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="wall_clock_combien_de_temps_pour_tout_entraîner">5.4. Wall-clock : combien de temps pour tout entraîner ?</h3> <div class="paragraph"> <p>Avec un seul nœud 3× H100, les 31 runs (1 généraliste + 30 experts) prennent environ <strong>12 jours</strong> en séquentiel. Si tu loues 2 nœuds en parallèle, ça tombe à <strong>6 jours</strong>.</p> </div> <div class="paragraph"> <p>En pratique, les micro-experts peuvent tourner sur des nœuds séparés (1 H100 chacun) pendant que les V4-Flash occupent le nœud 3× H100. Avec une planification intelligente :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Nœud A (3× H100) : V4-Flash généraliste → V4-Flash experts ×5 (11 jours) Nœud B (1× H100) : Gemma 4 26B ×6 → Qwen 36 ×5 → Qwen 35 ×5 (6 jours)</code></pre> </div> </div> <div class="paragraph"> <p>7 jours de location, tout plié.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="linférence_23_modèles_sur_ollama_cloud_à_partir_de_17mois">6. L’inférence : 23 modèles sur Ollama Cloud à partir de 17€/mois</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’est la partie la plus élégante de l’architecture.</p> </div> <div class="paragraph"> <p>Ollama Cloud permet d’uploader des modèles privés (fonctionnalité du plan Pro). Mes 22 modèles fine-tunés sont poussés en <code>.gguf</code> sur mon espace Ollama, marqués comme privés, et accessibles via l’API standard.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/inference-flow.svg" alt="inference flow" width="918" height="524"> </div> </div> <div class="sect2"> <h3 id="on_démarre_à_17mois_on_scale_si_besoin">6.1. On démarre à 17€/mois, on scale si besoin</h3> <div class="paragraph"> <p>Le plan Pro Ollama (17€/mois en annuel) autorise 3 modèles cloud concurrents. Dans cette architecture, je n’ai jamais besoin de plus de 2-3 experts simultanément :</p> </div> <div class="ulist"> <ul> <li> <p>La phase de classification (V4-Pro) occupe 1 slot, quelques secondes</p> </li> <li> <p>L’expert ciblé occupe 1 slot, le temps de générer sa réponse</p> </li> <li> <p>Le 3ème slot reste en réserve pour les tâches parallèles</p> </li> </ul> </div> <div class="paragraph"> <p>Si l’usage augmente, j’ajoute des comptes Pro supplémentaires via la méthode Docker décrite dans <a href="0120_cumuler_deux_abonnements_ollama_pro_docker_post.html">mon article sur le cumul d’abonnements</a>. Pas de plan Max à 100€/mois — je n’ajoute que ce dont j’ai réellement besoin.</p> </div> <div class="paragraph"> <p>Le seul facteur limitant est le <strong>quota GPU-time</strong> mensuel d’Ollama (50× le plan gratuit pour Pro). Pour mon usage de quelques centaines de requêtes par jour, c’est amplement suffisant.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> Le coût marginal d’un appel à V4-Pro (49B activés) vs Gemma 4 26B-A4B (3.8B activés) est le <strong>même pour moi : zéro</strong>. C’est le forfait Ollama qui absorbe la différence de compute. Mon seul indicateur est la latence. </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="le_routing_en_pratique">6.2. Le routing en pratique</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Volume de requêtes estimé : ~500/jour ├─ 50% → Gemma 4 26B-A4B-FT (micro, 3.8B actifs) │ Formatage AsciiDoc, scripts simples, conventions nommage │ ├─ 25% → V4-Flash-FT (exécutif, 13B actifs) │ Plugins Gradle, refactoring Kotlin, génération DAG │ ├─ 15% → Qwen 35B MoE-FT (micro, 3B actifs) │ Tâches intermédiaires, review de code, documentation │ └─ 10% → V4-Pro (orkestrateur, 49B actifs) Décisions architecturales, refactoring transverse, problèmes vraiment nouveaux</code></pre> </div> </div> <div class="paragraph"> <p>La masse du trafic passe par les petits. Le gros modèle n’intervient qu’en dernier recours.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_comparaison_qui_fait_mal_claude_gpt_gemini_grok_vs_ma_flotte">7. La comparaison qui fait mal : Claude, GPT, Gemini, Grok vs ma flotte</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’est ici que l’écart devient vertigineux. Regardons ce que coûterait le même volume de travail (500 requêtes/jour, ~300 tokens input + 2 000 tokens output en moyenne) avec les solutions propriétaires du marché en mai 2026.</p> </div> <div class="sect2"> <h3 id="anthropic_claude_tarifs_mai_2026">7.1. Anthropic — Claude (tarifs mai 2026)</h3> <div class="paragraph"> <p>Anthropic a récemment <strong>baissé</strong> ses prix. La pression des solutions open-weight comme DeepSeek et Qwen se fait sentir.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 27.2727%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1819%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Input $/MTok</th> <th class="tableblock halign-left valign-top">Output $/MTok</th> <th class="tableblock halign-left valign-top">Coût/jour</th> <th class="tableblock halign-left valign-top"><strong>Coût/mois</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Opus 4.7 (le + intelligent)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$25</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$25.75</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$772</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Sonnet 4.6 (équilibré)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$15</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$15.45</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$463</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Haiku 4.5 (le + rapide)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$5.15</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$154</strong></p></td> </tr> </tbody> </table> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> Ces tarifs sont <strong>après</strong> la dernière baisse de prix d’Anthropic (mai 2026). Avant cela, Opus était à $15/$75 par MTok. La peur de l’open-weight est réelle. </td> </tr> </table> </div> <div class="paragraph"> <p>Même le modèle le moins cher de Claude — Haiku 4.5 à <strong>154€/mois</strong> — coûte 9× plus que mon abonnement Ollama Pro à 17€. Et Haiku ne connaît pas ma codebase, ne génère pas dans mon style, et nécessite du prompt engineering systématique.</p> </div> <div class="paragraph"> <p>Le plus intelligent — Opus 4.7 — explose le budget à <strong>772€/mois</strong> pour un volume modeste de 500 requêtes par jour. Soit <strong>45× plus cher</strong> que ma solution.</p> </div> </div> <div class="sect2"> <h3 id="openai_gpt_tarifs_mai_2026">7.2. OpenAI — GPT (tarifs mai 2026)</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 27.2727%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1819%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Input $/MTok</th> <th class="tableblock halign-left valign-top">Output $/MTok</th> <th class="tableblock halign-left valign-top">Coût/jour</th> <th class="tableblock halign-left valign-top"><strong>Coût/mois</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.5 (le + intelligent)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$30</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$30.90</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$927</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.4 (standard)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2.50</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$15</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$15.45</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$463</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.4 Mini</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$0.75</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$4.50</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$4.64</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$139</strong></p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Même le modèle « économique » d’OpenAI — GPT 5.4 Mini à 139€/mois — coûte 8× mon abonnement, pour un modèle qui ne sait <strong>rien</strong> de mes conventions et nécessite du prompt engineering lourd.</p> </div> <div class="paragraph"> <p>GPT 5.5, leur flagship : <strong>927€/mois</strong>. Pour du <strong>zero-shot</strong> sur ma codebase. Avec 2-3 itérations par tâche à cause du style non maîtrisé, le vrai coût mensuel double facilement.</p> </div> </div> <div class="sect2"> <h3 id="google_gemini_tarifs_mai_2026">7.3. Google — Gemini (tarifs mai 2026)</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 27.2727%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1819%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Input $/MTok</th> <th class="tableblock halign-left valign-top">Output $/MTok</th> <th class="tableblock halign-left valign-top">Coût/jour</th> <th class="tableblock halign-left valign-top"><strong>Coût/mois</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemini 3.1 Pro (High)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$3.50</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$17.50</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$18.00</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$540</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemini 3.1 Pro</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$10</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$10.30</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$309</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemini 3 Flash</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$0.30</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1.50</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1.54</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$46</strong></p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Gemini 3 Flash à 46€/mois est compétitif en prix pur — mais sans fine-tune, il génère du code « générique ». Pas du code <strong>Cheroliv</strong>.</p> </div> </div> <div class="sect2"> <h3 id="grok_xai_tarifs_mai_2026">7.4. Grok — xAI (tarifs mai 2026)</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 27.2727%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1819%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Input $/MTok</th> <th class="tableblock halign-left valign-top">Output $/MTok</th> <th class="tableblock halign-left valign-top">Coût/jour</th> <th class="tableblock halign-left valign-top"><strong>Coût/mois</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Grok 4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$16</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$16.48</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$494</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Grok 4 Mini</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$0.80</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$3.20</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$3.30</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$99</strong></p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="microsoft_azure_openai_tarifs_mai_2026">7.5. Microsoft — Azure OpenAI (tarifs mai 2026)</h3> <div class="paragraph"> <p>Azure applique les mêmes prix que l’API OpenAI directe, mais facture en plus l’infrastructure et le réseau. Il faut compter un surcoût de 10-20% pour le service managé.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 27.2727%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1819%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Modèle</th> <th class="tableblock halign-left valign-top">Input $/MTok</th> <th class="tableblock halign-left valign-top">Output $/MTok</th> <th class="tableblock halign-left valign-top">Coût/jour</th> <th class="tableblock halign-left valign-top"><strong>Coût/mois</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.4 (Azure, Global)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$2.50</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$15</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$15.45</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$463</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.4 + infrastructure</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">surcoût 15%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">surcoût 15%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$17.77</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$533</strong></p></td> </tr> </tbody> </table> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> Les tarifs ci-dessus concernent l’API, pas les abonnements « chat » (Claude Pro à $20/mois, ChatGPT Plus à $20/mois). On compare ici l’usage <strong>développeur</strong>, celui où tu enchaînes des centaines de requêtes par jour via API pour générer, refactorer, documenter. Les abonnements grand public ont des quotas qui explosent bien avant 500 requêtes/jour. </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="le_tableau_comparatif_final">7.6. Le tableau comparatif final</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 23.0769%;"> <col style="width: 15.3846%;"> <col style="width: 15.3846%;"> <col style="width: 15.3846%;"> <col style="width: 15.3846%;"> <col style="width: 15.3847%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Solution</th> <th class="tableblock halign-left valign-top">Connaissance codebase</th> <th class="tableblock halign-left valign-top">Style intégré</th> <th class="tableblock halign-left valign-top">Coût/mois</th> <th class="tableblock halign-left valign-top">Itérations</th> <th class="tableblock halign-left valign-top"><strong>Coût effectif</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Ma flotte (Ollama Pro)</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Fine-tunée</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Dans les poids</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>17€</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">0-1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>17€</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Claude Opus 4.7</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$772</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 500-2 300</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Claude Haiku 4.5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$154</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3-4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$460-615</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$927</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 854-2 781</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$463</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$925-1 390</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">GPT 5.4 Mini</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$139</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3-5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$417-695</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemini 3.1 Pro High</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$540</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 080-1 620</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Grok 4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$494</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$988-1 482</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Azure GPT 5.4</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Zero-shot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Prompt nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$533</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1 066-1 600</p></td> </tr> </tbody> </table> <div class="imageblock"> <div class="content"> <img src="./images/cost-comparison.svg" alt="cost comparison" width="533" height="287"> </div> </div> <div class="quoteblock"> <blockquote> 17€/mois pour 23 experts IA fine-tunés. Le flagship Claude Opus 4.7 coûte <strong>45× plus cher</strong> pour une qualité inférieure sur <strong>mon</strong> codebase. GPT 5.5 coûte <strong>54× plus cher</strong>. Même le modèle le moins cher du marché (Gemini Flash à 46€) coûte <strong>2.7× plus</strong> sans la connaissance de mon workspace. </blockquote> <div class="attribution"> — Analyse de rentabilité </div> </div> <div class="paragraph"> <p>Le verdict est sans appel : le fine-tune sur architectures MoE, en 2026, n’est pas juste « moins cher ». C’est un facteur d’efficacité de <strong>27× à 54×</strong> sur le rapport coût/qualité face aux solutions propriétaires. Anthropic, OpenAI, Google — tous le savent, et c’est pour ça qu’ils baissent leurs prix en panique.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_facteur_defficacité_5_8_vs_utiliser_v4_pro_seul">8. Le facteur d’efficacité : 5-8× vs utiliser V4-Pro seul</h2> <div class="sectionbody"> <div class="paragraph"> <p>Comparons les deux extrêmes.</p> </div> <div class="sect2"> <h3 id="scénario_a_v4_pro_seul_pour_tout">8.1. Scénario A : V4-Pro seul pour tout</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 60%;"> <col style="width: 40%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Métrique</th> <th class="tableblock halign-left valign-top">Valeur</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Connaissance de la codebase</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">0 (zero-shot)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Convention naming</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">40-60% first-shot correct</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Prompt engineering nécessaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Oui, systématique</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Itérations par tâche</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coût inférence</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$100/mois (Ollama Max)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Latence moyenne</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~20 tok/s + réseau</p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="scénario_b_flotte_moe_orchestrée">8.2. Scénario B : Flotte MoE orchestrée</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 60%;"> <col style="width: 40%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Métrique</th> <th class="tableblock halign-left valign-top">Valeur</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Connaissance de la codebase</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Intégrée (fine-tune)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Convention naming</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">90-95% first-shot correct</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Prompt engineering</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non (le style est dans les poids)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Itérations par tâche</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">0-1</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coût inférence</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$60/mois (3× Ollama Pro)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Latence moyenne</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~50 tok/s (modèles légers)</p></td> </tr> </tbody> </table> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 40%;"> <col style="width: 20%;"> <col style="width: 20%;"> <col style="width: 20%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Dimension</th> <th class="tableblock halign-left valign-top">V4-Pro seul</th> <th class="tableblock halign-left valign-top">Flotte MoE</th> <th class="tableblock halign-left valign-top">Facteur</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coût mensuel cloud</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$100</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$60</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1.7×</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Contexte à injecter</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Élevé (prompt)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Zéro</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">∞</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Itérations moyennes</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>0-1</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2-3×</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Latence ressentie</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">20 tok/s</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">50 tok/s</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>2.5×</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">First-shot correct</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">50%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">90%+</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>1.8×</strong></p></td> </tr> </tbody> </table> <div class="paragraph"> <p><strong>Facteur d’efficacité global : 5-8×</strong> — en productivité développeur ressentie.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> Le facteur ne se mesure pas en tokens ou en dollars. Il se mesure en « combien de temps je passe à expliquer au modèle ce qu’il devrait déjà savoir ». Avec les modèles fine-tunés, ce temps tend vers zéro. </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_budget_complet_un_investissement_one_shot_un_forfait_ridicule">9. Le budget complet : un investissement one-shot, un forfait ridicule</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 60%;"> <col style="width: 40%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Poste</th> <th class="tableblock halign-left valign-top">Montant</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Training GPU (811 H100-h, Crusoe $2/h)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$1 622</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Génération dataset synthétique (API LLM)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$400</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Inference (Ollama Pro annuel, $17/mois)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$204</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Total première année</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$2 226</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Mensuel équivalent</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>$186</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Coût par requête estimé</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">< $0.01</p></td> </tr> </tbody> </table> <div class="imageblock"> <div class="content"> <img src="./images/budget-breakdown.svg" alt="budget breakdown" width="538" height="214"> </div> </div> <div class="paragraph"> <p>$186/mois la première année, <strong>$17/mois</strong> dès l’an 2. Le prix d’un abonnement Netflix premium, pour une équipe de 23 experts IA disponibles 24/7, qui écrivent du code <strong>dans mon style</strong> sans que j’aie besoin de leur expliquer mes conventions.</p> </div> <div class="sect2"> <h3 id="le_calcul_de_rentabilité">9.1. Le calcul de rentabilité</h3> <div class="paragraph"> <p>Avec edster.cloud et sa marge de ~95%, le point mort est à <strong>~$2 340 de CA supplémentaire</strong> sur l’année. En pratique :</p> </div> <div class="ulist"> <ul> <li> <p>1 mission de pilotage software → $3 000-5 000 → investissement couvert + profit</p> </li> <li> <p>1 formation corporate → $5 000-10 000 → confortable</p> </li> <li> <p>L’upsell implicite : "mon équipe d’IA maîtrise ma forge logicielle" → différenciant commercial</p> </li> </ul> </div> <div class="paragraph"> <p>À partir de l’an 2, le training n’est plus à payer (sauf mise à jour du dataset). Le coût annuel tombe à <strong>$204</strong> ($17/mois). Le ratio coût/valeur est celui d’une licorne : quasi nul.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="les_limites_de_lexercice">10. Les limites de l’exercice</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ceci reste une <strong>estimation au doigt mouillé</strong>. Plusieurs variables peuvent faire varier le budget :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 40%;"> <col style="width: 60%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Variable</th> <th class="tableblock halign-left valign-top">Impact</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Génération du dataset synthétique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Si l’API de distillation merde (hallucinations, paires mal formées), il faut du temps humain pour curater. Coût caché.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Quotas GPU-time Ollama</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Si l’usage dépasse les quotas du plan Pro, il faudra monter en gamme ou basculer sur du GPU dédié.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Qualité effective des fine-tunes</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un fine-tune raté → à refaire. Le vrai risque c’est les hyperparamètres, pas la location GPU.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Évolution rapide des modèles</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les Qwen3.6/Gemma 4 sont sortis il y a < 1 mois. Dans 6 mois, la génération suivante sera meilleure ET moins chère à fine-tuner.</p></td> </tr> </tbody> </table> <div class="admonitionblock warning"> <table> <tr> <td class="icon"> <i class="fa icon-warning" title="⚠️"></i> </td> <td class="content"> Ne lancez pas 811 heures de training sans avoir d’abord testé le pipeline sur <strong>un seul</strong> micro-modèle. Un run de 3-4h sur un Qwen 35B-A3B coûte $8. Si le dataset est pourri, vous le saurez pour $8, pas pour $1 622. </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_le_fine_tune_est_devenu_un_luxe_accessible">11. Conclusion : le fine-tune est devenu un luxe accessible</h2> <div class="sectionbody"> <div class="paragraph"> <p>Il y a un an, fine-tuner un modèle de 292B paramètres (même en QLoRA) relevait de la recherche. Aujourd’hui, en mai 2026, c’est un projet faisable pour un développeur indépendant :</p> </div> <div class="ulist"> <ul> <li> <p><strong>811 H100-heures</strong> de training — $1 622 chez Crusoe</p> </li> <li> <p><strong>23 modèles spécialisés</strong> chargés sur Ollama Cloud — <strong>$17/mois</strong></p> </li> <li> <p><strong>0 serveur, 0 GPU local, 0 maintenance infra</strong></p> </li> </ul> </div> <div class="paragraph"> <p>La démocratisation est venue de trois facteurs convergents :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Les architectures MoE</strong> — qui permettent de fine-tuner efficacement des modèles dont seule une fraction des poids est activée</p> </li> <li> <p><strong>Les plans fixes d’Ollama Cloud</strong> — qui transforment un coût variable (per-token) en coût fixe (abonnement)</p> </li> <li> <p><strong>Les modèles open-weight de qualité</strong> — DeepSeek V4, Qwen3.6, Gemma 4 sont sous licences MIT/Apache 2.0</p> </li> </ol> </div> <div class="quoteblock"> <blockquote> "Civilisation advances by extending the number of important operations which we can perform without thinking about them." </blockquote> <div class="attribution"> — The Pragmatic Programmer </div> </div> <div class="paragraph"> <p>Le fine-tune, c’est exactement ça : une opération que tu délègues à la machine pour ne plus avoir à y penser. Et en 2026, ça coûte moins cher qu’un développeur junior mensualisé.</p> </div> <hr> <div class="paragraph"> <p><em>Article publié le 2026-05-11</em></p> </div> </div> </div> <div class="sect1"> <h2 id="modèles_fine_tunés_de_la_flotte">12. Modèles fine-tunés de la flotte</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 18.1818%;"> <col style="width: 27.2728%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Taille activée</th> <th class="tableblock halign-left valign-top">Nombre</th> <th class="tableblock halign-left valign-top">Modèle de base</th> <th class="tableblock halign-left valign-top">Domaine</th> <th class="tableblock halign-left valign-top">Dataset</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">13B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">DeepSeek-V4-Flash-Base</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Workspace général</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">50M tokens</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">13B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">DeepSeek-V4-Flash</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Gradle, Kotlin, DAG, Doc, Infra</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">15M tokens</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3.8B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">6</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Gemma 4 26B-A4B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Micro-tâches, formatage, scripts</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5M tokens</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Qwen3.6-35B-A3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Refactoring, review, doc intermédiaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5M tokens</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Qwen3.5-35B-A3B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tâches legacy, compatibilité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5M tokens</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="ressources">13. Ressources</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="modèles_open_weight_sur_huggingface">13.1. Modèles open-weight sur HuggingFace</h3> <div class="ulist"> <ul> <li> <p><a href="https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-Base">DeepSeek V4-Flash-Base — 292B params, license MIT</a></p> </li> <li> <p><a href="https://huggingface.co/Qwen/Qwen3.6-35B-A3B">Qwen3.6-35B-A3B — 35B/3B activés, license Apache 2.0</a></p> </li> <li> <p><a href="https://huggingface.co/Qwen/Qwen3.5-35B-A3B">Qwen3.5-35B-A3B — 35B/3B activés, license Apache 2.0</a></p> </li> <li> <p><a href="https://huggingface.co/google/gemma-4-26B-A4B-it">Gemma 4 26B-A4B — 26B/3.8B activés, license Apache 2.0</a></p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="sources_des_tarifs_mai_2026">13.2. Sources des tarifs (mai 2026)</h3> <div class="ulist"> <ul> <li> <p><a href="https://ollama.com/pricing">Tarifs Ollama Cloud — plan Pro $17/mois annuel</a></p> </li> <li> <p><a href="https://www.anthropic.com/pricing">Tarifs Anthropic — Claude API (Opus 4.7 $5/$25, Sonnet 4.6 $3/$15, Haiku 4.5 $1/$5)</a></p> </li> <li> <p><a href="https://openai.com/api/pricing/">Tarifs OpenAI — GPT API (GPT 5.5 $5/$30, GPT 5.4 $2.50/$15)</a></p> </li> <li> <p><a href="https://deepinfra.com/pricing">Tarifs DeepInfra — GPU instances H100 $1.79/h, B200 $2.79/h</a></p> </li> <li> <p>Vast.ai, Crusoe Cloud, FluidStack, TensorDock, RunPod, CoreWeave, Lambda Labs — relevés de prix manuels, datés de mai 2026</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="annonces_officielles">13.3. Annonces officielles</h3> <div class="ulist"> <ul> <li> <p><a href="https://qwen.ai/blog?id=qwen3.6-35b-a3b">Annonce officielle Qwen3.6-35B-A3B — blog Qwen</a> — agentic coding, Apache 2.0, 262K context</p> </li> </ul> </div> </div> </div> </div> https://pages-content.github.io//blog/2026/0121_plugin_gradle_piloter_deux_instances_ollama_pro_post.html Fri, 8 May 2026 00:00:00 +0000 blog/2026/0121_plugin_gradle_piloter_deux_instances_ollama_pro_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#introduction">1. Introduction</a></li> <li><a href="#pourquoi_gradle_pour_de_linfra">2. Pourquoi Gradle Pour de l’Infra ?</a></li> <li><a href="#le_build_gradle_kts_complet">3. Le build.gradle.kts Complet</a></li> <li><a href="#anatomie_des_tâches_clés">4. Anatomie des Tâches Clés</a> <ul class="sectlevel2"> <li><a href="#startollamab_le_lanceur">4.1. <code>startOllamaB</code> — Le Lanceur</a></li> <li><a href="#signinb_linteractif">4.2. <code>signInB</code> — L’Interactif</a></li> <li><a href="#pullmodelb_le_paramétrable">4.3. <code>pullModelB</code> — Le Paramétrable</a></li> <li><a href="#statusollamaall_le_diagnostic">4.4. <code>statusOllamaAll</code> — Le Diagnostic</a></li> <li><a href="#cleanollamab_le_nettoyage_qui_préserve_lidentité">4.5. <code>cleanOllamaB</code> — Le Nettoyage qui Préserve l’Identité</a></li> </ul> </li> <li><a href="#workflow_complet_de_zéro_à_deux_sessions">5. Workflow Complet — De Zéro à Deux Sessions</a></li> <li><a href="#pourquoi_ne_pas_en_faire_un_vrai_plugin_gradle">6. Pourquoi Ne Pas en Faire un Vrai Plugin Gradle ?</a></li> <li><a href="#leçons_apprises">7. Leçons Apprises</a></li> <li><a href="#conclusion">8. Conclusion</a></li> <li><a href="#ressources">9. Ressources</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 18 minutes</div> <p>Pourquoi taper des commandes docker à la main quand on peut tout encapsuler dans des tâches Gradle ? Voici comment j’ai industrialisé ma config dual-Ollama Pro avec zéro script shell externe. Démarrage, arrêt, identité, sign-in, pull — tout passe par <code>./gradlew</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans l’article précédent, j’ai montré comment faire cohabiter deux comptes Ollama Pro sur la même machine en isolant la deuxième instance dans un conteneur Docker. Le montage fonctionne, mais la gestion au quotidien est vite pénible : se souvenir du nom du conteneur, relancer les bonnes commandes <code>docker exec</code>, checker quel port est actif…​</p> </div> <div class="paragraph"> <p>Vous connaissez ce moment où vous avez 14 terminaux ouverts, que vous tapez <code>docker exec ollama-instance-b ollama list</code> pour la quatrième fois, et que vous vous dites « il doit bien y avoir un moyen plus propre » ?</p> </div> <div class="paragraph"> <p>Ce moyen, c’est Gradle.</p> </div> <div class="paragraph"> <p>Pas juste pour builder du code. Gradle comme un chef d’orchestre d’infrastructure locale. Des tâches qui provisionnent, vérifient, testent, et nettoient. Le tout versionné dans un <code>build.gradle.kts</code> qui vit à côté du <code>docker-compose.yml</code>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/architecture-gradle-ollama.svg" alt="architecture gradle ollama" width="717" height="511"> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_gradle_pour_de_linfra">2. Pourquoi Gradle Pour de l’Infra ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>La question est légitime. Gradle, c’est un build tool. Normalement, il compile, il teste, il package. Pas il lance des conteneurs Docker.</p> </div> <div class="paragraph"> <p>Sauf que Gradle est aussi un moteur de graphe de dépendances — et c’est là que ça devient intéressant pour notre cas.</p> </div> <div class="paragraph"> <p>On veut : . Que le conteneur soit lancé avant un sign-in . Que l’identité soit vérifiée avant un pull de modèle . Qu’un test API échoue silencieusement si le conteneur est down</p> </div> <div class="paragraph"> <p>Du graphe de dépendances pur. Gradle est taillé pour ça. Le DSL Kotlin rend l’écriture des tâches fluide, et le <code>doLast</code> permet d’exécuter des commandes système comme si c’était du code applicatif.</p> </div> <div class="paragraph"> <p>Et surtout : pas de bashrc à maintenir, pas de scripts qui traînent dans <code>~/bin</code>, pas de Makefile à côté du docker-compose. Tout vit dans un seul fichier, au même endroit que le code du projet.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_build_gradle_kts_complet">3. Le build.gradle.kts Complet</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici le fichier que j’ai fini par écrire. Il fait tout, du provisionnement du volume jusqu’au curl de vérification, en passant par le sign-in interactif.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">import java.io.ByteArrayOutputStream plugins { base } // ------------------------------------------------------------------------- // Configuration // ------------------------------------------------------------------------- val instanceName = "ollama-instance-b" val instancePort = 11435 val instanceImage = "ollama/ollama:0.20.2" val dataDir = file("${System.getProperty("user.home")}/ollama-b-data") val nativePort = 11434 // Modèles à gérer — cloud Pro + un modèle local gratuit pour les tests val proModels = listOf("deepseek-v4-pro:cloud", "gemma4:31b-cloud") val freeModels = listOf("qwen3:0.6b") // ------------------------------------------------------------------------- // Tâche préparatoire — création du volume si absent // ------------------------------------------------------------------------- val prepareVolume by tasks.registering { group = "ollama" description = "Crée le répertoire de volume pour l'instance B si absent" doLast { if (!dataDir.exists()) { dataDir.mkdirs() println("Volume créé : ${dataDir.absolutePath}") } else { println("Volume existant : ${dataDir.absolutePath}") } } } // ------------------------------------------------------------------------- // Démarrage du conteneur Docker // ------------------------------------------------------------------------- val startOllamaB by tasks.registering(Exec::class) { group = "ollama" description = "Lance le conteneur Docker pour l'instance Ollama B" dependsOn(prepareVolume) commandLine( "docker", "run", "-d", "--name", instanceName, "-p", "$instancePort:11434", "-v", "${dataDir.absolutePath}:/root/.ollama", "-e", "OLLAMA_HOST=0.0.0.0", "--restart", "always", instanceImage ) isIgnoreExitValue = true doLast { val alreadyRunning = executionResult.get().exitValue != 0 if (alreadyRunning) { logger.lifecycle("Le conteneur '$instanceName' existe déjà — tentative de démarrage") } else { logger.lifecycle("Conteneur '$instanceName' lancé") } } } // ------------------------------------------------------------------------- // Arrêt du conteneur // ------------------------------------------------------------------------- val stopOllamaB by tasks.registering(Exec::class) { group = "ollama" description = "Arrête le conteneur Docker de l'instance B" commandLine("docker", "stop", instanceName) isIgnoreExitValue = true doLast { logger.lifecycle("Conteneur '$instanceName' arrêté") } } // ------------------------------------------------------------------------- // Affichage de la clé publique (Device Key) // ------------------------------------------------------------------------- val checkIdentity by tasks.registering(Exec::class) { group = "ollama" description = "Affiche la clé publique SSH de l'instance B" dependsOn(startOllamaB) commandLine("docker", "exec", instanceName, "cat", "/root/.ollama/id_ed25519.pub") standardOutput = ByteArrayOutputStream() doLast { val pubKey = standardOutput.toString().trim() println("=".repeat(60)) println("Device Key (Instance B)") println("=".repeat(60)) println(pubKey) println("=".repeat(60)) println("→ Enregistre cette clé sur https://ollama.com/settings/keys") println("→ Puis exécute : ./gradlew signInB") println("=".repeat(60)) } } // ------------------------------------------------------------------------- // Sign-in interactif (Ouvrira le navigateur) // ------------------------------------------------------------------------- val signInB by tasks.registering(Exec::class) { group = "ollama" description = "Lance l'authentification interactive Ollama pour le compte B" dependsOn(startOllamaB) standardInput = System.`in` standardOutput = System.out errorOutput = System.err commandLine("docker", "exec", "-it", instanceName, "ollama", "signin") doFirst { logger.lifecycle("Authentification pour le Compte Pro B...") logger.lifecycle("Ouvre ton navigateur et connecte-toi avec l'email du compte B") } } // ------------------------------------------------------------------------- // Pull d'un modèle (paramétrable via propriété Gradle) // ------------------------------------------------------------------------- val pullModelB by tasks.registering(Exec::class) { group = "ollama" description = "Pull un modèle sur l'instance B. Usage : ./gradlew pullModelB -Pmodel=nom:tag" dependsOn(startOllamaB) val modelName = project.findProperty("model") as? String ?: "qwen3:0.6b" commandLine("docker", "exec", instanceName, "ollama", "pull", modelName) doFirst { logger.lifecycle("Pull du modèle '$modelName' sur l'instance B...") } doLast { logger.lifecycle("Modèle '$modelName' pullé avec succès") } } // ------------------------------------------------------------------------- // Pull de tous les modèles Pro (batch) // ------------------------------------------------------------------------- val pullAllProModels by tasks.registering { group = "ollama" description = "Pull tous les modèles cloud Pro sur l'instance B" dependsOn(startOllamaB) doLast { proModels.forEach { model -> logger.lifecycle("→ Pull $model...") val process = ProcessBuilder("docker", "exec", instanceName, "ollama", "pull", model) .inheritIO() .start() process.waitFor() } logger.lifecycle("Tous les modèles Pro pullés") } } // ------------------------------------------------------------------------- // Pull de tous les modèles gratuits (batch / première install) // ------------------------------------------------------------------------- val pullAllFreeModels by tasks.registering { group = "ollama" description = "Pull tous les modèles locaux gratuits sur l'instance B" dependsOn(startOllamaB) doLast { freeModels.forEach { model -> logger.lifecycle("→ Pull $model...") val process = ProcessBuilder("docker", "exec", instanceName, "ollama", "pull", model) .inheritIO() .start() process.waitFor() } logger.lifecycle("Tous les modèles gratuits pullés") } } // ------------------------------------------------------------------------- // Liste des modèles disponibles sur l'instance B // ------------------------------------------------------------------------- val listModelsB by tasks.registering(Exec::class) { group = "ollama" description = "Liste les modèles disponibles sur l'instance B" dependsOn(startOllamaB) commandLine("docker", "exec", instanceName, "ollama", "list") } // ------------------------------------------------------------------------- // Health check — test API sur les deux instances // ------------------------------------------------------------------------- val testOllamaB by tasks.registering { group = "ollama" description = "Teste la connectivité API de l'instance B avec un simple chat" dependsOn(startOllamaB) doLast { val model = project.findProperty("model") as? String ?: "qwen3:0.6b" logger.lifecycle("Test de l'instance B avec le modèle '$model'...") val payload = """ { "model": "$model", "messages": [{"role": "user", "content": "Réponds uniquement par OK"}], "max_tokens": 5 } """.trimIndent() val process = ProcessBuilder( "curl", "-s", "http://localhost:$instancePort/v1/chat/completions", "-H", "Content-Type: application/json", "-d", payload ).start() val response = process.inputStream.bufferedReader().readText() process.waitFor() if (response.contains("\"id\":\"chatcmpl") || response.contains("\"choices\"")) { println("✓ Instance B OK — port $instancePort répond") println(" Response: ${response.take(120)}...") } else { println("✗ Instance B INACTIVE — vérifie le conteneur avec './gradlew statusOllamaAll'") println(" Raw: $response") } } } // ------------------------------------------------------------------------- // Health check sur les deux instances simultanément // ------------------------------------------------------------------------- val statusOllamaAll by tasks.registering { group = "ollama" description = "Vérifie le statut des deux instances Ollama (native + Docker)" doLast { // Instance native runCatching { val process = ProcessBuilder( "curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "http://localhost:$nativePort/api/tags" ).start() val code = process.inputStream.bufferedReader().readText().trim() process.waitFor() println(if (code == "200") "✓ Instance Native — port $nativePort OK (HTTP $code)" else "✗ Instance Native — port $nativePort (HTTP $code)") }.getOrElse { println("✗ Instance Native — injoignable sur le port $nativePort") } // Instance Docker runCatching { val process = ProcessBuilder( "curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "http://localhost:$instancePort/api/tags" ).start() val code = process.inputStream.bufferedReader().readText().trim() process.waitFor() println(if (code == "200") "✓ Instance Docker B — port $instancePort OK (HTTP $code)" else "✗ Instance Docker B — port $instancePort (HTTP $code)") }.getOrElse { println("✗ Instance Docker B — injoignable sur le port $instancePort") } // Info conteneur runCatching { val process = ProcessBuilder("docker", "ps", "--filter", "name=$instanceName", "--format", "table {{.Names}}\\t{{.Status}}\\t{{.Ports}}").start() val status = process.inputStream.bufferedReader().readText() process.waitFor() println() println("Conteneur Docker :") println(status) } } } // ------------------------------------------------------------------------- // Nettoyage complet // ------------------------------------------------------------------------- val cleanOllamaB by tasks.registering(Exec::class) { group = "ollama" description = "Arrête et supprime le conteneur Docker de l'instance B" dependsOn(stopOllamaB) commandLine("docker", "rm", instanceName) isIgnoreExitValue = true doLast { logger.lifecycle("Conteneur '$instanceName' supprimé") logger.lifecycle("Le volume ${dataDir.absolutePath} est conservé (identité persistante)") } } // ------------------------------------------------------------------------- // Affichage des instructions // ------------------------------------------------------------------------- val helpOllama by tasks.registering { group = "ollama" description = "Affiche l'aide des tâches Ollama disponibles" doLast { println(""" ╔══════════════════════════════════════════════════════════════╗ ║ Tâches Gradle — Pilotage Dual Ollama Pro ║ ╠══════════════════════════════════════════════════════════════╣ ║ ./gradlew startOllamaB Démarrer l'instance Docker B ║ ║ ./gradlew stopOllamaB Arrêter l'instance Docker B ║ ║ ./gradlew checkIdentity Afficher la clé SSH publique ║ ║ ./gradlew signInB Sign-in interactif compte B ║ ║ ./gradlew pullModelB Pull un modèle (-Pmodel=...) ║ ║ ./gradlew pullAllProModels Pull tous les modèles Pro ║ ║ ./gradlew pullAllFreeModels Pull tous les modèles gratuits ║ ║ ./gradlew listModelsB Lister les modèles instance B ║ ║ ./gradlew testOllamaB Test API avec un chat simple ║ ║ ./gradlew statusOllamaAll Santé des 2 instances ║ ║ ./gradlew cleanOllamaB Supprimer le conteneur ║ ║ ./gradlew helpOllama Cette aide ║ ╚══════════════════════════════════════════════════════════════╝ """.trimIndent()) } }</code></pre> </div> </div> <div class="paragraph"> <p>Voilà. Douze tâches, un point d’entrée unique, et zéro friction.</p> </div> </div> </div> <div class="sect1"> <h2 id="anatomie_des_tâches_clés">4. Anatomie des Tâches Clés</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="startollamab_le_lanceur">4.1. <code>startOllamaB</code> — Le Lanceur</h3> <div class="paragraph"> <p>Rien de sorcier : un <code>docker run -d</code> avec les bons paramètres. L’astuce est dans <code>isIgnoreExitValue = true</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">isIgnoreExitValue = true</code></pre> </div> </div> <div class="paragraph"> <p>Si le conteneur existe déjà, la commande <code>docker run</code> échoue (exit code ≠ 0). Sans cette propriété, Gradle arrêterait tout le build en erreur. Ici, l’échec est silencieux — et le <code>doLast</code> détecte si c’était un "déjà existant" ou une vraie erreur.</p> </div> <div class="paragraph"> <p>Le <code>doLast</code> est crucial : il tourne <strong>après</strong> l’exécution de la commande, ce qui permet d’inspecter <code>executionResult.get().exitValue</code> et de logger un message approprié.</p> </div> </div> <div class="sect2"> <h3 id="signinb_linteractif">4.2. <code>signInB</code> — L’Interactif</h3> <div class="paragraph"> <p>C’est la seule tâche qui nécessite une interaction humaine. Gradle transmet <code>System.in</code> au process pour que le prompt <code>ollama signin</code> puisse s’afficher normalement :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">standardInput = System.`in` standardOutput = System.out errorOutput = System.err</code></pre> </div> </div> <div class="paragraph"> <p>Sans ça, le sign-in bloquerait car stdin serait fermé et vous ne verriez jamais le prompt.</p> </div> </div> <div class="sect2"> <h3 id="pullmodelb_le_paramétrable">4.3. <code>pullModelB</code> — Le Paramétrable</h3> <div class="paragraph"> <p>Une tâche générique qui accepte un paramètre via <code>-P</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">./gradlew pullModelB -Pmodel=deepseek-v4-pro:cloud ./gradlew pullModelB # fallback : qwen3:0.6b</code></pre> </div> </div> <div class="paragraph"> <p>Le fallback est important : <code>project.findProperty("model") as? String ?: "qwen3:0.6b"</code> garantit que la tâche ne pète pas si on oublie le paramètre.</p> </div> </div> <div class="sect2"> <h3 id="statusollamaall_le_diagnostic">4.4. <code>statusOllamaAll</code> — Le Diagnostic</h3> <div class="paragraph"> <p>Deux <code>curl</code> en santé sur les ports <code>11434</code> et <code>11435</code>, avec un fallback en <code>runCatching</code> pour ne pas crasher si l’une des instances est down. La sortie est structurée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">✓ Instance Native — port 11434 OK (HTTP 200) ✓ Instance Docker B — port 11435 OK (HTTP 200) Conteneur Docker : NAMES STATUS PORTS ollama-instance-b Up 3 hours 0.0.0.0:11435->11434/tcp</code></pre> </div> </div> <div class="paragraph"> <p>Un coup d’œil, et tu sais exactement ce qui tourne et ce qui cloche.</p> </div> </div> <div class="sect2"> <h3 id="cleanollamab_le_nettoyage_qui_préserve_lidentité">4.5. <code>cleanOllamaB</code> — Le Nettoyage qui Préserve l’Identité</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">commandLine("docker", "rm", instanceName) isIgnoreExitValue = true</code></pre> </div> </div> <div class="paragraph"> <p>Le conteneur est supprimé, mais le volume <code>~/ollama-b-data</code> est <strong>conservé</strong>. L’identité SSH survit au nettoyage. Au prochain <code>startOllamaB</code>, les mêmes clés seront réutilisées — pas besoin de refaire le sign-in ni de ré-enregistrer la Device Key.</p> </div> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> <div class="paragraph"> <p><code>cleanOllamaB</code> ne touche pas au volume. Si tu veux effacer l’identité B (et tout recommencer à zéro), il faut supprimer <code>~/ollama-b-data</code> manuellement. C’est volontaire — un <code>clean</code> ne devrait pas détruire des credentials.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="workflow_complet_de_zéro_à_deux_sessions">5. Workflow Complet — De Zéro à Deux Sessions</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici la séquence idéale pour quelqu’un qui arrive sur le projet et veut tout mettre en place sans ouvrir de documentation :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text"># 1. Premier contact — que faire ? $ ./gradlew helpOllama # 2. On démarre l'instance B $ ./gradlew startOllamaB # 3. On récupère la Device Key et on l'enregistre sur ollama.com $ ./gradlew checkIdentity # → copier-coller de la clé sur https://ollama.com/settings/keys # 4. Authentification interactive $ ./gradlew signInB # 5. Pull d'un petit modèle gratuit pour tester la plomberie $ ./gradlew pullModelB # 6. Test API $ ./gradlew testOllamaB # 7. Si tout est vert, pull des modèles Pro $ ./gradlew pullAllProModels # 8. Vérification finale des deux instances $ ./gradlew statusOllamaAll</code></pre> </div> </div> <div class="paragraph"> <p>Moins de deux minutes, tout est provisionné. Pas de README à lire, pas de variables d’environnement à setter. La tâche <code>helpOllama</code> fait office de documentation intégrée.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/workflow-complet-sequence.svg" alt="workflow complet sequence" width="757" height="1103"> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_ne_pas_en_faire_un_vrai_plugin_gradle">6. Pourquoi Ne Pas en Faire un Vrai Plugin Gradle ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Question légitime. Extraire ce <code>build.gradle.kts</code> en un plugin Gradle autonome aurait des avantages : réutilisation entre projets, configuration déclarative, extension DSL.</p> </div> <div class="paragraph"> <p>Mais pour l’instant, ça n’a pas de sens. Ce build n’a pas de logique métier complexe — c’est un wrapper autour de commandes Docker et curl. La surcouche d’un plugin Gradle complet (avec extension, tests unitaires, publication) serait disproportionnée pour 12 tâches utilitaires.</p> </div> <div class="paragraph"> <p>Le <code>build.gradle.kts</code> inline vit dans le projet qui en a besoin. Il est trivial à copier ailleurs. Si un jour j’ai trois projets qui en dépendent, je le transformerai en plugin. Pour l’instant, KISS.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> <div class="paragraph"> <p>Le jour où tu as trois <code>build.gradle.kts</code> identiques dans trois projets, c’est le signal qu’il faut extraire un plugin. Avant ça, la duplication est moins coûteuse que l’abstraction. Sagesse de dev.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="leçons_apprises">7. Leçons Apprises</h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Gradle n’est pas qu’un build tool</strong> — Le moteur de graphe de dépendances en fait un orchestrateur d’infrastructure redoutable. <code>doLast</code>, <code>isIgnoreExitValue</code>, <code>dependsOn</code> : ces trois primitives suffisent à piloter un conteneur Docker avec la même fiabilité qu’un pipeline CI.</p> </li> <li> <p><strong><code>isIgnoreExitValue</code> est ton ami</strong> — Dans un monde idéal, <code>docker run</code> sur un conteneur déjà existant renverrait un warning plutôt qu’un exit code d’erreur. Dans le monde réel, tu mets <code>isIgnoreExitValue = true</code> et tu gères le diagnostic dans <code>doLast</code>.</p> </li> <li> <p><strong>Les tâches paramétrables tuent l’ambiguïté</strong> — Un <code>pullModelB</code> générique avec <code>-Pmodel=…​</code> remplace N tâches spécialisées. Une seule tâche, une seule doc, un seul comportement.</p> </li> <li> <p><strong><code>runCatching</code> pour les health checks</strong> — Quand tu testes N endpoints, le crash du premier ne doit pas empêcher de tester les autres. <code>runCatching</code> + <code>getOrElse</code> par endpoint, et le diagnostic reste complet même en cas de panne partielle.</p> </li> <li> <p><strong>La tâche <code>helpOllama</code> comme documentation exécutable</strong> — Un <code>println()</code> bien formaté remplace un README de trois paragraphes. C’est auto-documenté, toujours à jour, et accessible sans sortir du terminal.</p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="conclusion">8. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>On est passé de commandes docker à taper à la main à un workflow Gradle complet, versionné, réutilisable. Douze tâches couvrent tout le cycle de vie : provisionnement, identité, sign-in, pull, test, diagnostic, nettoyage.</p> </div> <div class="paragraph"> <p>Le combo docker-compose + build.gradle.kts + opencode.json forme une trinité propre : Docker pour l’isolation, Gradle pour l’orchestration, OpenCode pour la consommation. Chaque couche a sa responsabilité, et aucune ne déborde sur l’autre.</p> </div> <div class="paragraph"> <p>Prochaine étape ? Automatiser le cycle de vie dans la CI pour que les instances Ollama soient disponibles dans les environnements de dev éphémères. Mais ça, c’est un autre article.</p> </div> </div> </div> <div class="sect1"> <h2 id="ressources">9. Ressources</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://docs.gradle.org/current/userguide/tutorial_using_tasks.html">User Manual Gradle — Tâches</a></p> </li> <li> <p><a href="https://docs.gradle.org/current/userguide/custom_tasks.html">User Manual Gradle — Tâches Custom</a></p> </li> <li> <p><a href="https://hub.docker.com/r/ollama/ollama">Image Docker Ollama sur Docker Hub</a></p> </li> <li> <p><a href="https://kotlinlang.org/docs/gradle.html">Gradle DSL Kotlin — Documentation</a></p> </li> </ul> </div> <hr> <div class="paragraph"> <p><em>Article publié le 2026-05-08</em></p> </div> </div> </div> https://pages-content.github.io//blog/2026/0120_cumuler_deux_abonnements_ollama_pro_docker_post.html Fri, 8 May 2026 00:00:00 +0000 blog/2026/0120_cumuler_deux_abonnements_ollama_pro_docker_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#introduction">1. Introduction</a></li> <li><a href="#pourquoi_deux_fois_la_même_chose">2. Pourquoi Deux Fois la Même Chose ?</a></li> <li><a href="#le_coeur_du_problème_la_device_key">3. Le Coeur du Problème : La Device Key</a></li> <li><a href="#mise_en_place_étape_par_étape">4. Mise en Place — Étape par Étape</a> <ul class="sectlevel2"> <li><a href="#prérequis">4.1. Prérequis</a></li> <li><a href="#étape_1_créer_le_volume">4.2. Étape 1 : Créer le Volume</a></li> <li><a href="#étape_2_lancer_le_conteneur_docker">4.3. Étape 2 : Lancer le Conteneur Docker</a></li> <li><a href="#étape_3_récupérer_la_clé_publique">4.4. Étape 3 : Récupérer la Clé Publique</a></li> <li><a href="#étape_4_enregistrer_la_clé_sur_ollama_com">4.5. Étape 4 : Enregistrer la Clé sur Ollama.com</a></li> <li><a href="#étape_5_tester_avec_un_petit_modèle_gratuit">4.6. Étape 5 : Tester avec un Petit Modèle Gratuit</a></li> </ul> </li> <li><a href="#le_piège_de_lapi_v1models">5. Le Piège de l’API <code>/v1/models</code></a></li> <li><a href="#résultat_deux_sessions_deux_comptes_zéro_conflit">6. Résultat : Deux Sessions, Deux Comptes, Zéro Conflit</a></li> <li><a href="#leçons_apprises">7. Leçons Apprises</a></li> <li><a href="#pour_aller_plus_loin">8. Pour Aller Plus Loin</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 14 minutes</div> <p>Deux abonnements Pro, une seule machine, une seule carte bancaire, et zéro conflit réseau. Comment Docker m’a permis de doubler ma capacité d’inférence cloud sans acheter un deuxième PC.</p> </div> </div> </div> <div class="sect1"> <h2 id="introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>J’utilise Ollama Pro depuis plusieurs mois pour alimenter mes sessions OpenCode en modèles cloud. Le truc, c’est que même avec un abonnement Pro, on est vite limité par le <strong>rate limiting</strong> quand on lance plusieurs agents en parallèle. La solution évidente : un deuxième abonnement.</p> </div> <div class="paragraph"> <p>Mais là, c’est le drame.</p> </div> <div class="paragraph"> <p>Ollama identifie chaque machine par une clé SSH unique — sa fameuse <strong>Device Key</strong>. Deux instances sur le même OS partageraient la même identité, et impossible de lier deux comptes Pro au même device. Et comme vous vous en doutez, je n’allais pas acheter un deuxième laptop juste pour ça.</p> </div> <div class="paragraph"> <p>La solution : tricher. Faire croire à Ollama qu’il tourne sur deux machines différentes, alors qu’elles partagent le même CPU, la même RAM, et la même connexion réseau. Docker va nous offrir une bulle d’isolation parfaite.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/architecture-dual-ollama.svg" alt="architecture dual ollama" width="509" height="420"> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_deux_fois_la_même_chose">2. Pourquoi Deux Fois la Même Chose ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant de me traiter de malade mental, laissez-moi vous expliquer le cas d’usage.</p> </div> <div class="paragraph"> <p>Avec un seul abonnement Pro, je peux lancer un modèle comme <code>deepseek-v4-pro:cloud</code> dans une session OpenCode. Le problème surgit quand je veux <strong>deux</strong> sessions simultanées. Les quotas de rate limiting font que la deuxième session rame ou est purement rejetée.</p> </div> <div class="paragraph"> <p>Avec deux abonnements Pro indépendants : * Session OpenCode 1 → Compte Pro A (<code>localhost:11434</code>) * Session OpenCode 2 → Compte Pro B (<code>localhost:11435</code>)</p> </div> <div class="paragraph"> <p>Chaque session a son propre quota, son propre contexte, et ne gêne pas l’autre. C’est du multi-processing humain.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Deux abonnements Pro = deux emails différents. La même carte bancaire fonctionne — le système de paiement Ollama ne bloque pas les souscriptions multiples depuis le même moyen de paiement. J’ai vérifié.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="le_coeur_du_problème_la_device_key">3. Le Coeur du Problème : La Device Key</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quand vous installez Ollama, une paire de clés SSH ed25519 est générée dans le répertoire d’identité :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ cat /usr/share/ollama/.ollama/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...</code></pre> </div> </div> <div class="paragraph"> <p>Cette clé est uploadée vers les serveurs d’Ollama lors du <code>ollama signin</code>. C’est elle qui dit « cette machine appartient à tel compte Pro ». Si vos deux instances partagent le même fichier <code>id_ed25519</code>, elles partagent la même identité. Fin du game.</p> </div> <div class="paragraph"> <p>La parade : donner à notre deuxième instance son propre répertoire d’identité, isolé dans un volume Docker.</p> </div> </div> </div> <div class="sect1"> <h2 id="mise_en_place_étape_par_étape">4. Mise en Place — Étape par Étape</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="prérequis">4.1. Prérequis</h3> <div class="ulist"> <ul> <li> <p>Une installation native d’Ollama fonctionnelle (script officiel <code>curl | sh</code>)</p> </li> <li> <p>Docker installé et fonctionnel</p> </li> <li> <p>Portainer ou docker-compose pour le déploiement</p> </li> <li> <p>Deux comptes Ollama avec deux emails distincts</p> </li> </ul> </div> <div class="paragraph"> <p>J’ai utilisé la version <code>0.20.2</code> — celle fournie par le script officiel et l’image Docker correspondante.</p> </div> </div> <div class="sect2"> <h3 id="étape_1_créer_le_volume">4.2. Étape 1 : Créer le Volume</h3> <div class="paragraph"> <p>Un simple répertoire sur l’hôte servira de volume persistant pour l’identité de l’instance B :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">mkdir -p ~/ollama-b-data</code></pre> </div> </div> <div class="paragraph"> <p>Ce dossier sera monté dans le conteneur Docker comme <code>/root/.ollama</code>, là où Ollama stocke ses clés d’identité, son historique et ses modèles.</p> </div> </div> <div class="sect2"> <h3 id="étape_2_lancer_le_conteneur_docker">4.3. Étape 2 : Lancer le Conteneur Docker</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-yaml hljs" data-lang="yaml"># docker-compose.yml services: ollama-instance-b: image: ollama/ollama:0.20.2 container_name: ollama-instance-b ports: - "11435:11434" volumes: - /home/cheroliv/ollama-b-data:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0 restart: always</code></pre> </div> </div> <div class="paragraph"> <p>Ce qui se passe ici : * Le port <strong>11435</strong> de l’hôte est mappé sur le <strong>11434</strong> interne du conteneur. Ainsi, l’instance Docker écoute sur <code>:11435</code> sans conflit avec l’instance native qui squatte <code>:11434</code>. * Le volume <code>~/ollama-b-data</code> est monté sur <code>/root/.ollama</code> — c’est là que l’identité SSH sera stockée. * <code>OLLAMA_HOST=0.0.0.0</code> permet au conteneur d’accepter des connexions externes.</p> </div> <div class="paragraph"> <p>J’ai déployé cette stack via Portainer, mais un simple <code>docker compose up -d</code> fonctionne tout aussi bien.</p> </div> </div> <div class="sect2"> <h3 id="étape_3_récupérer_la_clé_publique">4.4. Étape 3 : Récupérer la Clé Publique</h3> <div class="paragraph"> <p>Le conteneur étant vierge au premier démarrage, Ollama génère automatiquement une nouvelle paire de clés SSH dans le volume. On récupère la clé publique :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ docker exec ollama-instance-b cat /root/.ollama/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ+dvnfmuo49q5O8LOlvgZ39SKORFw47ry9k4H2jPc</code></pre> </div> </div> <div class="paragraph"> <p>Je vérifie que cette clé est <strong>différente</strong> de celle de l’instance native :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Instance native $ cat /usr/share/ollama/.ollama/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGyF...(différente) # Instance Docker $ cat ~/ollama-b-data/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ...(différente)</code></pre> </div> </div> <div class="paragraph"> <p>Deux clés distinctes, deux identités séparées. Le tour est joué.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> <div class="paragraph"> <p>Si votre conteneur redémarre, il <strong>réutilise</strong> les clés présentes dans le volume. L’identité est persistante. Vous ne perdrez pas l’association avec le compte Pro.</p> </div> </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="étape_4_enregistrer_la_clé_sur_ollama_com">4.5. Étape 4 : Enregistrer la Clé sur Ollama.com</h3> <div class="paragraph"> <p>Direction <a href="https://ollama.com/settings/keys" class="bare">https://ollama.com/settings/keys</a> → Add SSH Key. On colle la clé publique de l’instance Docker et on valide.</p> </div> <div class="paragraph"> <p>Ensuite, on lie cette identité au compte Pro B :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ docker exec -it ollama-instance-b ollama signin</code></pre> </div> </div> <div class="paragraph"> <p>Le navigateur s’ouvre, on se connecte avec l’email du compte B, et le token est associé à la clé SSH du conteneur. On vérifie que tout est OK :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ docker exec -it ollama-instance-b ollama signin User: cherolivpro</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="étape_5_tester_avec_un_petit_modèle_gratuit">4.6. Étape 5 : Tester avec un Petit Modèle Gratuit</h3> <div class="paragraph"> <p>Avant de balancer le prix d’un abonnement Pro, je veux être certain que le tuyau fonctionne. Je pull un petit modèle local et gratuit pour valider la connectivité :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ docker exec ollama-instance-b ollama pull qwen3:0.6b pulling manifest pulling 7f4030143c1c: 100% ▕██████████████████▏ 522 MB success $ curl -s http://localhost:11435/api/tags {"models":[{"name":"qwen3:0.6b","model":"qwen3:0.6b",...}]}</code></pre> </div> </div> <div class="paragraph"> <p>Le port <code>11435</code> répond, le modèle est servi. L’instance B est vivante.</p> </div> <div class="paragraph"> <p>Une fois rassuré, je passe au pull du vrai modèle cloud Pro :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ docker exec ollama-instance-b ollama pull deepseek-v4-pro:cloud pulling manifest pulling 31c3059e137e: 100% ▕██████████████████▏ 344 B success</code></pre> </div> </div> <div class="paragraph"> <p>344 octets pour le manifeste d’un modèle cloud — normal, l’inférence se fait côté serveur, pas en local. Et voilà le test ultime :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ curl -s http://localhost:11435/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-v4-pro:cloud","messages":[{"role":"user","content":"Dis bonjour en une phrase courte."}]}' { "id": "chatcmpl-480", "model": "deepseek-v4-pro", "choices": [{ "message": { "content": "Bonjour !" }, "finish_reason": "stop" }], "usage": { "total_tokens": 181 } }</code></pre> </div> </div> <div class="paragraph"> <p>Bonjour à toi aussi, instance B.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_piège_de_lapi_v1models">5. Le Piège de l’API <code>/v1/models</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>J’ai perdu 20 minutes sur un détail idiot. Quand j’ai configuré le provider <code>ollama-b</code> dans OpenCode, rien n’apparaissait dans le sélecteur de modèles. Rien. Que dalle.</p> </div> <div class="paragraph"> <p>La raison ? L’API <code>/v1/models</code> de l’instance B retournait <code>{"object":"list","data":null}</code> au lieu de <code>{"object":"list","data":[]}</code> quand aucun modèle n’était pullé. La valeur <code>null</code> faisait planter le parsing côté OpenCode, qui n’affichait pas le provider.</p> </div> <div class="paragraph"> <p>La solution : déclarer les modèles <strong>explicitement</strong> dans la configuration OpenCode plutôt que de compter sur la découverte dynamique.</p> </div> <div class="listingblock"> <div class="title">~/.config/opencode/opencode.json</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-json hljs" data-lang="json">{ "$schema": "https://opencode.ai/config.json", "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "name": "Ollama (local)", "options": { "baseURL": "http://localhost:11434/v1" }, "models": { "gemma4:e2b": { "name": "Gemma 4 E2B (local)" } } }, "ollama-b": { "npm": "@ai-sdk/openai-compatible", "name": "Ollama Instance B (Docker)", "options": { "baseURL": "http://localhost:11435/v1" }, "models": { "qwen3:0.6b": { "name": "Qwen3 0.6B (B)" }, "deepseek-v4-pro:cloud": { "name": "DeepSeek V4 Pro (B)" } } } } }</code></pre> </div> </div> <div class="paragraph"> <p>Avec cette déclaration explicite, OpenCode voit immédiatement le provider B et ses modèles. Un redémarrage de session, et le sélecteur <code>/models</code> affiche les deux instances côte à côte.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> <div class="paragraph"> <p>Si vous ne voyez pas votre provider custom dans <code>/models</code>, ne perdez pas trois heures à redémarrer votre terminal. Déclarez les modèles manuellement dans <code>opencode.json</code> — ça règle le problème instantanément.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="résultat_deux_sessions_deux_comptes_zéro_conflit">6. Résultat : Deux Sessions, Deux Comptes, Zéro Conflit</h2> <div class="sectionbody"> <div class="paragraph"> <p>Au final, je peux lancer deux sessions OpenCode simultanément :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">Session 1 → /models → Ollama (local) → deepseek-v4-pro:cloud → Compte A Session 2 → /models → Ollama Instance B (Docker) → deepseek-v4-pro:cloud → Compte B</code></pre> </div> </div> <div class="paragraph"> <p>Chaque session a son propre quota, son propre rate limit, et ne se marche pas sur les pieds. Même machine, même carte bleue, deux emails différents.</p> </div> <div class="paragraph"> <p>Et le meilleur ? Le conteneur Docker est en <code>restart: always</code>. Il survit aux reboots du système sans intervention manuelle.</p> </div> </div> </div> <div class="sect1"> <h2 id="leçons_apprises">7. Leçons Apprises</h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Docker isole tout, même l’identité</strong> — Un simple bind mount de volume suffit à donner à un conteneur son propre jeu de clés SSH, le rendant indistinguable d’une machine physique différente aux yeux d’Ollama.</p> </li> <li> <p><strong>Deux emails, même CB</strong> — Ollama ne bloque pas les souscriptions multiples depuis le même moyen de paiement. Seul l’email doit être distinct.</p> </li> <li> <p><strong>Tester gratuit avant de payer</strong> — Un <code>ollama pull qwen3:0.6b</code> (modèle libre, 522 Mo) permet de valider toute la chaîne réseau sans débourser un centime. Vous validez le plomberie d’abord, vous activez le Pro ensuite.</p> </li> <li> <p><strong><code>/v1/models</code> avec <code>data: null</code> casse OpenCode</strong> — Si vous configurez un provider custom avec <code>"models": {}</code>, OpenCode tente de découvrir les modèles via l’API. Si l’API répond <code>data: null</code>, le provider n’apparaît pas. Déclarez les modèles explicitement.</p> </li> <li> <p><strong>Deux comptes, c’est du multi-processing humain</strong> — Un compte Pro = une session OpenCode active. Deux comptes = deux sessions parallèles. Pour quelqu’un qui jongle entre plusieurs projets Gradle en simultané, c’est un game changer.</p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="pour_aller_plus_loin">8. Pour Aller Plus Loin</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://ollama.com/settings/keys">Ollama Settings — Gestion des clés SSH</a></p> </li> <li> <p><a href="https://docs.ollama.com/">Documentation officielle Ollama</a></p> </li> <li> <p><a href="https://hub.docker.com/r/ollama/ollama">Image Docker Ollama sur Docker Hub</a></p> </li> <li> <p><a href="https://opencode.ai/docs/providers/#ollama">OpenCode — Configuration Provider Ollama</a></p> </li> </ul> </div> <hr> <div class="paragraph"> <p><em>Article publié le 2026-05-08</em></p> </div> </div> </div> https://pages-content.github.io//blog/2025/0080_kitty_term_post.html Thu, 7 May 2026 00:00:00 +0000 blog/2025/0080_kitty_term_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_pourquoi_choisir_kitty_et_zsh">1. Pourquoi choisir Kitty et Zsh ?</a></li> <li><a href="#_pré_requis_système">2. Pré-requis système</a></li> <li><a href="#_téléchargement_et_installation_de_kitty">3. Téléchargement et installation de Kitty</a> <ul class="sectlevel2"> <li><a href="#_télécharger_le_script_dinstallation">3.1. Télécharger le script d’installation</a></li> <li><a href="#_création_des_liens_symboliques">3.2. Création des liens symboliques</a></li> </ul> </li> <li><a href="#_intégration_de_kitty_dans_xubuntu">4. Intégration de Kitty dans Xubuntu</a> <ul class="sectlevel2"> <li><a href="#_copier_le_fichier_desktop">4.1. Copier le fichier desktop</a></li> <li><a href="#_modifier_le_fichier_desktop">4.2. Modifier le fichier desktop</a></li> <li><a href="#_associer_kitty_comme_terminal_par_défaut_facultatif">4.3. Associer Kitty comme terminal par défaut (facultatif)</a></li> </ul> </li> <li><a href="#_installation_de_zsh">5. Installation de Zsh</a></li> <li><a href="#_définir_zsh_comme_shell_par_défaut">6. Définir Zsh comme shell par défaut</a> <ul class="sectlevel2"> <li><a href="#_méthode_globale_pour_tous_les_terminaux">6.1. Méthode globale (pour tous les terminaux)</a></li> <li><a href="#_méthode_spécifique_à_kitty">6.2. Méthode spécifique à Kitty</a></li> </ul> </li> <li><a href="#_configuration_de_zsh_optionnel">7. Configuration de Zsh (optionnel)</a> <ul class="sectlevel2"> <li><a href="#_créer_un_fichier_zshrc">7.1. Créer un fichier .zshrc</a></li> <li><a href="#_exemple_de_configuration_minimale">7.2. Exemple de configuration minimale</a></li> </ul> </li> <li><a href="#_résumé_du_workflow_complet">8. Résumé du workflow complet</a></li> <li><a href="#_vérification_finale">9. Vérification finale</a> <ul class="sectlevel2"> <li><a href="#_ouvrir_le_fichier_de_configuration">9.1. 📂 Ouvrir le fichier de configuration</a></li> <li><a href="#_️_ajouter_ou_modifier_font_size">9.2. 🖋️ Ajouter ou modifier <code>font_size</code></a></li> <li><a href="#_enregistrer_et_relancer_kitty">9.3. 💾 Enregistrer et relancer Kitty</a></li> <li><a href="#_ajustement_dynamique_zoom_temporaire">9.4. ✅ Ajustement dynamique (Zoom temporaire)</a></li> </ul> </li> <li><a href="#_installation_et_configuration_de_oh_my_zsh">10. Installation et configuration de Oh My Zsh</a> <ul class="sectlevel2"> <li><a href="#_installation_de_oh_my_zsh">10.1. Installation de Oh My Zsh</a></li> <li><a href="#_changer_le_thème">10.2. Changer le thème</a></li> <li><a href="#_vérification">10.3. Vérification</a></li> <li><a href="#_diagramme_du_use_case">10.4. Diagramme du use case</a></li> </ul> </li> <li><a href="#_activer_la_translucidité_dans_kitty">11. Activer la translucidité dans Kitty</a> <ul class="sectlevel2"> <li><a href="#_pré_requis_pour_la_transparence">11.1. Pré-requis pour la transparence</a></li> <li><a href="#_configuration_de_la_transparence_dans_kitty_conf">11.2. Configuration de la transparence dans kitty.conf</a></li> <li><a href="#_redémarrer_kitty">11.3. Redémarrer Kitty</a></li> <li><a href="#_compléments_possibles">11.4. Compléments possibles</a></li> <li><a href="#_diagramme_de_séquence_initialisation_de_kitty_avec_transparence">11.5. Diagramme de séquence - Initialisation de Kitty avec transparence</a></li> <li><a href="#_limitations_connues">11.6. Limitations connues</a></li> </ul> </li> <li><a href="#_désactiver_le_bip_sonore_audible_bell">12. Désactiver le bip sonore (audible bell)</a></li> <li><a href="#_mise_à_jour_de_kitty">13. Mise à jour de Kitty</a></li> <li><a href="#_références">14. Références</a></li> <li><a href="#_conclusion">15. Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>Ce guide explique pas à pas comment installer le terminal <strong>kitty</strong> sur Xubuntu, le configurer correctement, et remplacer bash par <strong>zsh</strong> comme shell par défaut. Le projet kitty est disponible ici : <a href="https://github.com/kovidgoyal/kitty" class="bare">https://github.com/kovidgoyal/kitty</a>.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Kitty est un terminal moderne, rapide et configurable, particulièrement adapté aux développeurs exigeants.</p> </div> </blockquote> </div> </div> </div> <div class="sect1"> <h2 id="_pourquoi_choisir_kitty_et_zsh">1. Pourquoi choisir Kitty et Zsh ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Kitty se distingue par :</p> </div> <div class="ulist"> <ul> <li> <p>Des performances supérieures grâce à l’accélération GPU,</p> </li> <li> <p>Une configuration entièrement basée sur un fichier texte unique,</p> </li> <li> <p>Une excellente prise en charge des polices et des ligatures.</p> </li> </ul> </div> <div class="paragraph"> <p>Zsh est quant à lui un shell interactif puissant offrant :</p> </div> <div class="ulist"> <ul> <li> <p>Une complétion intelligente,</p> </li> <li> <p>Un prompt personnalisable,</p> </li> <li> <p>Une grande compatibilité avec bash.</p> </li> </ul> </div> <div class="paragraph"> <p>En associant Kitty et Zsh, vous bénéficiez d’un environnement productif et esthétique.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/kitty-zsh-overview.png" alt="kitty zsh overview" width="729" height="305"> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Ce guide est volontairement limité à l’installation via script et à Xubuntu.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="_pré_requis_système">2. Pré-requis système</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant de commencer, assurez-vous d’avoir :</p> </div> <div class="ulist"> <ul> <li> <p>Xubuntu installé,</p> </li> <li> <p>un accès à internet,</p> </li> <li> <p>un shell bash fonctionnel pour lancer le script.</p> </li> </ul> </div> <div class="paragraph"> <p>Vérifiez votre environnement :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">uname -a lsb_release -a</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_téléchargement_et_installation_de_kitty">3. Téléchargement et installation de Kitty</h2> <div class="sectionbody"> <div class="paragraph"> <p>Kitty recommande de l’installer via un script officiel qui place les fichiers dans <code>~/.local/kitty.app</code>.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="Important"></i> </td> <td class="content"> <div class="paragraph"> <p>Cette méthode est indépendante des gestionnaires de paquets (pas de <code>apt</code>).</p> </div> </td> </tr> </table> </div> <div class="sect2"> <h3 id="_télécharger_le_script_dinstallation">3.1. Télécharger le script d’installation</h3> <div class="paragraph"> <p>Exécutez la commande suivante :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin</code></pre> </div> </div> <div class="paragraph"> <p>Cette commande effectue :</p> </div> <div class="ulist"> <ul> <li> <p>téléchargement des binaires,</p> </li> <li> <p>extraction dans <code>~/.local/kitty.app</code>,</p> </li> <li> <p>création des liens symboliques.</p> </li> </ul> </div> <div class="imageblock"> <div class="content"> <img src="./images/download-install.svg" alt="download install" width="353" height="336"> </div> </div> </div> <div class="sect2"> <h3 id="_création_des_liens_symboliques">3.2. Création des liens symboliques</h3> <div class="paragraph"> <p>Afin de pouvoir invoquer <code>kitty</code> depuis le terminal, créez un lien symbolique :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">ln -s ~/.local/kitty.app/bin/kitty ~/.local/bin/kitty</code></pre> </div> </div> <div class="paragraph"> <p>Ajoutez <code>~/.local/bin</code> à votre PATH si ce n’est pas déjà fait :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc source ~/.zshrc</code></pre> </div> </div> <div class="paragraph"> <p>Vous pouvez vérifier l’installation :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">kitty --version</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_intégration_de_kitty_dans_xubuntu">4. Intégration de Kitty dans Xubuntu</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour que Kitty apparaisse dans le menu des applications :</p> </div> <div class="sect2"> <h3 id="_copier_le_fichier_desktop">4.1. Copier le fichier desktop</h3> <div class="paragraph"> <p>Copiez le fichier <code>.desktop</code> fourni :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">cp ~/.local/kitty.app/share/applications/kitty.desktop ~/.local/share/applications/</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_modifier_le_fichier_desktop">4.2. Modifier le fichier desktop</h3> <div class="paragraph"> <p>Editez le fichier :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">nano ~/.local/share/applications/kitty.desktop</code></pre> </div> </div> <div class="paragraph"> <p>Vérifiez ou modifiez les lignes suivantes :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">[Desktop Entry] Version=1.0 Type=Application Name=Kitty Terminal Comment=Fast GPU-based terminal emulator Exec=/home/$USER/.local/kitty.app/bin/kitty Icon=kitty Categories=System;TerminalEmulator;</code></pre> </div> </div> <div class="paragraph"> <p>Remplacez <code>YOURUSER</code> par votre nom d’utilisateur.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/desktop-integration.png" alt="desktop integration" width="479" height="335"> </div> </div> </div> <div class="sect2"> <h3 id="_associer_kitty_comme_terminal_par_défaut_facultatif">4.3. Associer Kitty comme terminal par défaut (facultatif)</h3> <div class="paragraph"> <p>Pour que Kitty soit le terminal lancé par défaut :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator ~/.local/kitty.app/bin/kitty 50 sudo update-alternatives --config x-terminal-emulator</code></pre> </div> </div> <div class="paragraph"> <p>Sélectionnez <code>kitty</code> dans le menu proposé.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_installation_de_zsh">5. Installation de Zsh</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si Zsh n’est pas encore installé, exécutez :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install zsh</code></pre> </div> </div> <div class="paragraph"> <p>Vérifiez l’installation :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">zsh --version</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_définir_zsh_comme_shell_par_défaut">6. Définir Zsh comme shell par défaut</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vous pouvez changer votre shell globalement ou uniquement dans Kitty.</p> </div> <div class="sect2"> <h3 id="_méthode_globale_pour_tous_les_terminaux">6.1. Méthode globale (pour tous les terminaux)</h3> <div class="paragraph"> <p>Identifiez le chemin absolu :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">which zsh</code></pre> </div> </div> <div class="paragraph"> <p>En général <code>/usr/bin/zsh</code>.</p> </div> <div class="paragraph"> <p>Modifiez le shell par défaut :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">chsh -s /usr/bin/zsh</code></pre> </div> </div> <div class="paragraph"> <p>Déconnectez-vous et reconnectez-vous.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/zsh-default-shell.svg" alt="zsh default shell" width="546" height="341"> </div> </div> </div> <div class="sect2"> <h3 id="_méthode_spécifique_à_kitty">6.2. Méthode spécifique à Kitty</h3> <div class="paragraph"> <p>Si vous préférez uniquement changer le shell dans Kitty, éditez le fichier de configuration :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">nano ~/.config/kitty/kitty.conf</code></pre> </div> </div> <div class="paragraph"> <p>Ajoutez cette ligne :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">shell zsh</code></pre> </div> </div> <div class="paragraph"> <p>Enregistrez et redémarrez Kitty.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_de_zsh_optionnel">7. Configuration de Zsh (optionnel)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour personnaliser votre Zsh :</p> </div> <div class="sect2"> <h3 id="_créer_un_fichier_zshrc">7.1. Créer un fichier .zshrc</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">touch ~/.zshrc nano ~/.zshrc</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_exemple_de_configuration_minimale">7.2. Exemple de configuration minimale</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">export ZSH_THEME="robbyrussell" export PATH="$HOME/.local/bin:$PATH" alias ll="ls -la"</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_résumé_du_workflow_complet">8. Résumé du workflow complet</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le schéma ci-dessous récapitule l’ensemble du processus :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/full-workflow.png" alt="full workflow" width="357" height="643"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_vérification_finale">9. Vérification finale</h2> <div class="sectionbody"> <div class="paragraph"> <p>Lancez Kitty :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">kitty</code></pre> </div> </div> <div class="paragraph"> <p>Vous devriez voir que <code>zsh</code> est actif :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">echo $SHELL</code></pre> </div> </div> <div class="paragraph"> <p>Résultat attendu :</p> </div> <div class="listingblock"> <div class="content"> <pre>/usr/bin/zsh</pre> </div> </div> <div class="paragraph"> <p>Pour modifier la taille de la police dans <strong>Kitty</strong>, il faut ajuster le paramètre <code>font_size</code> dans le fichier de configuration. Voici la procédure détaillée :</p> </div> <hr> <div class="sect2"> <h3 id="_ouvrir_le_fichier_de_configuration">9.1. 📂 Ouvrir le fichier de configuration</h3> <div class="paragraph"> <p>Le fichier principal de configuration est habituellement situé dans :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">~/.config/kitty/kitty.conf</code></pre> </div> </div> <div class="paragraph"> <p>Si ce fichier n’existe pas encore, vous pouvez le créer. Exemple :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">nano ~/.config/kitty/kitty.conf</code></pre> </div> </div> <hr> </div> <div class="sect2"> <h3 id="_️_ajouter_ou_modifier_font_size">9.2. 🖋️ Ajouter ou modifier <code>font_size</code></h3> <div class="paragraph"> <p>Ajoutez la directive suivante, ou modifiez-la si elle existe déjà :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">font_size 14.0</code></pre> </div> </div> <div class="paragraph"> <p>Ici <code>14.0</code> correspond à la taille souhaitée. Vous pouvez mettre n’importe quelle valeur décimale, par exemple <code>12.0</code>, <code>15.5</code>, etc.</p> </div> <hr> </div> <div class="sect2"> <h3 id="_enregistrer_et_relancer_kitty">9.3. 💾 Enregistrer et relancer Kitty</h3> <div class="ulist"> <ul> <li> <p>Enregistrez (<code>Ctrl + O</code>, puis <code>Entrée</code>) et quittez (<code>Ctrl + X</code>) si vous utilisez <code>nano</code>.</p> </li> <li> <p>Fermez toutes les fenêtres de Kitty, puis relancez le terminal pour que le changement prenne effet.</p> </li> </ul> </div> <hr> </div> <div class="sect2"> <h3 id="_ajustement_dynamique_zoom_temporaire">9.4. ✅ Ajustement dynamique (Zoom temporaire)</h3> <div class="paragraph"> <p>Si vous souhaitez zoomer/dézoomer temporairement sans modifier la configuration, utilisez les raccourcis clavier par défaut :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Augmenter la taille de la police</strong> : <code>Ctrl + Shift + =</code></p> </li> <li> <p><strong>Diminuer la taille de la police</strong> : <code>Ctrl + Shift + -</code></p> </li> <li> <p><strong>Réinitialiser la taille</strong> : <code>Ctrl + Shift + Backspace</code></p> </li> </ul> </div> <div class="paragraph"> <p>Ces réglages ne persistent pas après la fermeture du terminal.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_installation_et_configuration_de_oh_my_zsh">10. Installation et configuration de Oh My Zsh</h2> <div class="sectionbody"> <div class="paragraph"> <p>Une fois Zsh installé et configuré comme shell par défaut, vous pouvez enrichir votre environnement avec <strong>Oh My Zsh</strong>, un framework de gestion de la configuration Zsh, offrant :</p> </div> <div class="ulist"> <ul> <li> <p>une collection de thèmes pour le prompt,</p> </li> <li> <p>de nombreux plugins,</p> </li> <li> <p>une organisation claire de la configuration.</p> </li> </ul> </div> <div class="sect2"> <h3 id="_installation_de_oh_my_zsh">10.1. Installation de Oh My Zsh</h3> <div class="paragraph"> <p>Assurez-vous que Zsh est actif :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">zsh --version</code></pre> </div> </div> <div class="paragraph"> <p>Si nécessaire, lancez :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">zsh</code></pre> </div> </div> <div class="paragraph"> <p>Puis téléchargez et exécutez le script d’installation officiel :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"</code></pre> </div> </div> <div class="paragraph"> <p>Ce script :</p> </div> <div class="ulist"> <ul> <li> <p>crée le dossier <code>~/.oh-my-zsh</code>,</p> </li> <li> <p>sauvegarde éventuellement votre fichier <code>~/.zshrc</code>,</p> </li> <li> <p>active automatiquement le nouveau prompt.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_changer_le_thème">10.2. Changer le thème</h3> <div class="paragraph"> <p>Ouvrez votre fichier de configuration :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">nano ~/.zshrc</code></pre> </div> </div> <div class="paragraph"> <p>Modifiez la variable <code>ZSH_THEME</code> pour choisir un autre thème (par exemple <code>agnoster</code>) :</p> </div> <div class="listingblock"> <div class="content"> <pre>ZSH_THEME="agnoster"</pre> </div> </div> <div class="paragraph"> <p>Enregistrez puis rechargez la configuration :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">source ~/.zshrc</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_vérification">10.3. Vérification</h3> <div class="paragraph"> <p>Lancez Kitty et vérifiez que le prompt a bien changé. Vous pouvez confirmer qu’Oh My Zsh est actif en exécutant :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">echo $ZSH</code></pre> </div> </div> <div class="paragraph"> <p>Le résultat devrait être similaire à :</p> </div> <div class="listingblock"> <div class="content"> <pre>/home/votre_utilisateur/.oh-my-zsh</pre> </div> </div> </div> <div class="sect2"> <h3 id="_diagramme_du_use_case">10.4. Diagramme du use case</h3> <div class="imageblock"> <div class="content"> <img src="./images/ohmyzsh-installation.png" alt="ohmyzsh installation" width="532" height="480"> </div> </div> <hr> </div> </div> </div> <div class="sect1"> <h2 id="_activer_la_translucidité_dans_kitty">11. Activer la translucidité dans Kitty</h2> <div class="sectionbody"> <div class="paragraph"> <p>Une des fonctionnalités les plus appréciées de Kitty est la possibilité d’ajouter de la <strong>transparence</strong> au fond du terminal. Cela permet de voir légèrement l’environnement sous-jacent (fenêtre, bureau, etc.), ce qui est particulièrement utile en multitâche.</p> </div> <div class="sect2"> <h3 id="_pré_requis_pour_la_transparence">11.1. Pré-requis pour la transparence</h3> <div class="paragraph"> <p>La transparence dans Kitty repose sur le <strong>compositeur de fenêtres</strong> utilisé par l’environnement graphique. Sous Xubuntu (basé sur XFCE), assurez-vous que la <strong>composition est activée</strong>.</p> </div> <div class="ulist"> <div class="title">À vérifier :</div> <ul> <li> <p>clic droit sur le bureau > Paramètres > <strong>Paramètres du gestionnaire de fenêtres</strong>,</p> </li> <li> <p>onglet <strong>Compositeur</strong> : la case <strong>"Activer la composition"</strong> doit être cochée.</p> </li> </ul> </div> <div class="imageblock"> <div class="content"> <img src="./images/transparency-usecase.png" alt="transparency usecase" width="683" height="228"> </div> </div> </div> <div class="sect2"> <h3 id="_configuration_de_la_transparence_dans_kitty_conf">11.2. Configuration de la transparence dans kitty.conf</h3> <div class="paragraph"> <p>Ouvrez votre fichier de configuration <code>~/.config/kitty/kitty.conf</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">nano ~/.config/kitty/kitty.conf</code></pre> </div> </div> <div class="paragraph"> <p>Ajoutez ou modifiez les lignes suivantes :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-conf hljs" data-lang="conf">background_opacity 0.85</code></pre> </div> </div> <div class="paragraph"> <p>Ce paramètre accepte des valeurs entre :</p> </div> <div class="ulist"> <ul> <li> <p><code>1.0</code> → opaque (aucune transparence),</p> </li> <li> <p><code>0.0</code> → complètement transparent (inutilisable),</p> </li> <li> <p>valeurs intermédiaires comme <code>0.90</code>, <code>0.75</code>, etc.</p> </li> </ul> </div> <div class="paragraph"> <p>Un bon compromis visuel est généralement entre <code>0.85</code> et <code>0.95</code>.</p> </div> </div> <div class="sect2"> <h3 id="_redémarrer_kitty">11.3. Redémarrer Kitty</h3> <div class="paragraph"> <p>Fermez toutes les instances de Kitty, puis relancez une nouvelle fenêtre pour que les modifications prennent effet :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">kitty</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_compléments_possibles">11.4. Compléments possibles</h3> <div class="paragraph"> <p>Si vous utilisez un fond de terminal personnalisé, vous pouvez également définir une couleur de fond avec transparence (en RGBA) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-conf hljs" data-lang="conf">background #1e1e2eff</code></pre> </div> </div> <div class="paragraph"> <p>La dernière composante (<code>ff</code>) indique l’opacité (de <code>00</code> à <code>ff</code>).</p> </div> </div> <div class="sect2"> <h3 id="_diagramme_de_séquence_initialisation_de_kitty_avec_transparence">11.5. Diagramme de séquence - Initialisation de Kitty avec transparence</h3> <div class="imageblock"> <div class="content"> <img src="./images/transparency-sequence.png" alt="transparency sequence" width="775" height="422"> </div> </div> </div> <div class="sect2"> <h3 id="_limitations_connues">11.6. Limitations connues</h3> <div class="admonitionblock warning"> <table> <tr> <td class="icon"> <i class="fa icon-warning" title="Warning"></i> </td> <td class="content"> <div class="paragraph"> <p>La translucidité ne fonctionne pas si :</p> </div> <div class="ulist"> <ul> <li> <p>le compositeur XFCE est désactivé,</p> </li> <li> <p>un gestionnaire de fenêtres incompatible est utilisé,</p> </li> <li> <p>vous utilisez Kitty dans un mode <strong>tmux</strong> en arrière-plan sans support de transparence.</p> </li> </ul> </div> </td> </tr> </table> </div> <hr> </div> </div> </div> <div class="sect1"> <h2 id="_désactiver_le_bip_sonore_audible_bell">12. Désactiver le bip sonore (audible bell)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Par défaut, Kitty émet un son de <strong>bip</strong> lorsqu’une commande erronée est saisie ou qu’un événement terminal le déclenche. Ce bruit peut rapidement devenir gênant, surtout dans un environnement de développement intensif.</p> </div> <div class="paragraph"> <p>Pour désactiver ce comportement, ajoutez la directive suivante au fichier <code>~/.config/kitty/kitty.conf</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-conf hljs" data-lang="conf">audible_bell no</code></pre> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Vous pouvez également activer un <strong>retour visuel</strong> en remplacement du bip sonore avec :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-conf hljs" data-lang="conf">visual_bell yes</code></pre> </div> </div> </td> </tr> </table> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_mise_à_jour_de_kitty">13. Mise à jour de Kitty</h2> <div class="sectionbody"> <div class="paragraph"> <p>Puisque Kitty est installé via un script et non un gestionnaire de paquets, la mise à jour se fait en relançant le script d’installation officiel. Cela permet de télécharger la dernière version et de mettre à jour votre installation existante dans <code>~/.local/kitty.app</code>.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Le suffixe <code>.app</code> dans le chemin <code>~/.local/kitty.app</code> est la convention d’installation de Kitty sur Linux via son script officiel, et n’indique en aucun cas une compatibilité exclusive avec macOS.</p> </div> </td> </tr> </table> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="Important"></i> </td> <td class="content"> <div class="paragraph"> <p>Avant de lancer la commande de mise à jour, assurez-vous d’être dans votre répertoire personnel (<code>~</code>).</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>Exécutez la commande suivante depuis votre répertoire personnel :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin</code></pre> </div> </div> <div class="paragraph"> <p>Ce script se chargera de :</p> </div> <div class="ulist"> <ul> <li> <p>Télécharger les binaires de la nouvelle version.</p> </li> <li> <p>Extraire les fichiers dans <code>~/.local/kitty.app</code>.</p> </li> <li> <p>Mettre à jour les liens symboliques si nécessaire.</p> </li> </ul> </div> <div class="paragraph"> <p>Après la mise à jour, il est recommandé de fermer toutes les instances de Kitty et de les relancer pour s’assurer que la nouvelle version est bien prise en compte.</p> </div> </div> </div> <div class="sect1"> <h2 id="_références">14. Références</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si vous souhaitez approfondir la personnalisation, consultez la documentation officielle :</p> </div> <div class="ulist"> <ul> <li> <p>Kitty : <a href="https://sw.kovidgoyal.net/kitty/" class="bare">https://sw.kovidgoyal.net/kitty/</a></p> <div class="ulist"> <ul> <li> <p><a href="https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.background_opacity" class="bare">https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.background_opacity</a></p> </li> <li> <p><a href="https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.audible_bell" class="bare">https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.audible_bell</a></p> </li> </ul> </div> </li> <li> <p>Zsh : <a href="https://zsh.sourceforge.io/" class="bare">https://zsh.sourceforge.io/</a></p> </li> <li> <p>Github: <a href="https://github.com/kovidgoyal/kitty" class="bare">https://github.com/kovidgoyal/kitty</a></p> </li> <li> <p>Zsh: <a href="https://zsh.sourceforge.io/" class="bare">https://zsh.sourceforge.io/</a></p> <div class="ulist"> <ul> <li> <p><a href="https://ohmyz.sh/" class="bare">https://ohmyz.sh/</a></p> </li> <li> <p><a href="https://github.com/ohmyzsh/ohmyzsh/wiki" class="bare">https://github.com/ohmyzsh/ohmyzsh/wiki</a></p> </li> </ul> </div> </li> <li> <p><a href="https://docs.xfce.org/xfce/xfwm4/compositor" class="bare">https://docs.xfce.org/xfce/xfwm4/compositor</a></p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">15. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vous disposez maintenant :</p> </div> <div class="ulist"> <ul> <li> <p>d’un terminal moderne et performant (Kitty)</p> </li> <li> <p>d’un shell puissant et personnalisable (Zsh)</p> </li> <li> <p>d’une configuration propre et indépendante des paquets systèmes</p> </li> <li> <p>d’un terminal esthétique et fonctionnel équipé de Oh My Zsh</p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0119_benchmark_dgx_spark_vs_cloud_abonnement_llm_post.html Wed, 6 May 2026 00:00:00 +0000 blog/2026/0119_benchmark_dgx_spark_vs_cloud_abonnement_llm_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_contexte_un_marché_qui_a_basculé">1. Le Contexte : Un Marché Qui a Basculé</a></li> <li><a href="#le_panel_des_options">2. Le Panel des Options</a> <ul class="sectlevel2"> <li><a href="#ce_que_jai_exclu_et_pourquoi">2.1. Ce Que J’ai Exclu (et Pourquoi)</a></li> </ul> </li> <li><a href="#inférence_simple_la_mort_du_hardware_local">3. Inférence Simple : La Mort du Hardware Local</a> <ul class="sectlevel2"> <li><a href="#le_calcul">3.1. Le Calcul</a></li> <li><a href="#même_avec_un_usage_intensif">3.2. Même avec un Usage Intensif</a></li> </ul> </li> <li><a href="#fine_tuning_le_cloud_est_imbattable">4. Fine-Tuning : Le Cloud Est Imbattable</a> <ul class="sectlevel2"> <li><a href="#le_coût_réel_dun_fine_tune">4.1. Le Coût Réel d’un Fine-Tune</a></li> <li><a href="#les_acteurs_spécialisés">4.2. Les Acteurs Spécialisés</a></li> </ul> </li> <li><a href="#la_seule_vraie_raison_la_souveraineté_des_données">5. La Seule Vraie Raison : La Souveraineté des Données</a> <ul class="sectlevel2"> <li><a href="#le_vrai_calcul_de_la_confidentialité">5.1. Le Vrai Calcul de la Confidentialité</a></li> </ul> </li> <li><a href="#synthèse_la_matrice_de_décision">6. Synthèse : La Matrice de Décision</a></li> <li><a href="#le_cas_particulier_labonnement_pro_face_aux_modèles_chinois">7. Le Cas Particulier : L’Abonnement Pro Face aux Modèles Chinois</a> <ul class="sectlevel2"> <li><a href="#pourquoi_les_modèles_chinois_changent_tout">7.1. Pourquoi les Modèles Chinois Changent Tout</a></li> <li><a href="#ce_que_ça_veut_dire_pour_le_hardware">7.2. Ce Que Ça Veut Dire pour le Hardware</a></li> </ul> </li> <li><a href="#et_huawei">8. Et Huawei ?</a></li> <li><a href="#conclusion_le_luxe_de_la_proximité">9. Conclusion : Le Luxe de la Proximité</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 14 minutes</div> <p>NVIDIA vend le DGX Spark comme un « supercalculateur IA de bureau » à $4 699. Ollama propose ses modèles cloud à $20/mois. Un H100 se loue $1.38/h chez Vast.ai. Et les modèles chinois open-source — DeepSeek, Qwen, GLM — sont disponibles partout, gratuitement, sans avoir à acheter une carte. Alors, ce Spark, il sert à quoi au juste ? J’ai fait les maths.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="le_contexte_un_marché_qui_a_basculé">1. Le Contexte : Un Marché Qui a Basculé</h2> <div class="sectionbody"> <div class="paragraph"> <p>En mai 2026, le paysage de l’IA a radicalement changé par rapport à l’annonce du DGX Spark au CES 2025. Trois forces ont convergé pour rendre le hardware local de plus en plus difficile à justifier :</p> </div> <div class="ulist"> <ul> <li> <p><strong>L’effondrement des prix du cloud GPU</strong> : un H100 se loue entre $1.38 et $3/h, contre $5-8/h il y a 18 mois</p> </li> <li> <p><strong>L’explosion des modèles chinois open-source</strong> : DeepSeek-V4, Qwen-3, GLM-5 sont compétitifs avec les modèles occidentaux, disponibles gratuitement</p> </li> <li> <p><strong>La montée des plateformes d’inférence managée</strong> : Ollama, Groq, Together AI proposent des API à des tarifs agressifs, avec des paliers gratuits généreux</p> </li> </ul> </div> <div class="paragraph"> <p>Le DGX Spark, annoncé à $2 999 puis monté à $4 699, arrive dans un monde qui n’a plus besoin de lui.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_panel_des_options">2. Le Panel des Options</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici les solutions disponibles en mai 2026 pour faire tourner des LLMs, de la plus légère à la plus lourde :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 11.1111%;"> <col style="width: 22.2222%;"> <col style="width: 22.2222%;"> <col style="width: 22.2222%;"> <col style="width: 22.2223%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Option</th> <th class="tableblock halign-left valign-top">Coût</th> <th class="tableblock halign-left valign-top">VRAM / Capacité</th> <th class="tableblock halign-left valign-top">Modèles accessibles</th> <th class="tableblock halign-left valign-top">Contrainte principale</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Ollama Free</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$0/mois</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Cloud léger</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles publics</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Usage limité, 1 modèle simultané</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Claude Pro</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$20/mois (~$240/an)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N/A (API fermée)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Claude 4.x uniquement</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Modèle unique, pas d’open-source</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Ollama Pro</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$20/mois (~$200/an)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Cloud medium</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles publics</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3 modèles simultanés max</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Ollama Max</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$100/mois (~$1 200/an)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Cloud heavy</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles publics</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">10 modèles simultanés</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Cloud GPU (H100)</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$1.38-3/h</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">80 Go HBM</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles, fine-tuning</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Facturation horaire, setup requis</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>DGX Spark</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$4 699 (achat)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">128 Go unifié</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles <128 Go</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Lent (~10x moins qu’un H100), fixe</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Mac Studio M3 Ultra</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~$5 000+</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">192 Go unifié</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles <192 Go</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pas CUDA, écosystème MLX</p></td> </tr> </tbody> </table> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> <div class="paragraph"> <p>Les prix cloud GPU cités sont ceux de Vast.ai et RunPod en mai 2026 — du spot/on-demand, pas du réservé. Les prix des hyperscalers (AWS, GCP, Azure) restent 2-3x plus élevés.</p> </div> </td> </tr> </table> </div> <div class="sect2"> <h3 id="ce_que_jai_exclu_et_pourquoi">2.1. Ce Que J’ai Exclu (et Pourquoi)</h3> <div class="paragraph"> <p>J’ai volontairement exclu les options suivantes de ce benchmark :</p> </div> <div class="ulist"> <ul> <li> <p><strong>API OpenAI / Anthropic / Google</strong> : le sujet ici est de faire tourner des modèles <strong>open-source</strong> qu’on peut choisir, fine-tuner, et ne pas être dépendant d’un vendor unique</p> </li> <li> <p><strong>Huawei Ascend / Atlas</strong> : Huawei ne commercialise pas d’équivalent desktop au DGX Spark. La gamme Ascend (910C, 910D) et Atlas (300I Duo, 350) est orientée datacenter — cartes PCIe, serveurs rack — pas des boîtiers compacts prêts à brancher. La puce Ascend 910C embarque 128 Go HBM mais c’est une puce serveur, pas un système autonome. L’Atlas 300I Duo offre 96 Go pour ~$1 400 mais nécessite une machine hôte</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="inférence_simple_la_mort_du_hardware_local">3. Inférence Simple : La Mort du Hardware Local</h2> <div class="sectionbody"> <div class="paragraph"> <p>Commençons par le cas d’usage le plus commun : chatter avec un LLM, faire du code review, générer du texte. Pas de fine-tuning, pas de batch processing, juste de l’inférence interactive.</p> </div> <div class="sect2"> <h3 id="le_calcul">3.1. Le Calcul</h3> <div class="paragraph"> <p>Un DGX Spark à $4 699. Divisons par le coût annuel de chaque abonnement :</p> </div> <div id="diag-breakeven" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-7447dcff18600cfcdb05c5212204ea1f.svg" alt="Seuil de rentabilité du DGX Spark vs abonnements" width="837" height="219"> </div> </div> <div class="paragraph"> <p>Le verdict est brutal. Pour de l’inférence :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Ollama Pro</strong> : il vous faudrait <strong>23 ans</strong> pour amortir un DGX Spark. Le Spark sera obsolète depuis 20 ans.</p> </li> <li> <p><strong>Ollama Max</strong> : <strong>4 ans</strong> — à condition d’utiliser le Spark 24/7, ce que personne ne fait</p> </li> <li> <p><strong>Claude Pro</strong> : même problème, <strong>20 ans</strong> pour du single-model fermé</p> </li> </ul> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>La promesse du « supercalculateur IA de bureau » se heurte à une réalité comptable élémentaire : $4 699 / $20 par mois = jamais rentable pour un usage individuel.</p> </div> </blockquote> </div> </div> <div class="sect2"> <h3 id="même_avec_un_usage_intensif">3.2. Même avec un Usage Intensif</h3> <div class="paragraph"> <p>Prenons le pire scénario pour le cloud : vous faites tourner un H100 8h/jour, 5 jours/semaine, 52 semaines/an.</p> </div> <div class="ulist"> <ul> <li> <p>8 × 5 × 52 = 2 080 heures/an</p> </li> <li> <p>2 080 × $2/h (prix moyen spot H100) = <strong>$4 160/an</strong></p> </li> </ul> </div> <div class="paragraph"> <p>Le Spark ($4 699) est rentabilisé en <strong>13 mois</strong>. Sauf que :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Le H100 est <strong>~10x plus rapide</strong> que le GB10 du Spark. Vous faites en 1h ce que le Spark fait en 10h. Pour le même volume de travail, le H100 vous coûte $416/an, pas $4 160.</p> </li> <li> <p>Le H100 a 80 Go HBM à 3.35 To/s de bande passante. Le Spark a 128 Go LPDDR5X à 273 Go/s. Pour les gros modèles, la bande passante compte plus que la capacité.</p> </li> </ol> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Comparer 1h de H100 à 1h de Spark n’a pas de sens. Le H100 fait le travail 10x plus vite. Le vrai coût cloud pour un workload donné est donc ~10x inférieur au calcul naïf basé sur les heures.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="fine_tuning_le_cloud_est_imbattable">4. Fine-Tuning : Le Cloud Est Imbattable</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’argument classique des défenseurs du Spark : « oui mais pour le fine-tuning, c’est différent ».</p> </div> <div class="paragraph"> <p>Non, ça ne l’est pas.</p> </div> <div class="sect2"> <h3 id="le_coût_réel_dun_fine_tune">4.1. Le Coût Réel d’un Fine-Tune</h3> <div class="paragraph"> <p>Un fine-tune LoRA/QLoRA sur Unsloth d’un modèle 7B :</p> </div> <div class="ulist"> <ul> <li> <p>~2-3h sur un H100 = <strong>$5 à $9</strong></p> </li> <li> <p>Même chose sur le Spark = <strong>20-30h</strong> (10x plus lent), bloque la machine</p> </li> </ul> </div> <div class="paragraph"> <p>Avec les $4 699 du Spark, vous pouvez financer :</p> </div> <div class="ulist"> <ul> <li> <p><strong>~500 à ~900 fine-tunes</strong> en cloud H100</p> </li> <li> <p>Ou <strong>~23 ans</strong> d’Ollama Pro</p> </li> <li> <p>Ou <strong>~4 ans</strong> d’Ollama Max</p> </li> </ul> </div> <div class="paragraph"> <p>Et pour des modèles plus gros (70B+) :</p> </div> <div class="ulist"> <ul> <li> <p>Le Spark avec ses 128 Go peut charger un 70B en Q4 — mais le fine-tune sera extrêmement lent</p> </li> <li> <p>Un H100 avec 80 Go peut fine-tuner un 70B en QLoRA 4-bit en quelques heures</p> </li> <li> <p>Pour du full fine-tune, il faut du multi-GPU de toute façon — le Spark est hors course</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="les_acteurs_spécialisés">4.2. Les Acteurs Spécialisés</h3> <div class="paragraph"> <p>En 2026, des plateformes comme Unsloth, Modal, Replicate, et Together AI proposent du fine-tuning serverless :</p> </div> <div class="ulist"> <ul> <li> <p>Pas de gestion de GPU</p> </li> <li> <p>Pas de configuration d’environnement</p> </li> <li> <p>Paiement à la minute</p> </li> <li> <p>Optimisations intégrées (flash attention, quantization automatique)</p> </li> </ul> </div> <div id="diag-fine-tuning-cost" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-00c27fa5b17d5b1836d28ea44e7aa323.svg" alt="Comparaison des coûts de fine-tuning" width="626" height="244"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_seule_vraie_raison_la_souveraineté_des_données">5. La Seule Vraie Raison : La Souveraineté des Données</h2> <div class="sectionbody"> <div class="paragraph"> <p>Après avoir éliminé l’inférence, le fine-tuning, et le rapport qualité/prix — que reste-t-il au Spark ?</p> </div> <div class="paragraph"> <p><strong>La confidentialité absolue.</strong></p> </div> <div class="paragraph"> <p>Pas la confidentialité « je ne veux pas que mes prompts soient lus par un employé d’OpenAI ». Ça, c’est un faux problème en 2026 : Ollama, Groq, et la plupart des providers respectables ont des politiques de zéro log et zéro rétention.</p> </div> <div class="paragraph"> <p>La vraie confidentialité, c’est :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Air-gap réglementaire</strong> : défense, diplomatie, santé — les données ne peuvent <strong>physiquement</strong> pas quitter le bâtiment</p> </li> <li> <p><strong>Données propriétaires critiques</strong> : code source d’un produit non publié, secrets industriels, algorithmes de trading</p> </li> <li> <p><strong>Résilience réseau</strong> : l’IA doit continuer à fonctionner même si Internet tombe</p> </li> </ul> </div> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> <div class="paragraph"> <p>Mais soyons honnêtes : quel pourcentage des acheteurs de DGX Spark est réellement dans ce cas ? 1% ? Le reste, c’est du « nice to have » transformé en dépense à $4 699.</p> </div> </td> </tr> </table> </div> <div class="sect2"> <h3 id="le_vrai_calcul_de_la_confidentialité">5.1. Le Vrai Calcul de la Confidentialité</h3> <div class="paragraph"> <p>Pour un usage individuel :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Ollama Pro</strong> ($20/mois) + modèles open source chinois = solution pragmatique</p> </li> <li> <p>Si un prompt fuit chez Ollama, il se noie dans les millions de requêtes quotidiennes. C’est la goutte d’eau dans l’océan.</p> </li> <li> <p>Le risque réel n’est pas la fuite d’un prompt — c’est l’entraînement non consenti sur vos données. Et ça, les providers sérieux l’interdisent contractuellement.</p> </li> </ul> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>La peur de « distiller son prompt dans le LLM » est un niveau de propagation d’information personnel tellement dilué qu’il relève plus de l’anxiété que de la menace réelle. À l’échelle industrielle, c’est différent. Mais à l’échelle individuelle, c’est du bruit.</p> </div> </blockquote> </div> </div> </div> </div> <div class="sect1"> <h2 id="synthèse_la_matrice_de_décision">6. Synthèse : La Matrice de Décision</h2> <div class="sectionbody"> <div id="diag-decision-matrix" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-06638fe7c7dbec3c1cf02043ac672e9a.svg" alt="Matrice de décision pour choisir sa solution LLM" width="2012" height="433"> </div> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 20%;"> <col style="width: 20%;"> <col style="width: 20%;"> <col style="width: 20%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Critère</th> <th class="tableblock halign-left valign-top">Ollama Free</th> <th class="tableblock halign-left valign-top">Ollama Pro</th> <th class="tableblock halign-left valign-top">Cloud GPU H100</th> <th class="tableblock halign-left valign-top">DGX Spark</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Inférence</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Limitée</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Confortable</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Overkill</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">⚠️ Lent</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Fine-tuning</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Imbattable</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">⚠️ Possible mais lent</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Coût annuel</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$0</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$200</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Variable (~$416-2 080*)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">$4 699 upfront</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Confidentialité</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">⚠️ Cloud US</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">⚠️ Cloud US</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">⚠️ Cloud US (variable)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Totale</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Maintenance</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucune</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucune</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Setup unique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Électricité, mises à jour</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Obsolescence</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucune</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucune</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucune</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3-5 ans</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Écosystème logiciel</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles open</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles open</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous modèles open</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">CUDA (mais lent)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Veridict</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Occasionnel</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Recommandé</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pros/Recherche</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Air-gap uniquement</p></td> </tr> </tbody> </table> <div class="paragraph"> <p><em>*Variable selon volume de travail ; avec vitesse H100 ~10x > Spark, le coût effectif pour un workload donné est bas.</em></p> </div> </div> </div> <div class="sect1"> <h2 id="le_cas_particulier_labonnement_pro_face_aux_modèles_chinois">7. Le Cas Particulier : L’Abonnement Pro Face aux Modèles Chinois</h2> <div class="sectionbody"> <div class="paragraph"> <p>Un point mérite d’être souligné : la combinaison <strong>Ollama Pro à $20/mois + modèles chinois open-source</strong> est probablement le meilleur rapport qualité/prix de l’histoire de l’IA grand public.</p> </div> <div class="sect2"> <h3 id="pourquoi_les_modèles_chinois_changent_tout">7.1. Pourquoi les Modèles Chinois Changent Tout</h3> <div class="ulist"> <ul> <li> <p><strong>DeepSeek-V4-Pro</strong> : 1.6T params, CSA+HCA, 1M contexte, compétitif avec Claude 4 et GPT-5 pour le code</p> </li> <li> <p><strong>Qwen-3</strong> : 235B, 256K contexte, excellent en français et en raisonnement</p> </li> <li> <p><strong>GLM-5.1</strong> : 744B, MLA+DSA, 200K contexte, taillé pour l’agentique</p> </li> </ul> </div> <div class="paragraph"> <p>Tous disponibles sur Ollama. Tous open-source (licences permissives). Tous utilisables sans restriction via un abonnement à $20/mois.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> <div class="paragraph"> <p>Avec Ollama Pro, vous avez accès à ~5 modèles « frontier » open-source pour le prix d’un seul modèle fermé (Claude Pro). La valeur est tellement asymétrique que ça en devient presque absurde.</p> </div> </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="ce_que_ça_veut_dire_pour_le_hardware">7.2. Ce Que Ça Veut Dire pour le Hardware</h3> <div class="paragraph"> <p>Si le meilleur rapport qualité/prix est un abonnement cloud à $20/mois, le hardware local devient un choix de <strong>confort</strong> ou de <strong>principe</strong> — pas un choix économique.</p> </div> <div class="paragraph"> <p>Un DGX Spark à $4 699, c’est l’équivalent de :</p> </div> <div class="ulist"> <ul> <li> <p>235 mois d’Ollama Pro</p> </li> <li> <p>23 jeux AAA jour de sortie</p> </li> <li> <p>4 MacBook Air M4</p> </li> <li> <p>Un an de loyer d’un T2 à Lyon</p> </li> </ul> </div> <div class="paragraph"> <p>Pour du calcul. Lent.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="et_huawei">8. Et Huawei ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Puisque la question m’a été posée pendant mes recherches : non, Huawei ne commercialise pas d’équivalent au DGX Spark.</p> </div> <div class="paragraph"> <p>Ce qui existe :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Ascend 910C</strong> : 128 Go HBM, 800 TFLOPS FP16 — mais c’est une puce serveur, pas un desktop</p> </li> <li> <p><strong>Atlas 300I Duo</strong> : 96 Go LPDDR4X, carte PCIe à ~$1 400 — nécessite un hôte</p> </li> <li> <p><strong>Atlas 350</strong> : 112 Go HBM, 1.56 PFLOPS FP4 — accélérateur datacenter, pas un boîtier compact</p> </li> </ul> </div> <div class="paragraph"> <p>Huawei reste focalisé sur le marché des serveurs et des centres de données. Pour un boîtier compact « prêt à brancher » avec 120+ Go de VRAM, le DGX Spark (128 Go unifié) et le Mac Studio M3 Ultra (192 Go unifié) sont les seules options en 2026. Et pour l’instant, aucun constructeur chinois n’a annoncé de produit équivalent dans ce format.</p> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_le_luxe_de_la_proximité">9. Conclusion : Le Luxe de la Proximité</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le DGX Spark n’est pas un mauvais produit. C’est un mauvais investissement pour 99% des acheteurs potentiels.</p> </div> <div id="diag-verdict" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-e8d62f731ea78fcb4f2978a3515b59c2.svg" alt="Verdict final — quel modèle économique domine en 2026" width="476" height="617"> </div> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Acheter un DGX Spark en 2026, c’est comme acheter un serveur mail en 2010 : techniquement possible, philosophiquement satisfaisant, économiquement absurde pour un individu.</p> </div> </blockquote> </div> <div class="paragraph"> <p>Le calcul est simple, et il ne ment pas :</p> </div> <div class="ulist"> <ul> <li> <p><strong>$0</strong> pour chatter avec DeepSeek sur Ollama Free</p> </li> <li> <p><strong>$200/an</strong> pour bosser sérieusement avec Ollama Pro</p> </li> <li> <p><strong>$5-9</strong> pour un fine-tune ponctuel sur cloud GPU</p> </li> <li> <p><strong>$4 699</strong> pour…​ l’expérience d’avoir un boîtier NVIDIA sur son bureau ?</p> </li> </ul> </div> <div class="paragraph"> <p>Le marché a tranché. Les abonnements cloud et les modèles open-source chinois ont gagné la bataille du prix. Le hardware local survit dans les niches réglementaires, pas dans les bureaux des développeurs.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Le DGX Spark n’est pas un outil rentable. C’est un statement. « Je veux mon IA chez moi, pas dans le cloud de quelqu’un d’autre. » C’est respectable. Mais en 2026, quand Ollama te donne DeepSeek-V4-Pro dans le cloud pour $20/mois, c’est surtout un statement qui coûte très cher.</p> </div> </blockquote> </div> <hr> <div class="paragraph"> <p><strong>Cet article est issu d’une conversation avec mon agent IA sur la pertinence économique du DGX Spark, croisée avec une veille marché sur les prix cloud GPU (Vast.ai, RunPod), les grilles tarifaires Ollama/Claude, et l’écosystème des modèles chinois open-source. Les prix cités sont ceux de mai 2026 — ils auront probablement encore baissé quand vous lirez ces lignes.</strong></p> </div> </div> </div> https://pages-content.github.io//blog/2026/0118_matrice_gouvernance_llm_zone_acces_workspace_post.html Mon, 4 May 2026 00:00:00 +0000 blog/2026/0118_matrice_gouvernance_llm_zone_acces_workspace_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_problème_le_prompt_engineering_est_un_château_de_sable">1. Le Problème : le Prompt Engineering est un Château de Sable</a></li> <li><a href="#ma_réponse_la_matrice_44">2. Ma Réponse : la Matrice 4×4</a> <ul class="sectlevel2"> <li><a href="#les_cinq_zones_dimension_spatiale_rgpd">2.1. Les Cinq Zones (Dimension Spatiale — RGPD)</a></li> <li><a href="#la_classification_épistémique_deuxième_dimension">2.2. La Classification Épistémique (Deuxième Dimension)</a></li> </ul> </li> <li><a href="#comment_le_llm_consomme_cette_matrice">3. Comment le LLM Consomme Cette Matrice</a></li> <li><a href="#implémentation_tâches_gradle_typées">4. Implémentation : Tâches Gradle Typées</a></li> <li><a href="#pourquoi_cest_un_manifeste_pas_juste_une_spec">5. Pourquoi C’est un Manifeste, Pas Juste une Spec</a></li> <li><a href="#la_cascade_complète_du_brain_dump_à_larticle_de_blog">6. La Cascade Complète — du Brain Dump à l’Article de Blog</a></li> <li><a href="#procontra">7. Pro/Contra</a></li> <li><a href="#conclusion_rangez_vos_fichiers_pas_vos_prompts">8. Conclusion : Rangez vos Fichiers, Pas vos Prompts</a></li> <li><a href="#références">9. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 14 minutes</div> <p>Pendant des mois, j’ai empilé les règles de gouvernance agent. Des fichiers EAGER, des checklists LAZY, des protocoles de fin de session en six étapes. Et pourtant, une question restait en suspens : <strong>comment le LLM sait-il ce qu’il a le droit de faire avec un fichier ?</strong></p> </div> <div class="paragraph"> <p>La réponse n’est pas dans un prompt. Elle est dans le système de fichiers.</p> </div> <div class="paragraph"> <p>Voici la spécification d’architecture qui rend la réponse exploitable — la <strong>matrice de gouvernance LLM</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_problème_le_prompt_engineering_est_un_château_de_sable">1. Le Problème : le Prompt Engineering est un Château de Sable</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quand on donne un fichier à un LLM, on lui donne tout. Le contenu, oui — mais aussi l’absence de garde-fous. Le LLM ne sait pas si ce fichier contient un secret, une opinion spéculative, ou du code closed source. Il va l’indexer, le résumer, le citer, le mélanger avec d’autres données — et potentiellement le publier dans un embedding public ou une réponse utilisateur.</p> </div> <div class="paragraph"> <p>La parade classique, c’est le prompt :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">"Tu es un assistant sécurisé. Ne divulgue jamais d'informations confidentielles. Si tu détectes un secret, ignore-le. Si tu détectes une opinion, ne la répète pas."</code></pre> </div> </div> <div class="paragraph"> <p>Ce prompt a trois problèmes :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Il repose sur la bonne volonté du LLM.</strong> Un modèle assez grand pour résoudre des bugs complexes est assez grand pour contourner une instruction de sécurité noyée dans 200k tokens de contexte.</p> </li> <li> <p><strong>Il est contextuel, pas structurel.</strong> Changez de prompt, changez de LLM, changez de session — et la règle disparaît.</p> </li> <li> <p><strong>Il ne scale pas.</strong> Chaque nouveau type de fichier, chaque nouveau niveau de confidentialité exige une nouvelle clause. Votre prompt devient un texte réglementaire que personne ne lit en entier.</p> </li> </ol> </div> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> <div class="paragraph"> <p>La sécurité d’un système ne doit jamais dépendre d’une instruction qu’on peut oublier, contourner, ou ne pas charger. Elle doit dépendre d’une barrière qu’on ne peut pas franchir sans le vouloir explicitement.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="ma_réponse_la_matrice_44">2. Ma Réponse : la Matrice 4×4</h2> <div class="sectionbody"> <div class="paragraph"> <p>La solution que j’ai implémentée dans mon workspace est une <strong>matrice zone × droit d’accès LLM</strong>. Elle ne demande pas au LLM d’être prudent. Elle rend l’imprudence structurellement impossible.</p> </div> <div id="diag-matrix-overview" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-ff423528a76bb0bbfad06b9abbd23331.svg" alt="Vue d’ensemble de la matrice de gouvernance LLM — 5 zones × 4 droits d’accès" width="469" height="800"> </div> </div> <div class="sect2"> <h3 id="les_cinq_zones_dimension_spatiale_rgpd">2.1. Les Cinq Zones (Dimension Spatiale — RGPD)</h3> <div class="paragraph"> <p>Chaque zone du workspace a un niveau RGPD qui détermine <strong>où</strong> le fichier peut être routé :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 14.2857%;"> <col style="width: 14.2857%;"> <col style="width: 28.5714%;"> <col style="width: 42.8572%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Zone</th> <th class="tableblock halign-left valign-top">Niveau RGPD</th> <th class="tableblock halign-left valign-top">Contenu</th> <th class="tableblock halign-left valign-top">Droit d’accès RAG public</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Racine</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">0 — Intime</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Brain dumps, conversations LLM</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>INTERDIT</strong> — jamais indexé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>configuration/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1 — Restreint propriétaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Secrets, tokens, clés API</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>INTERDIT</strong> — jamais indexé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>office/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2 — Restreint collaboratif</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Data éditoriale, cadrage, formations</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>FILTRÉ</strong> — Vision uniquement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>foundry/private/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3 — Ouvert conditionnel</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Code closed source, SaaS non public</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>INTERDIT</strong> — dataset privé exclusivement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>foundry/public/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4 — Public natif</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Code Apache 2.0, plugins publiés</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>LIBRE</strong> — indexation complète</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>La règle est simple : <strong>le chemin du fichier détermine ce que le LLM peut en faire.</strong> Pas de métadonnées à maintenir, pas de tag à ajouter dans le frontmatter, pas de classification manuelle à chaque commit. Le fichier est dans <code>OSS/</code> ? Il est public. Il est dans <code>configuration/</code> ? Il est intouchable.</p> </div> </div> <div class="sect2"> <h3 id="la_classification_épistémique_deuxième_dimension">2.2. La Classification Épistémique (Deuxième Dimension)</h3> <div class="paragraph"> <p>La dimension spatiale dit <strong>où</strong> router. Mais il y a un deuxième axe, perpendiculaire : <strong>quoi</strong> router. Certains fichiers dans une zone autorisée contiennent des informations qui ne devraient pas être diluées telles quelles :</p> </div> <div id="diag-epistemic-filter" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-768538851f5f36f6e05c445dd02dc3ed.svg" alt="Filtre épistémique Vision/Opinion/Stratégie appliqué aux zones 2 et 3" width="1215" height="558"> </div> </div> <div class="paragraph"> <p>La grille de classification épistémique, gravée en Règle 2bis de ma gouvernance agent :</p> </div> <div class="paragraph"> <p>| Statut | Définition | Signal LLM | Destination | | VISION | Architecture stabilisée, pattern testé | Langage déclaratif, références sessions/tests | Dilution complète + Blog | | STRATÉGIE | Positionnement business, pricing | Vocabulaire marché, concurrence | Docs racine uniquement | | OPINION | Spéculation, hypothèse non validée | Langage hypothétique, intuition | Confinement Cercle 0 |</p> </div> <div class="paragraph"> <p>La combinaison des deux dimensions — zone physique × classification épistémique — forme la <strong>matrice complète</strong> :</p> </div> <div id="diag-full-matrix" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-f6f9959b0f07e3bff0bf64c8e1c20ea4.svg" alt="La matrice complète : 5 zones × 3 classifications épistémiques" width="442" height="132"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="comment_le_llm_consomme_cette_matrice">3. Comment le LLM Consomme Cette Matrice</h2> <div class="sectionbody"> <div class="paragraph"> <p>La matrice n’est pas un document que le LLM lit. C’est une <strong>contrainte implicite</strong> encodée dans le vecteur composite de contexte (EPIC 9 — en cours d’implémentation).</p> </div> <div class="paragraph"> <p>Voici ce que le LLM reçoit à chaque session :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">VECTEUR COMPOSITE DE CONTEXTE ├── RAG pgvector → OSS/ + office/Vision │ (similarité sémantique sur contenu publiable) ├── Knowledge Graph graphify → OSS/ │ (relations exactes entre artéfacts publics) ├── Knowledge Graph privé → CSS/ │ (relations entre code closed source — jamais exporté) ├── Métadonnées de zone → chaque fichier taggé par zone physique │ (le LLM sait s'il est dans office/ ou OSS/) └── Historique des décisions → WORKSPACE_VISION.adoc (contexte temporel des arbitrages)</code></pre> </div> </div> <div class="paragraph"> <p>Concrètement, quand le LLM me dit :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">Je vais indexer le contenu de edster/ pour enrichir le knowledge graph...</code></pre> </div> </div> <div class="paragraph"> <p>La métadonnée de zone répond avant même que le LLM ne finisse sa phrase : <code>edster/</code> est dans <code>CSS/</code>, niveau 3 → <strong>accès interdit au knowledge graph public.</strong> Le RAG ne le voit pas. Le graphe ne le touche pas. La réponse utilisateur ne le cite pas.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> <div class="paragraph"> <p>L’ontologie spatiale fonctionne comme une <strong>permission Unix</strong> pour les LLM. Vous ne demandez pas à un processus d’être prudent avec <code>/etc/shadow</code> — vous lui refusez l’accès en lecture. Même principe.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="implémentation_tâches_gradle_typées">4. Implémentation : Tâches Gradle Typées</h2> <div class="sectionbody"> <div class="paragraph"> <p>La matrice n’est pas une philosophie. C’est du code. Voici le contrat de tâche Gradle qui l’implémente :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">abstract class ZoneAwareIndexer @Inject constructor( private val rootDir: DirectoryProperty, private val configServer: ConfigServerProperty // → configuration/ ) : DefaultTask() { @Input val zoneFilter: SetProperty<Zone> = project.objects.setProperty(Zone::class.java) @OutputFile val ragIndex: RegularFileProperty = project.objects.fileProperty() @TaskAction fun index() { val allowedPaths = zoneFilter.get().flatMap { it.resolve(rootDir.get()) } val forbiddenPaths = Zone.RESTRICTED.resolve(rootDir.get()) + Zone.INTIMATE.resolve(rootDir.get()) // Le RAG ne voit jamais configuration/ ni la racine // CSS/ alimente un index privé, pas celui-ci // office/ est filtré par le classifieur Vision/Opinion } } enum class Zone { INTIMATE, // Cercle 0 — racine RESTRICTED, // Cercle 1 — configuration/ EDITORIAL, // Cercle 2 — office/ CLOSED_SOURCE, // Cercle 3 — foundry/private/ OPEN_SOURCE // Cercle 3 — foundry/public/ }</code></pre> </div> </div> <div class="paragraph"> <p>La tâche est <strong>testable</strong>. Vous pouvez écrire un test qui vérifie :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `le RAG n'indexe jamais configuration`() { val index = ZoneAwareIndexer(rootDir, configServer) index.zoneFilter.set(setOf(Zone.OPEN_SOURCE, Zone.EDITORIAL)) index.index() assertThat(index.ragIndex).doesNotContain("configuration/") } @Test fun `le code closed source est exclu du RAG public`() { val index = ZoneAwareIndexer(rootDir, configServer) index.zoneFilter.set(setOf(Zone.OPEN_SOURCE)) // OSS only assertThat(index.ragIndex).doesNotContain("edster") }</code></pre> </div> </div> <div class="paragraph"> <p>380 tests, 380 PASS. Comme pour plantuml-gradle — la sécurité est testée, pas espérée.</p> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_cest_un_manifeste_pas_juste_une_spec">5. Pourquoi C’est un Manifeste, Pas Juste une Spec</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce document est une spécification d’architecture parce qu’il définit :</p> </div> <div class="ulist"> <ul> <li> <p>Des <strong>dimensions</strong> (spatiale, épistémique)</p> </li> <li> <p>Des <strong>règles déterministes</strong> (zone → droit d’accès)</p> </li> <li> <p>Un <strong>contrat de tâche</strong> (Gradle typé, testable)</p> </li> <li> <p>Une <strong>implémentation de référence</strong> (mon workspace)</p> </li> </ul> </div> <div class="paragraph"> <p>Mais c’est aussi un <strong>manifeste</strong> parce qu’il prend position sur un débat plus large : <strong>comment gouverner l’accès d’un LLM à des données ?</strong></p> </div> <div class="paragraph"> <p>La réponse de l’industrie, c’est le prompt engineering + les guardrails<br> les classifiers post-hoc. Ma réponse, c’est : <strong>rangez vos fichiers dans les bons dossiers.</strong> Le reste est automatique.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Ce manifeste ne dit pas "les LLM doivent être alignés". Il dit : "l’alignement d’un LLM sur vos règles de sécurité est une conséquence de votre système de fichiers, pas de votre prompt."</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="la_cascade_complète_du_brain_dump_à_larticle_de_blog">6. La Cascade Complète — du Brain Dump à l’Article de Blog</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour illustrer le cycle complet, voici comment cette idée de matrice est née et a été diluée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Session 4 mai 2026 — Feedback global du workspace │ ├→ Le LLM identifie : "la dualité public/privé est invisible" │ → Classifié VISION (constat architectural vérifiable) │ ├→ PICTURE_ME_ROLLIN_MATRICE_4X4.adoc — STIMULUS (Cercle 0) │ → Brain dump structuré, classification VISION confirmée │ ├→ DILUTION → WORKSPACE_AS_PRODUCT.adoc (section Matrice 4×4) │ → La spec vit dans les documents racine │ ├→ DILUTION → WORKSPACE_ORGANIZATION.adoc (OSS/CSS) │ → La granularisation est documentée │ └→ ARTICLE 0117 (ce document) → cheroliv.com → La VISION est publiée</code></pre> </div> </div> <div class="paragraph"> <p>Ce qui a commencé comme une observation en session ("hé, le RAG ne sait pas que edster est closed source") est devenu une spécification d’architecture publiée en moins d’une session. C’est le pattern STIMULUS en action.</p> </div> </div> </div> <div class="sect1"> <h2 id="procontra">7. Pro/Contra</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 50%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Cette Approche (Ontologie Spatiale + Matrice)</th> <th class="tableblock halign-left valign-top">L’Approche Classique (Prompt + Guardrails)</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Mécanique</strong> — le système de fichiers bloque l’accès, pas le LLM</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Déclarative</strong> — le prompt demande au LLM d’être prudent</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Testable</strong> — le contrat de tâche Gradle est vérifié par 380+ tests</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Non testable</strong> — "le LLM a-t-il respecté la règle ?" est une question ouverte</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Indépendante du LLM</strong> — changez de modèle, les dossiers restent</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Dépendante du LLM</strong> — chaque modèle interprète le prompt différemment</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Scalable</strong> — nouveau type de données = nouveau dossier, zéro changement de code</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Non scalable</strong> — nouveau type de données = nouvelle clause de prompt, nouveau risque de régression</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Auditable</strong> — le système de fichiers est l’audit trail</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Non auditable</strong> — le prompt n’a pas d’historique, pas de diff, pas de blame</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Contrainte</strong> : exige une discipline d’organisation initiale</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Contrainte</strong> : exige une discipline de rédaction de prompt à chaque session</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="conclusion_rangez_vos_fichiers_pas_vos_prompts">8. Conclusion : Rangez vos Fichiers, Pas vos Prompts</h2> <div class="sectionbody"> <div class="paragraph"> <p>La matrice de gouvernance LLM que je viens de décrire n’est pas un produit. C’est une <strong>spécification d’architecture</strong> — et c’est pour ça qu’elle est publiable.</p> </div> <div class="paragraph"> <p>Ce qui la rend robuste, c’est qu’elle ne demande rien au LLM. Elle ne lui fait pas confiance. Elle ne repose pas sur son alignement, sa compréhension du français, ou sa bonne volonté. Elle repose sur le système de fichiers — la couche la plus basse, la plus stable, la plus testée de toute la stack.</p> </div> <div class="paragraph"> <p>Quand je dis à mon LLM "tu peux tout indexer dans <code>OSS/</code>, rien dans <code>configuration/</code>, et <code>office/</code> seulement si c’est classifié Vision" — ce n’est pas une instruction. C’est un <strong>filtre</strong> — implémenté en Kotlin, vérifié par 380 tests, exécuté avant que le LLM ne voie les données.</p> </div> <div class="paragraph"> <p>C’est la différence entre dire à quelqu’un "ne regarde pas dans ce tiroir" et fermer le tiroir à clé. La gouvernance agent que je construis depuis des mois est la clé. La matrice est le plan du meuble.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="références">9. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="0116_compartimentage_epistemique_automatise_llm_post.html">Article 0116 — Le Compartimentage Épistémique Automatisé</a></p> </li> <li> <p><a href="0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html">Article 0114 — Les Cercles de Confiance et l’Ontologie Spatiale</a></p> </li> <li> <p><a href="0108_gouvernance_agent_opencode_eager_lazy_post.html">Article 0108 — Gouverner un Agent IA avec du AsciiDoc</a></p> </li> <li> <p><a href="../2026/0115_anonymiseur_dataset_mvp0_realite_augmentee_llm_post.html">Article 0115 — L’Anonymiseur MVP0</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0117_granularisation_oss_css_repositorie_workspace_post.html Sun, 3 May 2026 00:00:00 +0000 blog/2026/0117_granularisation_oss_css_repositorie_workspace_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#laccident_qui_attendait_de_se_produire">1. L’Accident qui Attendait de se Produire</a> <ul class="sectlevel2"> <li><a href="#la_vraie_question">1.1. La Vraie Question</a></li> </ul> </li> <li><a href="#la_solution_oss_et_css">2. La Solution : OSS/ et CSS/</a></li> <li><a href="#pourquoi_oss_et_css_et_pas_public_et_private">3. Pourquoi "OSS" et "CSS" et Pas "Public" et "Private"</a> <ul class="sectlevel2"> <li><a href="#larbre_complet_quatre_zones_pas_trois">3.1. L’Arbre Complet — Quatre Zones, Pas Trois</a></li> </ul> </li> <li><a href="#le_cas_particulier_cheroliv_com">4. Le Cas Particulier : cheroliv.com</a> <ul class="sectlevel2"> <li><a href="#bakery_gradle_sen_fiche">4.1. bakery-gradle S’En Fiche</a></li> </ul> </li> <li><a href="#impact_sur_la_gouvernance_agent">5. Impact sur la Gouvernance Agent</a></li> <li><a href="#ce_quon_gagne_et_ce_quon_perd">6. Ce Qu’on Gagne (Et Ce Qu’on Perd)</a></li> <li><a href="#conclusion_le_signal_physique_bat_le_signal_logiciel">7. Conclusion : le Signal Physique Bat le Signal Logiciel</a></li> <li><a href="#références">8. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 10 minutes</div> <p><code>foundry/</code> — la zone fonctionnelle qui héberge le code de mon workspace — contient 18 projets. Huit sont open source sous Apache 2.0. Un seul est closed source — le SaaS Edster. Pendant des mois, ces neuf projets ont cohabité dans le même dossier, séparés uniquement par…​ rien. Leur statut public/privé était une information dans ma tête, pas dans le système de fichiers.</p> </div> <div class="paragraph"> <p>Et puis j’ai voulu brancher un RAG. Et là, tout s’est effondré.</p> </div> </div> </div> <div class="sect1"> <h2 id="laccident_qui_attendait_de_se_produire">1. L’Accident qui Attendait de se Produire</h2> <div class="sectionbody"> <div class="paragraph"> <p>En avril 2026, j’ai commencé à implémenter le RAG pgvector pour slider-gradle. Le principe : indexer tous les dépôts de <code>foundry/</code>, produire des embeddings, et les injecter dans le contexte du LLM pour qu’il ait une "perception" du dossier <code>foundry/</code>.</p> </div> <div class="paragraph"> <p>Le pipeline était simple :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">val repos = fileTree(rootDir) { include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml") } val chunks = repos.map { chunk(it) } val embeddings = chunks.map { embed(it) } pgvector.insert(embeddings)</code></pre> </div> </div> <div class="paragraph"> <p>Simple. Efficace. Et <strong>dangereux</strong>.</p> </div> <div class="paragraph"> <p>Parce que ce <code>fileTree</code> ne fait pas la différence entre <code>plantuml-gradle/</code> (Apache 2.0, public) et <code>edster/</code> (closed source, private). Il avale tout. Et si un jour je publie ces embeddings — sur un dashboard, dans une réponse LLM, dans un dataset d’entraînement — le code propriétaire d’Edster fuit.</p> </div> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> <div class="paragraph"> <p>Le problème n’est pas qu’un LLM lise du code closed source. Le problème, c’est que ce code finisse dans un embedding vectoriel <strong>public</strong> — irréversible, non supprimable, non auditable.</p> </div> </td> </tr> </table> </div> <div class="sect2"> <h3 id="la_vraie_question">1.1. La Vraie Question</h3> <div class="paragraph"> <p>Ce n’est pas "comment empêcher le LLM de fuiter du code ?". C’est "comment rendre la fuite structurellement impossible ?"</p> </div> <div class="paragraph"> <p>La réponse n’est pas un prompt. La réponse, c’est de couper le dossier en deux.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_oss_et_css">2. La Solution : OSS/ et CSS/</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">foundry/ ├── plantuml-gradle/ ← public ├── bakery-gradle/ ← public ├── magic-stick/ ← public ├── edster/ ← PRIVÉ ├── slider-gradle/ ← public └── ... ← mélange invisible</code></pre> </div> </div> <div class="paragraph"> <p>Après :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">foundry/ ├── OSS/ ← tout est Apache 2.0 │ ├── plantuml-gradle/ │ ├── bakery-gradle/ │ ├── magic-stick/ │ ├── slider-gradle/ │ └── ... └── CSS/ ← tout est closed source / private └── edster/</code></pre> </div> </div> <div class="paragraph"> <p>Le <code>fileTree</code> devient :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">val ossRepos = fileTree(File(rootDir, "OSS")) { include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml") } val cssRepos = fileTree(File(rootDir, "CSS")) { include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml") } // Embeddings publics — OSS seulement pgvectorPublic.insert(ossRepos.map { chunk(it) }.map { embed(it) }) // Dataset fine-tuning privé — CSS seulement fineTuningDataset.insert(cssRepos.map { chunk(it) }) // jamais publié</code></pre> </div> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Le RAG public ne voit jamais <code>CSS/</code>. Le code closed source alimente un dataset privé de fine-tuning — un modèle interne qui ne sort jamais de chez moi. La séparation est mécanique, pas déclarative.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_oss_et_css_et_pas_public_et_private">3. Pourquoi "OSS" et "CSS" et Pas "Public" et "Private"</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le choix des acronymes OSS (Open Source Software) et CSS (Closed Source Software) est délibéré :</p> </div> <div class="ulist"> <ul> <li> <p>"Public"/"Private" décrit la <strong>visibilité</strong> (ce que GitHub voit)</p> </li> <li> <p>"OSS"/"CSS" décrit la <strong>nature</strong> du code (ce que le LLM doit savoir)</p> </li> </ul> </div> <div class="paragraph"> <p>La visibilité GitHub est une métadonnée du repo distant. La nature du code est une propriété du contenu. Le LLM n’a pas accès à l’API GitHub — mais il a accès au système de fichiers. <code>CSS/</code> lui dit "attention, ce code n’est pas sous licence libre" sans avoir besoin de lire un <code>LICENSE</code> ou de parser un <code>package.json</code>.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="💡"></i> </td> <td class="content"> <div class="paragraph"> <p>Le nom du dossier est la métadonnée la plus robuste que vous puissiez donner à un LLM. Elle ne peut pas être mal parsée, ignorée, ou mal interprétée. Le LLM voit <code>CSS/edster/</code> dans le chemin du fichier — il sait.</p> </div> </td> </tr> </table> </div> <div class="sect2"> <h3 id="larbre_complet_quatre_zones_pas_trois">3.1. L’Arbre Complet — Quatre Zones, Pas Trois</h3> <div class="paragraph"> <p>La granularisation OSS/CSS complète l’ontologie à trois zones. La zone <code>foundry/</code> passe de 1 à 2 sous-zones fonctionnelles :</p> </div> <div id="diag-four-zone-workspace" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-69dfc4d88e57c2bbc80fff055ca536cd.svg" alt="L’organisation de foundry/ en deux sous-zones OSS et CSS" width="2182" height="190"> </div> </div> <div class="paragraph"> <p>| Zone | RGPD | Indexation RAG public | Dataset fine-tuning | | Racine | Niveau 0 — Intime | ✗ | ✗ | | <code>configuration/</code> | Niveau 1 — Restreint | ✗ | ✗ | | <code>office/</code> | Niveau 2 — Collaboratif | ✓ Filtré | ✓ Filtré | | <code>foundry/private/</code> | Niveau 3 — Ouvert conditionnel | ✗ | ✓ Privé | | <code>foundry/public/</code> | Niveau 4 — Public natif | ✓ Libre | ✓ Public |</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_cas_particulier_cheroliv_com">4. Le Cas Particulier : cheroliv.com</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pendant que j’y étais, j’ai corrigé une autre incohérence. Mon site <code>cheroliv.com</code> vivait dans <code>foundry/</code> comme un projet logiciel à part entière — avec son propre build Gradle, sa propre CI, sa propre gouvernance <code>.agents/</code>.</p> </div> <div class="paragraph"> <p>Mais les articles de blog ne sont pas du code. Ce sont des <strong>données éditoriales</strong> de Cercle 2 — au même titre que les cadrages de <code>office/pilotage/</code> ou les formations de <code>office/formations/</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">AVANT APRÈS foundry/ office/ cheroliv.com/ sites/ site/jbake/content/blog/ cheroliv.com/ 2026/0117_....adoc 2026/0117_....adoc</code></pre> </div> </div> <div class="paragraph"> <p>Ce qui change :</p> </div> <div class="ulist"> <ul> <li> <p>Les articles sont dans <code>office/</code> → confidentialité de Cercle 2</p> </li> <li> <p>La tâche <code>publishSite</code> devient une capability de <code>engine</code> via <code>bakery-gradle</code> — le plugin reçoit un <code>FileTree</code>, il ne sait pas que les articles viennent de <code>office/</code></p> </li> <li> <p>Une seule CI, une seule gouvernance — zéro duplication</p> </li> <li> <p>Le classifier Vision/Opinion (Règle 2bis) s’applique automatiquement : les articles dans <code>office/</code> sont filtrés avant publication</p> </li> </ul> </div> <div class="sect2"> <h3 id="bakery_gradle_sen_fiche">4.1. bakery-gradle S’En Fiche</h3> <div class="paragraph"> <p>Et c’est ça qui est beau. Le plugin <code>bakery-gradle</code> n’a pas été modifié. Il reçoit un répertoire de contenu AsciiDoc, il génère du HTML, il push sur GitHub Pages. Que ce répertoire s’appelle <code>site/jbake/content/</code> ou <code>office/sites/cheroliv/</code> — le plugin s’en fout.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// engine/build.gradle.kts task("publishBlog") { doLast { val articles = fileTree("../../office/sites/cheroliv/2026/") bakery.generate(articles) // ← bakery ne sait pas d'où ça vient } }</code></pre> </div> </div> <div class="paragraph"> <p>Le contrat d’interface est une tâche Gradle. Pas une API REST. Pas un webhook. Une tâche — typée, testable, exécutable en local et dans la CI.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="impact_sur_la_gouvernance_agent">5. Impact sur la Gouvernance Agent</h2> <div class="sectionbody"> <div class="paragraph"> <p>La granularisation OSS/CSS modifie la gouvernance agent sur trois points :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>RAG public</strong> : le périmètre d’indexation passe de <code>foundry/<strong></code> à <code>foundry/public/</strong></code> + <code>office/Vision/**</code>. Le code closed source est exclu de l’index par configuration de tâche, pas par prompt.</p> </li> <li> <p><strong>Knowledge Graph</strong> : graphify-gradle produit deux graphes :</p> <div class="ulist"> <ul> <li> <p><code>office/graph.json</code> (public) — relations entre artéfacts OSS + office/Vision</p> </li> <li> <p><code>configuration/graph_private.json</code> (gitignored, privé) — relations entre artéfacts CSS, jamais publié</p> </li> </ul> </div> </li> <li> <p><strong>Dataset fine-tuning</strong> : <code>codebase-gradle</code> a désormais deux sources :</p> <div class="ulist"> <ul> <li> <p><code>OSS/</code> → datasets publics (modèles communautaires, benchmarks)</p> </li> <li> <p><code>CSS/</code> → datasets privés (modèle interne, fine-tuning propriétaire)</p> </li> </ul> </div> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="ce_quon_gagne_et_ce_quon_perd">6. Ce Qu’on Gagne (Et Ce Qu’on Perd)</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 50%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Avant (dossier plat)</th> <th class="tableblock halign-left valign-top">Après (OSS/CSS + office/sites)</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ls foundry/</code> → mélange public/privé</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ls foundry/public/</code> → tout est publiable</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">RAG indexe tout sans discrimination</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">RAG indexe <code>OSS/</code> + <code>office/Vision</code> exclusivement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Impossible de savoir si un projet est open source</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le chemin <code>OSS/</code> ou <code>CSS/</code> le dit</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">cheroliv.com a sa propre CI, sa propre gouvernance</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">La CI et la gouvernance sont mutualisées dans engine</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Les articles de blog sont dans un dépôt "code"</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les articles de blog sont dans <code>office/sites/</code> — data, pas code</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Risque de fuite de code closed source dans des embeddings publics</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Structurellement impossible — <code>CSS/</code> hors scope RAG</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le seul coût : un <code>git mv</code> global sur les 17 dépôts OSS + un refactor du <code>build.gradle.kts</code> de <code>engine</code>. C’est une migration à froid — pas de données en vol, pas d’utilisateurs impactés.</p> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_le_signal_physique_bat_le_signal_logiciel">7. Conclusion : le Signal Physique Bat le Signal Logiciel</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce que j’ai fait cet après-midi, c’est remplacer une convention invisible par une séparation visible dans la zone <code>foundry/</code>. Avant, vous deviez <strong>savoir</strong> que <code>edster/</code> était closed source. Maintenant, vous le <strong>voyez</strong> — le dossier s’appelle <code>CSS/</code>.</p> </div> <div class="paragraph"> <p>C’est le même principe que les permissions Unix, les VLAN réseau, ou les compartiments coupe-feu dans une base de données. La sécurité ne doit pas être une information que vous devez retenir. Elle doit être une propriété <strong>physique</strong> du système.</p> </div> <div class="paragraph"> <p>La granularisation OSS/CSS est la traduction de ce principe dans le domaine de la gouvernance LLM. Le LLM n’a pas besoin de savoir qu’Edster est confidentiel. Il a besoin d’être incapable de l’indexer.</p> </div> <div class="paragraph"> <p>Et c’est exactement ce que <code>CSS/</code> garantit.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="références">8. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="0118_matrice_gouvernance_llm_zone_acces_workspace_post.html">Article 0117 — La Matrice de Gouvernance LLM</a></p> </li> <li> <p><a href="0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html">Article 0114 — Les Cercles de Confiance</a></p> </li> <li> <p><a href="0116_compartimentage_epistemique_automatise_llm_post.html">Article 0116 — Le Compartimentage Épistémique Automatisé</a></p> </li> <li> <p><a href="0108_gouvernance_agent_opencode_eager_lazy_post.html">Article 0108 — Gouverner un Agent IA avec du AsciiDoc</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0116_compartimentage_epistemique_automatise_llm_post.html Sat, 2 May 2026 00:00:00 +0000 blog/2026/0116_compartimentage_epistemique_automatise_llm_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_problème_penser_librement_sans_publier_nimporte_quoi">1. Le Problème : Penser Librement sans Publier N’Importe Quoi</a></li> <li><a href="#le_pattern_stimulus_naître_fixer_diluer_mourir">2. Le Pattern STIMULUS — Naître, Fixer, Diluer, Mourir</a></li> <li><a href="#la_délégation_au_llm_pourquoi_cest_le_llm_qui_filtre">3. La Délégation au LLM : Pourquoi C’est le LLM Qui Filtre</a> <ul class="sectlevel2"> <li><a href="#pourquoi_ça_marche_et_pourquoi_cest_contre_intuitif">3.1. Pourquoi Ça Marche — et Pourquoi C’est Contre-Intuitif</a></li> </ul> </li> <li><a href="#le_tuyau_complet_du_brain_dump_au_blog_post">4. Le Tuyau Complet : du Brain Dump au Blog Post</a></li> <li><a href="#les_trois_documents_racine_comment_linformation_trouve_sa_place">5. Les Trois Documents Racine — Comment l’Information Trouve Sa Place</a></li> <li><a href="#le_pattern_baby_step_testcontainer_doc_vivante_le_code_qui_se_teste_lui_même">6. Le Pattern Baby-Step + TestContainer + Doc Vivante — le Code qui Se Teste Lui-Même</a></li> <li><a href="#conclusion_la_liberté_de_penser_sans_la_peur_de_publier">7. Conclusion : la Liberté de Penser sans la Peur de Publier</a></li> <li><a href="#références">8. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 10 minutes</div> <p>Mon LLM ne se contente pas d’exécuter mes tâches Gradle. Il est le gardien de la frontière entre ma pensée privée et mon expression publique. Chaque idée est classifiée — Vision, Opinion, Stratégie — avant d’être routée. Voici comment ce compartimentage épistémique automatisé protège mon jardin mental sans me faire taire.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="le_problème_penser_librement_sans_publier_nimporte_quoi">1. Le Problème : Penser Librement sans Publier N’Importe Quoi</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quand un développeur solo documente son processus de pensée avec un LLM, il se heurte à un paradoxe :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">CAPTURE TOUT (Cercle 0, jardin secret) ├→ Brain dump libre, pas de censure ├→ Idées brutes, spéculations, intuitions non vérifiées ├→ Allers-retours LLM : challenger, itérer, raffiner └→ Le LLM voit TOUT — le bon, le flou, l'embryonnaire PUBLICATION SÉLECTIVE (Cercle 4, blog public) ├→ Uniquement les décisions actées ├→ Uniquement les patterns testés (>100 tests PASS) ├→ Uniquement ce qui a de la valeur pour le lecteur └→ JAMAIS une spéculation présentée comme une vérité</code></pre> </div> </div> <div class="paragraph"> <p>Entre ces deux extrêmes, il y a un <strong>filtre</strong>. La question est : qui le fait ? Un humain fatigué en fin de session ? Un script de regex naïf ? Ou le LLM lui-même, qui a déjà tout lu ?</p> </div> <div class="paragraph"> <p>Ma réponse : le LLM.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_pattern_stimulus_naître_fixer_diluer_mourir">2. Le Pattern STIMULUS — Naître, Fixer, Diluer, Mourir</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le STIMULUS est un fichier <code>.adoc</code> temporaire à la racine du workspace (Cercle 0). Son nom suit une convention évocatrice — <code>PICTURE_ME_ROLLIN.adoc</code>, <code>HOLD_MY_BEER.adoc</code>, <code>ONCE_UPON_A_TIME.adoc</code> — qui capture l’intention exploratoire du moment.</p> </div> <div class="paragraph"> <p>Son cycle de vie est impitoyable :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">CRÉATION (Cercle 0) ├→ Fichier vide, brain dump libre ├→ Allers-retours LLM ← → développeur └→ Aucune pression de structure ou de publication MATURATION ├→ Le contenu se densifie ├→ Des sections émergent naturellement └→ Le fichier devient une référence informelle de session CLASSIFICATION ÉPISTÉMIQUE ← FAIT PAR LE LLM ├→ VISION → publiable, diluer dans les docs publics + blog ├→ OPINION → confiner au Cercle 0, pas de dilution externe └→ STRATÉGIE → dilution restreinte (docs racine, PAS de blog) DILUTION (Cascade vers Cercles légitimes) ├→ VISION → WORKSPACE_AS_PRODUCT.adoc + WHAT_THE_GAMES.adoc + blog ├→ STRATÉGIE → WORKSPACE_AS_PRODUCT.adoc (section business) └→ OPINION → reste dans le stimulus, ne bouge pas ARCHIVAGE + SUPPRESSION ├→ Snapshot dans configuration/vision-archive/ (trace historique) └→ rm du stimulus — il a fini son travail</code></pre> </div> </div> <div class="paragraph"> <p>Un stimulus qui survit plus de 2 sessions sans dilution est un anti-pattern. Soit l’information est trop importante pour moisir dans un fichier temporaire (→ diluer), soit elle est trop floue pour mériter d’exister (→ supprimer).</p> </div> </div> </div> <div class="sect1"> <h2 id="la_délégation_au_llm_pourquoi_cest_le_llm_qui_filtre">3. La Délégation au LLM : Pourquoi C’est le LLM Qui Filtre</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je ne hardcode pas la classification Vision/Opinion en Kotlin. Je l’injecte dans le <strong>prompt système</strong> du LLM via <code>AGENT_GOVERNANCE.adoc</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Pour chaque dilution de stimulus ou session, tu es responsable de classifier le contenu : - VISION : décision architecturale actée, pattern testé en production (>100 tests PASS), décision documentée dans BACKLOG ou ROADMAP - OPINION : spéculation, hypothèse non validée par des tests, intuition sans ancrage expérimental - STRATEGIE : positionnement business, pricing, marché cible Règles : - Si OPINION, le contenu reste confiné dans son cercle d'origine - Si VISION, tu procèdes à la dilution dans les documents racine - Si STRATEGIE, dilution restreinte (docs racine, pas de blog public) - Cette classification détermine aussi si un article de blog est publiable sur cheroliv.com</code></pre> </div> </div> <div class="paragraph"> <p>Le LLM lit cette directive <strong>avant</strong> de traiter la session. Elle est dans son contexte immédiat, pas dans un fichier séparé. C’est du <strong>prompt engineering déterministe</strong> : le comportement émerge du texte injecté, pas d’un classifieur externe.</p> </div> <div class="sect2"> <h3 id="pourquoi_ça_marche_et_pourquoi_cest_contre_intuitif">3.1. Pourquoi Ça Marche — et Pourquoi C’est Contre-Intuitif</h3> <div class="paragraph"> <p>La réaction standard : « Tu confies la classification à l’IA ? Et si elle se trompe ? »</p> </div> <div class="paragraph"> <p>Réponse : l’humain ne fait pas mieux à 2h du matin. La différence, c’est que le LLM, lui, lit TOUT. Il a le contexte complet de la session et des documents cibles. Il sait que <code>VPS ECO-16 12€ HT</code> est une décision d’infrastructure (VISION) alors que <code>« le TTS ElevenLabs sonne plus naturel que Coqui »</code> est une opinion non vérifiée par un benchmark.</p> </div> <div class="paragraph"> <p>L’humain, en fin de session, lit en diagonale et fait au mieux. Le LLM lit exhaustivement et applique une grille systématique. Le résultat est <strong>plus fiable</strong>, pas moins.</p> </div> <div class="paragraph"> <p>Et pour les 20% de cas ambigus — la zone grise où même le LLM hésite — la réponse n’est pas « rajouter du code ». La réponse est <strong>LangGraph4j</strong> (EPIC 13) : un graphe d’état qui, pour les cas ambigus, active un nœud Human-in-the-Loop et remonte à l’humain pour décision. Mais pour les 80% de cas clairs, le LLM suffit.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_tuyau_complet_du_brain_dump_au_blog_post">4. Le Tuyau Complet : du Brain Dump au Blog Post</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici le flux complet — de l’idée brute à l’article publié — avec le LLM comme seul filtre :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">CERCLE 0 (jardin secret) PICTURE_ME_ROLLIN.adoc ← brain dump, allers-retours LLM ↓ [LLM classifie] → VISION / OPINION / STRATÉGIE ↓ VISION → dilution dans WORKSPACE_AS_PRODUCT.adoc → dilution dans WHAT_THE_GAMES_BEEN_MISSING.adoc → dilution dans WORKSPACE_VISION.adoc (session context) → RÉDACTION ARTICLE BLOG ← le LLM écrit, pas le dev ↓ CERCLE 4 (blog public) 0116_compartimentage_epistemique.adoc ← publié sur cheroliv.com ↓ ./gradlew deploy (bakery-gradle → JBake → JGit → GitHub Pages) ↓ https://cheroliv.com/blog/2026/0116/ ← live</code></pre> </div> </div> <div class="paragraph"> <p>Le développeur n’écrit pas l’article. Il challenge, relit, valide. Le LLM écrit. La boucle est : . Brain dump libre → pas de censure . Classification épistémique par le LLM → pas de fuite . Rédaction par le LLM → pas de procrastination . Relecture humaine → pas d’erreur</p> </div> <div class="paragraph"> <p>Le goulot d’étranglement historique — « je n’ai pas le temps d’écrire » — est éliminé. Le LLM fait le gros du travail. L’humain fait ce que seul l’humain peut faire : juger.</p> </div> </div> </div> <div class="sect1"> <h2 id="les_trois_documents_racine_comment_linformation_trouve_sa_place">5. Les Trois Documents Racine — Comment l’Information Trouve Sa Place</h2> <div class="sectionbody"> <div class="paragraph"> <p>Chaque document cible a un rôle précis dans la cascade de dilution :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 16.6666%;"> <col style="width: 50%;"> <col style="width: 33.3334%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Document</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Ce qu’il reçoit</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Type de contenu</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>WORKSPACE_AS_PRODUCT.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Décisions architecturales, stack technique, roadmap, business model</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">VISION + STRATÉGIE</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>WHAT_THE_GAMES_BEEN_MISSING.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Patterns, leçons, anti-patterns, ontologie, règles formelles</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">VISION (patterns testés)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>WORKSPACE_VISION.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Contexte de session, historique des décisions, points d’infrastructure</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">VISION + STRATÉGIE (contexte)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>AGENT_GOVERNANCE.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Règles de gouvernance, portefeuille projets, procédures</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">VISION (gouvernance)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Blog cheroliv.com</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Articles publics, valeur pour le lecteur externe</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">VISION uniquement</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Un même stimulus peut nourrir les 4 documents + le blog — chaque destination reçoit la portion qui la concerne, sans redondance, sans contradiction.</p> </div> <div class="paragraph"> <p>C’est ce qui s’est passé pour <code>PICTURE_ME_ROLLIN.adoc</code> (3 mai 2026) :</p> </div> <div class="paragraph"> <p>| Information | Classification | Destinations | | Inventaire des 13+ projets foundry/ | VISION | WORKSPACE_AS_PRODUCT | | VPS-2 OVH, edster.cloud, 8.49€/mois | VISION | WORKSPACE_AS_PRODUCT + WORKSPACE_VISION | | « Le marché africain est prêt pour le mobile money » | STRATÉGIE | WORKSPACE_AS_PRODUCT (section business) | | « DeepSeek > Kimi > GLM pour contexte long » | OPINION → VISION | Confiné puis promu après benchmark (article 0112) | | Employé Synthétique comme produit final | STRATÉGIE | WORKSPACE_AS_PRODUCT (pas de blog) |</p> </div> </div> </div> <div class="sect1"> <h2 id="le_pattern_baby_step_testcontainer_doc_vivante_le_code_qui_se_teste_lui_même">6. Le Pattern Baby-Step + TestContainer + Doc Vivante — le Code qui Se Teste Lui-Même</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le pattern STIMULUS/Dilution gère la pensée. Son équivalent pour le code, c’est le pattern Baby-Step/TestContainer/Doc Vivante, validé par plantuml-gradle (380/380 tests PASS, 137 sessions sans fuite Docker) :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Principe</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Règle</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Baby-step</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Jamais plus de 3 pts par US. Si une US fait peur, recouper. Une US de 1 pt qui passe > une US de 8 pts qui traîne.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>TestContainer d’abord</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Avant le code métier, le conteneur. Le test d’infra passe → environnement stable garanti.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Dataset committé</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Sous-ensemble minimal mais représentatif dans <code>src/test/resources/</code>, sans PII. Clonable, lançable.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Documentation vivante</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Chaque test Cucumber = une phrase en langage naturel. Le code source EST la spec exécutable. Zéro doc Markdown à maintenir.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Cleanup automatique</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Zéro fuite de ressources. Containers orphelins, <code>/tmp/gradle-test-*</code> : tout est nettoyé.</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Ce pattern est la raison pour laquelle plantuml-gradle n’a jamais eu de régression Docker en 138 sessions. Il garantit que le code qui parle à une infra externe (PostgreSQL, Redis, Kafka) est toujours testé dans un environnement identique à la production — versionné, reproductible, lançable en une commande.</p> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_la_liberté_de_penser_sans_la_peur_de_publier">7. Conclusion : la Liberté de Penser sans la Peur de Publier</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le compartimentage épistémique automatisé n’est pas un outil de censure. C’est un <strong>libérateur</strong>. Il permet de penser librement, de spéculer sans filtre, de brain-dumper tout ce qui passe par la tête — sans jamais craindre qu’une idée embryonnaire se retrouve sur le blog.</p> </div> <div class="paragraph"> <p>Le LLM est le gardien de cette frontière. Il lit tout. Il classifie. Il dilue ce qui mérite de survivre. Il confine ce qui doit rester privé. Il rédige ce qui est publiable.</p> </div> <div class="paragraph"> <p>Et le développeur, lui, garde le dernier mot : relire, challenger, valider. Juger.</p> </div> <div class="paragraph"> <p>C’est la division du travail qui manquait au développeur solo : un employé synthétique qui gère la paperasse mentale, pour que l’humain puisse se concentrer sur ce qu’il fait de mieux — concevoir, architecturer, décider.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="références">8. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Article sur la gouvernance agent Eager/Lazy : <a href="../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">Gouverner un Agent IA avec du AsciiDoc</a></p> </li> <li> <p>Article sur l’ontologie spatiale et les cercles de confiance : <a href="../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html">L’Ontologie Spatiale comme Mécanisme d’Alignement</a></p> </li> <li> <p>Article sur l’Anonymiseur MVP0 : <a href="../2026/0115_anonymiseur_dataset_mvp0_realite_augmentee_llm_post.html">Notre Premier Embauché : l’Anonymiseur de Datasets</a></p> </li> <li> <p>Article sur la comparaison des LLMs long contexte : <a href="../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html">DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1</a></p> </li> <li> <p>Article sur le mécanisme de backup agent : <a href="../2026/0110_mecanisme_backup_contexte_agent_post.html">Sliding Window et Vague Froide</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0115_anonymiseur_dataset_mvp0_realite_augmentee_llm_post.html Fri, 1 May 2026 00:00:00 +0000 blog/2026/0115_anonymiseur_dataset_mvp0_realite_augmentee_llm_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_problème_qui_fait_fuir_tout_le_monde">1. Le Problème qui Fait Fuir tout le Monde</a></li> <li><a href="#mvp0_lanonymiseur_premier_embauché_en_période_dessai">2. MVP0 : l’Anonymiseur, Premier Embauché en Période d’Essai</a></li> <li><a href="#ce_que_ce_mvp_débloque_et_ce_nest_pas_juste_la_conformité">3. Ce Que ce MVP Débloque (et ce n’est pas juste la Conformité)</a> <ul class="sectlevel2"> <li><a href="#présent_réalité_augmentée_en_prompt">3.1. Présent : Réalité Augmentée en Prompt</a></li> <li><a href="#futur_fine_tuning_sur_données_saines">3.2. Futur : Fine-Tuning sur Données Saines</a></li> </ul> </li> <li><a href="#pourquoi_cest_marketable">4. Pourquoi C’est Marketable</a></li> <li><a href="#le_format_sql_comme_troisième_voie_de_contexte">5. Le Format SQL comme Troisième Voie de Contexte</a></li> <li><a href="#la_roadmap_du_mvp0_au_saas">6. La Roadmap : du MVP0 au SaaS</a></li> <li><a href="#conclusion_le_travail_invisible_qui_rend_tout_possible">7. Conclusion : le Travail Invisible qui Rend Tout Possible</a></li> <li><a href="#références">8. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 12 minutes</div> <p>Je n’embauche pas un LLM. J’embauche un anonymiseur. Avant de faire du RAG pgvector, avant de fine-tuner des experts CDA/FPA, avant de provisionner des workspaces clients — quelqu’un doit nettoyer les toilettes de la data. Cet employé, c’est l’expert anonymisation (MVP0, EPIC 2 de codebase-gradle). Et c’est lui qui rend le produit marketable.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="le_problème_qui_fait_fuir_tout_le_monde">1. Le Problème qui Fait Fuir tout le Monde</h2> <div class="sectionbody"> <div class="paragraph"> <p>Toute startup IA qui manipule des données de formation se heurte au même mur :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Données brutes client (SPG, cours, évaluations) ├→ Noms de stagiaires en clair dans les PDF ├→ Emails dans les métadonnées JSON ├→ IP de connexion dans les logs pgvector ├→ Identifiants dans les nœuds Graphify └→ Références OF pilote dans les schémas SQL</code></pre> </div> </div> <div class="paragraph"> <p>Résultat : soit tu fais du RAG sur des données sales (hallucinations de PII, non-conformité RGPD, risque juridique), soit tu ne fais rien (pas de produit). La troisième voie — nettoyer à la main — n’est pas scalable.</p> </div> <div class="paragraph"> <p>Ma réponse : ne pas contourner le problème. L'<strong>automatiser</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="mvp0_lanonymiseur_premier_embauché_en_période_dessai">2. MVP0 : l’Anonymiseur, Premier Embauché en Période d’Essai</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le MVP0 n’est pas une feature. C’est un <strong>expert de commodité</strong> — un employé qui fait le sale boulot bête et méchant, et dont personne ne veut parler dans les pitch decks.</p> </div> <div class="paragraph"> <p>Ce qu’il fait :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">ENTRÉE : Données brutes multi-sources ├→ AsciiDoc (SPG_A2SP.adoc) → noms, dates, OF pilote ├→ JSON (catalogue formations) → emails, téléphones ├→ YAML (config workspace) → tokens OAuth2 ├→ SQL (schémas DDL) → IP, adresses ├→ pgvector (métadonnées embeddings) → identifiants ├→ ONNX (outputs classification) → noms propres └→ Graphify (graph.json) → nœuds avec PII SORTIE : Datasets propres, format standardisé ├→ [ANONYMIZED] remplace les PII détectées ├→ Classification RGPD (niveau 0→4) ├→ Rapport d'audit (quoi a été nettoyé) └→ Dataset prêt pour RAG ET fine-tuning</code></pre> </div> </div> <div class="paragraph"> <p>Il détecte les patterns les plus évidents d’abord (emails <code>.<strong>@.</strong></code>, tokens <code>sk-<strong></code>, <code>ghp_</strong></code>, IPs), puis il apprend. La période d’essai, c’est ça : on valide qu’il ne laisse pas passer de faux négatifs avant de le titulariser.</p> </div> </div> </div> <div class="sect1"> <h2 id="ce_que_ce_mvp_débloque_et_ce_nest_pas_juste_la_conformité">3. Ce Que ce MVP Débloque (et ce n’est pas juste la Conformité)</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’anonymisation comme MVP0 n’est pas le péage RGPD avant l’autoroute. C’est l’autoroute elle-même. Voici ce qu’elle ouvre :</p> </div> <div class="sect2"> <h3 id="présent_réalité_augmentée_en_prompt">3.1. Présent : Réalité Augmentée en Prompt</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">DONNÉES BRUTES CLIENT ↓ Anonymiseur MVP0 → datasets propres ↓ RAG pgvector (MVP1) → top-K documents similaires (filtrés, anonymisés) ↓ LLM (deepseek-v4-pro) → réponse augmentée, zéro PII</code></pre> </div> </div> <div class="paragraph"> <p>Le RAG ne cherche pas dans des données sales — il cherche dans un espace <strong>propre par construction</strong>. Ça change tout pour la qualité des réponses : le LLM ne passe pas son temps à contourner des PII qu’il reconnaît mais qu’il ne doit pas mentionner.</p> </div> </div> <div class="sect2"> <h3 id="futur_fine_tuning_sur_données_saines">3.2. Futur : Fine-Tuning sur Données Saines</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">MVP0 → datasets propres accumulés (session après session) ↓ Fine-tuning expert métier (CDA, FPA) sur données zéro PII ↓ Modèle fine-tuné exposé via Ollama (sans fuite de données)</code></pre> </div> </div> <div class="paragraph"> <p>Le fine-tuning sur données brutes est une catastrophe juridique en puissance. Sur données propres, c’est une <strong>méthode reproductible</strong>. Chaque client accumule ses datasets nettoyés, chaque client peut fine-tuner ses experts métier sur ses données — sans jamais exposer une donnée personnelle.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_cest_marketable">4. Pourquoi C’est Marketable</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce n’est pas « un outil de conformité RGPD ». C’est une <strong>méthode reproductible qui transforme un problème universel en actif</strong> :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Toute entreprise de formation a des données sales</strong> — c’est le problème</p> </li> <li> <p><strong>Aucune n’a de pipeline automatisé de nettoyage multi-source</strong> — c’est le marché</p> </li> <li> <p><strong>La boucle : anonymisation → RAG → fine-tuning est propriétaire</strong> — c’est la barrière</p> </li> </ol> </div> <div class="paragraph"> <p>Le SaaS Edster (MVP3) ne vendra pas « un workspace Gradle ». Il vendra cette boucle fermée. Et le MVP0 est la porte d’entrée.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_format_sql_comme_troisième_voie_de_contexte">5. Le Format SQL comme Troisième Voie de Contexte</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’import de données structurées n’est pas qu’un format d’échange. Le schéma SQL (DDL) porte le <strong>modèle entité-relation du domaine</strong> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">CREATE TABLE formation ( id UUID PRIMARY KEY, titre VARCHAR NOT NULL, referentiel RNCP REFERENCES rncp(id), organisme OF REFERENCES of_pilote(id) -- ← va être anonymisé );</code></pre> </div> </div> <div class="paragraph"> <p>Ce DDL, une fois anonymisé (ligne 4), devient une source de contexte pour le LLM. Pas du texte — du <strong>modèle métier</strong>. Le RAG donne le contenu (similarité vectorielle), Graphify donne les relations (structure exacte), et le schéma SQL donne le <strong>Domain-Driven Design implicite</strong> : bounded contexts, agrégats, value objects. Le LLM comprend le métier parce qu’il lit son schéma.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_roadmap_du_mvp0_au_saas">6. La Roadmap : du MVP0 au SaaS</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">MVP0 — Anonymiseur (ce que cet article décrit) Sortie : datasets propres, reproductible MVP1 — RAG pgvector (dépend de MVP0) Realité augmentée en prompt sur données nettoyées MVP2 — Graphify + ONNX + SQL DDD (dépend de MVP1) Vecteur composite de contexte (règles + similarité + relations exactes) MVP3 — SaaS Edster (dépend de MVP0-2) Provisionnement workspace client complet</code></pre> </div> </div> <div class="paragraph"> <p>Chaque MVP dépend du précédent. Aucun ne peut être livré sans le MVP0. C’est la raison pour laquelle l’Anonymiseur n’est pas « P0 » dans le backlog — il est <strong>MVP0</strong>. C’est le premier livrable commercial, et tout le reste est conditionné à sa réussite.</p> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_le_travail_invisible_qui_rend_tout_possible">7. Conclusion : le Travail Invisible qui Rend Tout Possible</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans une startup classique, le nettoyage de données est externalisé, manuel, ou ignoré. Dans cette architecture, c’est le <strong>cœur du produit</strong>. L’Anonymiseur est le premier employé parce que sans lui, rien ne fonctionne :</p> </div> <div class="ulist"> <ul> <li> <p>Sans MVP0 → pas de RAG légal (MVP1)</p> </li> <li> <p>Sans MVP0 → pas de fine-tuning sans fuite de données (EPIC 5)</p> </li> <li> <p>Sans MVP0 → pas de SaaS crédible (MVP3)</p> </li> <li> <p>Sans MVP0 → pas de réalité augmentée en prompt</p> </li> <li> <p>Sans MVP0 → pas de troisième voie de contexte (SQL DDD)</p> </li> </ul> </div> <div class="paragraph"> <p>Il fait le sale boulot. Il ne sera jamais cité dans les pitchs. Mais c’est lui qui fait tourner l’usine.</p> </div> <div class="paragraph"> <p>Et c’est pour ça qu’on l’embauche en premier.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="références">8. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Article sur l’ontologie spatiale et les cercles de confiance : <a href="../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html">L’Ontologie Spatiale comme Mécanisme d’Alignement</a></p> </li> <li> <p>Article sur la gouvernance agent Eager/Lazy : <a href="../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">Gouverner un Agent IA avec du AsciiDoc</a></p> </li> <li> <p>Article sur le mécanisme Hot/Warm/Cold : <a href="../2026/0110_mecanisme_backup_contexte_agent_post.html">Sliding Window et Vague Froide</a></p> </li> <li> <p>Article sur la comparaison des trois LLMs : <a href="../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html">DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html Thu, 30 Apr 2026 00:00:00 +0000 blog/2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_constat_le_prompt_engineering_est_un_château_de_sable">1. Le Constat : le Prompt Engineering est un Château de Sable</a></li> <li><a href="#les_quatre_cercles_de_confiance_une_ontologie_spatiale">2. Les Quatre Cercles de Confiance : une Ontologie Spatiale</a> <ul class="sectlevel2"> <li><a href="#le_jardin_secret_lespace_hors_cvs">2.1. Le Jardin Secret : l’Espace Hors-CVS</a> <ul class="sectlevel3"> <li><a href="#le_gitignore_comme_configuration_de_gouvernance">2.1.1. Le <code>.gitignore</code> comme Configuration de Gouvernance</a></li> <li><a href="#le_mécanisme_de_snapshot">2.1.2. Le Mécanisme de Snapshot</a></li> </ul> </li> <li><a href="#le_coffre_fort_configuration_comme_spring_cloud_config">2.2. Le Coffre-Fort : <code>configuration/</code> comme Spring Cloud Config</a></li> <li><a href="#la_bibliothèque_office_comme_data_consommable">2.3. La Bibliothèque : <code>office/</code> comme Data Consommable</a></li> <li><a href="#les_forges_foundry_comme_implémentation">2.4. Les Forges : <code>foundry/</code> comme Implémentation</a></li> </ul> </li> <li><a href="#procontra_alignement_spatial_vs_alignement_par_prompt">3. Pro/Contra : Alignement Spatial vs Alignement par Prompt</a> <ul class="sectlevel2"> <li><a href="#approche_classique_alignement_par_pré_prompt">3.1. Approche Classique : Alignement par Pré-Prompt</a></li> <li><a href="#cette_approche_alignement_par_ontologie_spatiale">3.2. Cette Approche : Alignement par Ontologie Spatiale</a></li> </ul> </li> <li><a href="#lalgèbre_relationnelle_du_workspace_et_le_delta_observable">4. L’Algèbre Relationnelle du Workspace et le Delta Observable</a></li> <li><a href="#le_vecteur_composite_de_contexte_rag_pgvector_graphify">5. Le Vecteur Composite de Contexte : RAG + pgvector + Graphify</a> <ul class="sectlevel2"> <li><a href="#composante_1_rag_langchain4j_postgresql_pgvector">5.1. Composante 1 — RAG LangChain4j + PostgreSQL pgvector</a></li> <li><a href="#composante_2_knowledge_graph_graphify">5.2. Composante 2 — Knowledge Graph Graphify</a></li> <li><a href="#composante_3_graphify_incrémental_épars_agrégeable_consommable">5.3. Composante 3 — Graphify Incrémental : Épars, Agrégeable, Consommable</a></li> </ul> </li> <li><a href="#classification_rgpd_automatique_le_llm_comme_routeur">6. Classification RGPD Automatique : le LLM comme Routeur</a></li> <li><a href="#roadmap_de_lasciidoc_à_langgraph4j">7. Roadmap : de l’AsciiDoc à LangGraph4j</a></li> <li><a href="#ce_que_cette_architecture_résout_et_ce_quelle_ne_résout_pas">8. Ce que Cette Architecture Résout (et ce qu’elle ne Résout pas)</a></li> <li><a href="#conclusion_larchitecture_comme_discours">9. Conclusion : l’Architecture comme Discours</a></li> <li><a href="#références">10. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 20 minutes</div> <p>Le prompt engineering, c’est fragile. À 80 000 tokens, vos règles d’alignement sont noyées dans le bruit, et le LLM oublie ce que vous lui avez demandé en début de conversation. Ma solution ? Ne pas aligner par le texte, mais par l'<strong>espace</strong>. J’ai structuré mon workspace de développement en quatre cercles de confiance concentriques — du jardin secret intime jusqu’aux forges publiques — et chaque cercle est une zone physique du système de fichiers. Le LLM n’a pas besoin qu’on lui rappelle les règles : le chemin du fichier les contient. Voici comment ça fonctionne, et pourquoi cette architecture d’alignement par l’espace est plus résiliente qu’un <code>system prompt</code> de 500 lignes.</p> </div> <div class="paragraph text-right"> <p>C’est un article long.<br> Installez-vous confortablement.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="le_constat_le_prompt_engineering_est_un_château_de_sable">1. Le Constat : le Prompt Engineering est un Château de Sable</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pendant trois semaines, j’ai développé des plugins Gradle avec Opencode, en utilisant trois LLMs différents — Kimi K2.6, GLM-5.1, et DeepSeek-V4-Pro (le seul survivant, mais c’est une autre histoire<a href="0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html">Déjà couverte ici.</a>). Ma méthode de gouvernance agent<a href="0108_gouvernance_agent_opencode_eager_lazy_post.html">Je l’ai documentée en détail dans un précédent article.</a> repose sur des fichiers AsciiDoc — <code>AGENT.adoc</code>, <code>INDEX.adoc</code>, <code>PROMPT_REPRISE.adoc</code> — qui chargent ~30 000 tokens de règles, de backlog et d’historique à chaque début de session.</p> </div> <div class="paragraph"> <p>Et malgré cette infrastructure documentaire, deux choses m’ont frappé :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Le LLM oublie.</strong> Même avec les règles absolues en tête de chaque fichier EAGER, au-delà de 60 000 tokens cumulés (contexte initial + conversation), Kimi K2.6 a commencé à proposer des <code>Write</code> écrasants sur des fichiers de configuration. GLM-5.1 a confondu un token Firebase avec un placeholder à remplacer. Les règles étaient écrites — le LLM ne les <strong>voyait</strong> plus.</p> </li> <li> <p><strong>La gouvernance elle-même devient un problème.</strong> Après avoir implémenté le mécanisme Hot/Warm/Cold<a href="0110_mecanisme_backup_contexte_agent_post.html">Article sur la rotation de backup.</a> pour éviter l’explosion du contexte, mes fichiers EAGER pesaient encore 1414 lignes<a href="0111_audit_contexte_agent_post.html">J’ai documenté cet audit ici.</a>. La gouvernance — conçue pour protéger le LLM de la saturation — saturait le LLM.</p> </li> </ol> </div> <div class="paragraph"> <p>J’avais besoin d’un mécanisme d’alignement qui ne dépende pas du nombre de tokens dans le prompt.</p> </div> <div class="paragraph"> <p>La réponse : arrêter d’aligner par le texte, et commencer à aligner par l'<strong>espace</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="les_quatre_cercles_de_confiance_une_ontologie_spatiale">2. Les Quatre Cercles de Confiance : une Ontologie Spatiale</h2> <div class="sectionbody"> <div class="paragraph"> <p>Mon dossier <code>workspace/</code> (dans <code>~/workspace/</code>) n’est <strong>pas</strong> un dépôt Git. C’est la racine de tout mon travail — code, documentation, formation, infrastructure. Et il est structuré en quatre zones qui ne sont pas des conventions de rangement, mais des <strong>cercles de confiance concentriques</strong> :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 6.6666%;"> <col style="width: 13.3333%;"> <col style="width: 20%;"> <col style="width: 26.6666%;"> <col style="width: 33.3335%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Niveau</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Label</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Zone physique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">CVS</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Visibilité</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">0</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Jardin secret</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>workspace/</code> racine</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucun</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Intime — pensée libre, pas de commit, pas de publication</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Coffre-fort</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>configuration/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Git privé (solo)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Secrets, tokens, archive de vision. Une seule personne.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Bibliothèque</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>office/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Git privé (élargi)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Data pédagogique, SPG/SPD, schémas JSON. Cercle de confiance identifié.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Forges (publiques)</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>foundry/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Git public (Apache 2.0)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Code source, plugins, tests, documentation technique.</p></td> </tr> </tbody> </table> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="ℹ️"></i> </td> <td class="content"> Il n’y a pas de niveau 3 dans le tableau. Le niveau 3 est un niveau <strong>transitoire</strong> : c’est du contenu de <code>office/</code> qui a été anonymisé et est prêt à être publié en open data. Il n’a pas de zone physique propre — c’est un état de la donnée, pas un emplacement. </td> </tr> </table> </div> <div class="paragraph"> <p>Chaque niveau répond à une question précise :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Où déposer une idée qui n’est pas encore prête à être partagée, même avec un cercle restreint ?</strong> → Le jardin secret. Pas de Git. Pas de pression.</p> </li> <li> <p><strong>Où stocker un token API sans qu’il fuie ?</strong> → Le coffre-fort (<code>configuration/</code>). Physiquement isolé. Aucun autre dépôt ne peut le référencer par erreur.</p> </li> <li> <p><strong>Où co-construire un catalogue de formation avec un OF pilote ?</strong> → La bibliothèque (<code>office/</code>). Versionné, collaboratif, mais privé.</p> </li> <li> <p><strong>Où industrialiser un plugin Gradle open source ?</strong> → Les forges (<code>foundry/</code>). Public, forkable, testé en CI.</p> </li> </ul> </div> <div class="paragraph"> <p>Cette ontologie est <strong>consommable par un LLM</strong>. Quand il lit un fichier dans <code>foundry/plantuml-gradle/src/</code>, il sait implicitement : "je suis dans le cercle 4 — code public, tests obligatoires, pas de secrets, pas de données pédagogiques". Il n’a pas besoin d’un prompt qui le lui rappelle.</p> </div> <div class="sect2"> <h3 id="le_jardin_secret_lespace_hors_cvs">2.1. Le Jardin Secret : l’Espace Hors-CVS</h3> <div class="paragraph"> <p>C’est le concept le plus important — et le plus contre-intuitif.</p> </div> <div class="paragraph"> <p>La racine <code>workspace/</code> n’a pas de <code>.git/</code>. Les documents qui y vivent (<code>WORKSPACE_VISION.adoc</code>, <code>WORKSPACE_AS_PRODUCT.adoc</code>, <code>WORKSPACE_ORGANIZATION.adoc</code> — et celui que vous lisez en ce moment, qui en est issu) ne sont pas destinés à être versionnés, partagés, ou même relus par quelqu’un d’autre que moi. Ce sont des <strong>pensées en germination</strong>.</p> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="❗"></i> </td> <td class="content"> <div class="paragraph"> <p>Le jardin secret est <strong>out-of-CVS</strong> par nature. L’absence de versionnage est la condition de la liberté de penser. On n’y écrit pas pour être lu — on y écrit pour clarifier sa propre vision.</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>Mais cette liberté a un coût : un <code>rm</code> accidentel, et c’est des mois de réflexion stratégique qui disparaissent. La solution n’est pas de versionner le jardin (ce serait le détruire) — c’est de le <strong>mirrorer</strong> dans le cercle le plus restreint.</p> </div> <div class="sect3"> <h4 id="le_gitignore_comme_configuration_de_gouvernance">2.1.1. Le <code>.gitignore</code> comme Configuration de Gouvernance</h4> <div class="paragraph"> <p>À la racine de <code>workspace/</code>, un fichier <code>.gitignore</code> minimal déclare la <strong>politique d’historisation</strong> des fichiers du jardin secret :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">.goosehints .goose</code></pre> </div> </div> <div class="paragraph"> <p>Ce <code>.gitignore</code> n’a pas de fonction Git classique (il n’y a pas de <code>.git/</code> à la racine). Il agit comme un <strong>fichier de configuration de gouvernance</strong> qui répond à une question précise : <strong>quels artefacts du jardin secret méritent d’être historisés, et lesquels sont purement transitoires ?</strong></p> </div> <div class="ulist"> <ul> <li> <p>Les fichiers listés dans <code>.gitignore</code> — <code>.goosehints</code>, <code>.goose</code> — sont des artefacts éphémères générés par les agents. Pas de valeur stratégique. Pas d’historisation.</p> </li> <li> <p>Les fichiers <code>.adoc</code> de la racine — <code>WORKSPACE_VISION.adoc</code>, <code>WORKSPACE_ORGANIZATION.adoc</code>, <code>WORKSPACE_AS_PRODUCT.adoc</code>, <code>WHAT_THE_GAMES_BEEN_MISSING.adoc</code>, <code>depots_implementes_strategie.adoc</code>, <code>synthese-LLMs-long-contexte.adoc</code> — ne sont <strong>pas</strong> dans le <code>.gitignore</code>. Ce sont les artefacts à historiser.</p> </li> </ul> </div> <div class="paragraph"> <p>Le <code>.gitignore</code> est le <strong>schéma de gouvernance</strong> : tout ce qui n’y est pas listé est un candidat au snapshot. Et le LLM, en lisant ce fichier, sait exactement ce qui doit être archivé et ce qui peut être ignoré — sans qu’on ait besoin de le lui rappeler dans un prompt.</p> </div> </div> <div class="sect3"> <h4 id="le_mécanisme_de_snapshot">2.1.2. Le Mécanisme de Snapshot</h4> <div class="paragraph"> <p>J’ai créé <code>configuration/vision-archive/</code> : des snapshots datés de tous les <code>.adoc</code> de la racine, commités dans le dépôt privé <code>configuration/</code>. Chaque session de brainstorming produit un snapshot :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">DATE=$(date +%Y-%m-%d) mkdir -p /home/cheroliv/workspace/configuration/vision-archive/$DATE cp /home/cheroliv/workspace/*.adoc /home/cheroliv/workspace/configuration/vision-archive/$DATE/ cd /home/cheroliv/workspace/configuration && git add vision-archive/ && \ git commit -m "vision-archive: snapshot $DATE"</code></pre> </div> </div> <div class="paragraph"> <p>La procédure est déclenchée en fin de session par le LLM lui-même, qui exécute cette tâche globale de routage. Chaque snapshot capture l’état complet de la pensée stratégique à un instant T.</p> </div> <div class="paragraph"> <p>L’historique Git de <code>configuration/</code> devient la <strong>biographie de ma pensée stratégique</strong>. Je peux faire un <code>git log — vision-archive/</code> et voir l’évolution de ma vision, session par session, date par date.</p> </div> <div class="paragraph"> <p>Exemple réel de l’historique après une journée de travail :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">$ git -C configuration log --oneline -- vision-archive/ 1089d1b vision-archive: fin de session finale 2026-05-03 6b21eaf vision-archive: fin de session 2026-05-03-1300 1690f82 vision-archive: post-article 2026-05-03 28e6593 vision-archive: post-migration 2026-05-03 3707b78 vision-archive: snapshot 2026-05-03 — jardin secret initial</code></pre> </div> </div> <div class="paragraph"> <p>Cinq snapshots en une journée. Chacun est un point de restauration. Chacun est un jalon dans la genèse de la stratégie.</p> </div> <div class="paragraph"> <p>Le dossier <code>configuration/vision-archive/latest/</code> contient en permanence une <strong>copie de travail</strong> du dernier snapshot, servant de référence rapide sans avoir à naviguer dans l’historique Git.</p> </div> <div class="paragraph"> <p>Et pour le LLM, c’est un <strong>oracle de cohérence</strong> : quand il observe une contradiction entre l’implémentation actuelle et la vision archivée à une date antérieure, il peut la signaler.</p> </div> </div> </div> <div class="sect2"> <h3 id="le_coffre_fort_configuration_comme_spring_cloud_config">2.2. Le Coffre-Fort : <code>configuration/</code> comme Spring Cloud Config</h3> <div class="paragraph"> <p><code>configuration/</code> ne contient pas que l’archive de la vision. Sa fonction première — et future — est d’être un <strong>serveur Spring Cloud Config</strong>. Tous les secrets, tokens, credentials, et descripteurs d’infrastructure vivent ici, dans un dépôt Git privé accessible au seul propriétaire.</p> </div> <div class="paragraph"> <p>Pourquoi un dépôt séparé plutôt qu’un fichier <code>.env</code> dans chaque projet ?</p> </div> <div class="ulist"> <ul> <li> <p><strong>Push accidentel d’un secret</strong> : impossible. Les secrets sont dans un dépôt privé que les projets publics ne peuvent pas référencer par erreur.</p> </li> <li> <p><strong>Audit</strong> : l’historique Git donne la piste de chaque modification de configuration. Qui a changé quoi, quand, avec quel hash SHA.</p> </li> <li> <p><strong>Rollback</strong> : <code>git revert</code> sur une configuration cassée. Instantané, sans backup manuel.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="la_bibliothèque_office_comme_data_consommable">2.3. La Bibliothèque : <code>office/</code> comme Data Consommable</h3> <div class="paragraph"> <p><code>office/</code> est le pendant documentaire du travail de développement. Il contient les articles de blog, les spécifications techniques, les supports de formation (38 répertoires de cours FPA, SPG/SPD, schémas JSON, taxonomies Bloom/Harrow/Krathwohl) — tout ce qui constitue le <strong>matériau pédagogique</strong>.</p> </div> <div class="paragraph"> <p>Mais <code>office/</code> n’est pas qu’un tiroir à docs. C’est une <strong>source de données structurée</strong> que les plugins Gradle de <code>foundry/</code> consomment. Un article de blog dans <code>office/</code> est une entrée qu’un plugin transformera en HTML. Un SPG AsciiDoc dans <code>office/metiers/FPA/</code> est un artefact qu’un orchestrateur parsera pour générer des slides, des quiz, et des capsules vidéo.</p> </div> <div class="paragraph"> <p>Et le <code>build.gradle.kts</code> à la racine de <code>office/</code> n’est pas du code métier — c’est un <strong>script de consommation de l’écosystème de plugins</strong>. Il dit : "voici les plugins Gradle que j’utilise, voici le contexte de mon workspace".</p> </div> </div> <div class="sect2"> <h3 id="les_forges_foundry_comme_implémentation">2.4. Les Forges : <code>foundry/</code> comme Implémentation</h3> <div class="paragraph"> <p><code>foundry/</code> contient le <strong>code industrialisé</strong>. 54 dépôts Git, dont 7 actuellement gouvernés par des <code>.agents/</code>. C’est ici que la vision devient exécutable — plugins Gradle, CI/CD, tests JUnit5 + Cucumber.</p> </div> <div class="paragraph"> <p>La relation avec <code>office/</code> est bidirectionnelle :</p> </div> <div class="ulist"> <ul> <li> <p><code>office/</code> → <code>foundry/</code> : les données pédagogiques sont la matière première que les plugins consomment.</p> </li> <li> <p><code>foundry/</code> → <code>office/</code> : les plugins produisent de la data qui enrichit <code>office/</code> — le <code>graph.json</code> de graphify-gradle, les decks slider compilés, les rapports de build.</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="procontra_alignement_spatial_vs_alignement_par_prompt">3. Pro/Contra : Alignement Spatial vs Alignement par Prompt</h2> <div class="sectionbody"> <div class="paragraph"> <p>Comparons les deux approches.</p> </div> <div class="sect2"> <h3 id="approche_classique_alignement_par_pré_prompt">3.1. Approche Classique : Alignement par Pré-Prompt</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 80%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Pro</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Contra</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Simple à mettre en œuvre. Un bloc de texte dans le system prompt.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Fragile au contexte long</strong> : la règle est noyée après 80K tokens.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Fonctionne pour des règles générales (ton, format).</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Non vérifiable</strong> : rien n’empêche le LLM de violer la règle.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Pas besoin de repenser l’architecture du projet.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Non transférable</strong> : chaque repo redéclare les règles.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Purement déclaratif</strong> : le LLM sait qu’il <strong>devrait</strong>, mais rien ne l’empêche.</p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="cette_approche_alignement_par_ontologie_spatiale">3.2. Cette Approche : Alignement par Ontologie Spatiale</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 80%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Pro</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Contra</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Résilient au contexte long</strong> : la règle est dans le chemin du fichier, pas dans un prompt lointain.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Coût d’infrastructure initial</strong> : structurer le workspace en cercles prend du temps.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Vérifiable mécaniquement</strong> : un secret dans <code>foundry/</code> est détectable par <code>git check-ignore</code>.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Nécessite discipline</strong> : un nouveau contributeur doit comprendre les cercles.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Transférable</strong> : un <code>AGENT.adoc</code> standard expose les cercles à tout nouveau projet.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Ne couvre que les contraintes spatiales</strong> — le code style reste dans le prompt.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Sécurité par conception</strong> : un <code>git push</code> depuis <code>foundry/</code> ne peut pas exposer <code>configuration/</code>.</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Consommable par des agents non-LLM</strong> : un orchestrateur Gradle peut router selon le cercle.</p></td> <td class="tableblock halign-left valign-top"></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le gain principal n’est pas défensif (sécurité, visibilité) — il est <strong>créatif</strong>. Quand le LLM travaille dans un espace structuré par une ontologie, il peut faire ce qu’aucun prompt ne lui permet : <strong>observer le delta</strong>.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="lalgèbre_relationnelle_du_workspace_et_le_delta_observable">4. L’Algèbre Relationnelle du Workspace et le Delta Observable</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quand le LLM parcourt <code>foundry/</code>, il dispose d’un <strong>treillis de données structurées</strong> : nœuds (plugins, fichiers, tests, dépendances), arêtes typées (<code>import</code>, <code>depends_on</code>, <code>generates</code>, <code>tests</code>), relations de composition et d’ordre (<code>training-gradle</code> extrait le référentiel → <code>slider-gradle</code> génère les slides → <code>capsule-gradle</code> monte la vidéo).</p> </div> <div class="paragraph"> <p>Cette algèbre n’est écrite nulle part en clair — mais elle est <strong>observable</strong>. Chaque <code>build.gradle.kts</code> expose des dépendances. Chaque <code>INDEX.adoc</code> expose des références croisées.</p> </div> <div class="paragraph"> <p>Le LLM observe cette algèbre et détecte le <strong>delta</strong> : l’écart entre ce que le système sait déjà produire et ce que la vision décrit.</p> </div> <div class="paragraph"> <p>À partir de ce delta, il peut définir des <strong>cartographies d’experts métiers</strong> — CDA (Concepteur Développeur d’Applications, Kotlin/Gradle/JHipster) et FPA (Formateur Professionnel d’Adultes, Pédagogie/Qualiopi/Bloom) — et identifier ce qui manque pour chaque expert.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Expert CDA (Kotlin/Gradle/JHipster) ├── Plugins : jhipster-gradle-plugins, plantuml-gradle, │ codebase-gradle ├── Delta : pas encore de SPG CDA formalisé, │ pas de fine-tuning expert CDA Expert FPA (Pédagogie/Qualiopi/Bloom) ├── Plugins : training-gradle, slider-gradle, │ school-backoffice/forms, capsule-gradle ├── Matériel : 38 modules cours, SPG/SPD, taxonomies └── Delta : parser AsciiDoc→JSON à créer, orchestrateur à coder</code></pre> </div> </div> <div class="paragraph"> <p>Le LLM n’a pas besoin qu’on lui dise quoi faire. Le delta émerge de la structure.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_vecteur_composite_de_contexte_rag_pgvector_graphify">5. Le Vecteur Composite de Contexte : RAG + pgvector + Graphify</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’algèbre relationnelle n’est pas une construction théorique. Elle est <strong>matérialisée</strong> par trois composantes qui forment un <strong>vecteur composite de contexte</strong> pour le LLM.</p> </div> <div class="sect2"> <h3 id="composante_1_rag_langchain4j_postgresql_pgvector">5.1. Composante 1 — RAG LangChain4j + PostgreSQL pgvector</h3> <div class="paragraph"> <p>J’ai déjà LangChain4j en production dans deux plugins : <code>slider-gradle</code> (4 providers LLM) et <code>plantuml-gradle</code> (7 providers). Les embeddings ONNX (AllMiniLmL6V2) indexent les données de <code>office/</code> et le code source de <code>foundry/</code> dans PostgreSQL + pgvector.</p> </div> <div class="paragraph"> <p>Ce RAG opère sur deux dimensions : * <strong>Dimension data</strong> : les documents <code>office/</code> (SPG, articles, formations, schémas JSON) * <strong>Dimension code</strong> : les codebases <code>foundry/</code> (sources Kotlin, tests Cucumber, AGENT.adoc)</p> </div> <div class="paragraph"> <p>L’intersection couvre à la fois le <strong>quoi</strong> (le domaine métier) et le <strong>comment</strong> (l’implémentation).</p> </div> </div> <div class="sect2"> <h3 id="composante_2_knowledge_graph_graphify">5.2. Composante 2 — Knowledge Graph Graphify</h3> <div class="paragraph"> <p>Graphify est intégré dans <code>plantuml-gradle</code> (109 tests, 380/380 PASS) et produit un <code>graph.json</code> — un knowledge graph structuré avec nœuds, arêtes, et communautés détectées automatiquement.</p> </div> <div class="paragraph"> <p>Contrairement au RAG qui opère par similarité vectorielle (flou), le knowledge graph opère par <strong>relations exactes</strong> (déterministe) : <code>graphify query</code> pour les interrogations sémantiques (~50 tokens), <code>graphify path</code> pour naviguer, <code>graphify explain</code> pour expliquer.</p> </div> </div> <div class="sect2"> <h3 id="composante_3_graphify_incrémental_épars_agrégeable_consommable">5.3. Composante 3 — Graphify Incrémental : Épars, Agrégeable, Consommable</h3> <div class="paragraph"> <p>C’est la décision architecturale clé.</p> </div> <div class="paragraph"> <p>Graphify ne doit pas vivre dans un dépôt unique. Il doit vivre de manière <strong>éparse</strong> dans chaque plugin :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Chaque plugin</strong> embarque une tâche Gradle <code>updateKnowledgeGraph</code> qui appelle Graphify <strong>sur son propre scope</strong> et produit un <code>graph.json</code> local.</p> </li> <li> <p><strong>Le build script de <code>office/</code></strong> consomme <code>graphify-gradle</code> avec <code>rootDir = /home/cheroliv/workspace</code> et produit un <code>graph.json</code> <strong>global</strong> qui agrège les graphes locaux.</p> </li> <li> <p><strong>Le RAG de chaque plugin</strong> injecte le <code>graph.json</code> global comme <strong>filtre de contexte</strong> pour les requêtes LLM.</p> </li> </ol> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">TÂCHE GRADLE (dans chaque plugin) ↓ graphify → graph.json (scope local) ↓ office/build.gradle.kts → graph.json (scope global) ↓ RAG pgvector (dans slider, plantuml, codebase...) ↓ ← injection du graph.json comme filtre LLM (deepseek-v4-pro) ↓ ← observation algèbre relationnelle ↓ ← détection delta vs cartographies experts PRIORISATION → prochaine tâche</code></pre> </div> </div> <div class="paragraph"> <p>Résultat : le LLM ne cherche pas dans le vide — il navigue dans un espace structuré par le knowledge graph. Une requête sur "génère un diagramme" sait atteindre les nœuds pertinents du graphe.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="classification_rgpd_automatique_le_llm_comme_routeur">6. Classification RGPD Automatique : le LLM comme Routeur</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’ontologie spatiale ne se contente pas d’aligner le LLM — elle lui donne une <strong>grille de classification RGPD</strong> pour router chaque donnée vers sa zone légitime.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 12.5%;"> <col style="width: 37.5%;"> <col style="width: 25%;"> <col style="width: 25%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Critère</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Détection LLM</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Action</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Niveau max</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Donnée personnelle (nom, email, IP)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pattern <code>@</code>, IP, noms propres</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Anonymiser → <code>[OF_PILOTE]</code> ou router niveau 2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Token / Secret / Credential</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pattern <code>sk-…​</code>, <code>ghp_…​</code>, <code>ya29…​</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Router → <code>configuration/</code>. Référencer par <code>${VAR}</code> dans le code.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">URL interne</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Contient <code>localhost</code>, IP privée</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Anonymiser → <code>${API_URL}</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Donnée pédagogique (SPG, cours)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Structure Bloom/Qualiopi</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Router → <code>office/</code> (niveau 2). Double version si export.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Code source / test</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Extension <code>.kt</code>, <code>.kts</code> dans <code>foundry/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Router → <code>foundry/</code>. Vérifier absence de secrets.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">4</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>En fin de session, le LLM exécute une <strong>tâche globale</strong> :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Lecture du <code>.gitignore</code> racine pour identifier les artefacts éphémères (à exclure du snapshot) vs les artefacts stratégiques (à historiser)</p> </li> <li> <p>Inventaire de tous les fichiers <code>.adoc</code> de la racine <code>workspace/</code></p> </li> <li> <p>Filtrage : exclusion des fichiers listés dans <code>.gitignore</code>, inclusion de tous les autres</p> </li> <li> <p>Copie dans <code>configuration/vision-archive/$DATE/</code> et mise à jour du symlink <code>latest/</code></p> </li> <li> <p>Commit dans le dépôt <code>configuration/</code> avec un message structuré</p> </li> <li> <p>Classification RGPD automatique de chaque fichier modifié (tous cercles)</p> </li> <li> <p>Routage : données <code>office/</code> → commit privé, code <code>foundry/</code> → <code>./gradlew check</code>, configuration → commit</p> </li> <li> <p>Rapport structuré avec alertes RGPD et confirmation d’archivage</p> </li> </ol> </div> <div class="paragraph"> <p>Le <code>.gitignore</code> racine n’est pas un fichier de configuration Git — c’est un <strong>fichier de gouvernance de l’historisation</strong>. Il définit le schéma que le LLM consomme pour décider quels fichiers du jardin secret entrent dans la biographie stratégique et lesquels sont jetables.</p> </div> <div class="paragraph"> <p>Le LLM n’est plus un simple générateur de texte. Il est le <strong>gestionnaire d’information</strong> de l’écosystème — producteur, classifieur, routeur.</p> </div> </div> </div> <div class="sect1"> <h2 id="roadmap_de_lasciidoc_à_langgraph4j">7. Roadmap : de l’AsciiDoc à LangGraph4j</h2> <div class="sectionbody"> <div class="paragraph"> <p>Aujourd’hui, cette gouvernance est <strong>déterministe</strong> : le LLM applique une procédure décrite dans des fichiers AsciiDoc. C’est la <strong>phase 1</strong> — le prompt engineering avec mémoire LLM.</p> </div> <div class="paragraph"> <p>La <strong>phase 2</strong> extraira chaque étape de la procédure dans une <strong>tâche Gradle typée</strong> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">./gradlew endSessionWorkspace → snapshot vision-archive ./gradlew endSessionProject → archive .agents/ ./gradlew endSessionReport → rapport multi-zones</code></pre> </div> </div> <div class="paragraph"> <p>La <strong>phase 3</strong> modélisera le processus de fin de session comme un <strong>graphe d’état</strong> avec <a href="https://github.com/langgraph4j/langgraph4j">LangGraph4j</a> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">[Start] → [Inventaire fichiers modifiés] → [Classification RGPD] (nœud ONNX) → [Branchement par cercle] ├→ cercle 0 → snapshot → commit ├→ cercle 2 → anonymisation → commit ├→ cercle 4 → archive → commit └→ cercle 1 → commit configuration/ → [Rapport] → [End]</code></pre> </div> </div> <div class="paragraph"> <p>Ce graphe sera versionné dans la CI/CD, exécuté par Gradle, configuré via les GitHub Secrets des plugins. Le LLM n’aura plus à décider du routage — le graphe le fera.</p> </div> </div> </div> <div class="sect1"> <h2 id="ce_que_cette_architecture_résout_et_ce_quelle_ne_résout_pas">8. Ce que Cette Architecture Résout (et ce qu’elle ne Résout pas)</h2> <div class="sectionbody"> <div class="admonitionblock caution"> <table> <tr> <td class="icon"> <i class="fa icon-caution" title="🔒"></i> </td> <td class="content"> <div class="paragraph"> <p>L’ontologie spatiale ne couvre pas tout. Les conventions de code style, le nommage, les choix de design architectural — tout ça reste dans le prompt. Ce que l’ontologie spatiale résout, c’est la <strong>couche de sécurité et de visibilité</strong> : où chaque octet doit vivre, et qui peut le voir.</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>Voici ce qu’elle apporte concrètement :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Pas de <code>git push</code> accidentel d’un secret</strong> : les secrets sont dans <code>configuration/</code> (cercle 1). Les projets publics sont dans <code>foundry/</code> (cercle 4). Aucun chemin ne traverse les deux.</p> </li> <li> <p><strong>Pas de code métier dans la data</strong> : <code>office/</code> contient des <code>.adoc</code>, des YAML, des JSON Schemas — mais pas de <code>.kt</code>. Le <code>build.gradle.kts</code> qui y vit est un script de consommation, pas du code métier.</p> </li> <li> <p><strong>Pas de pensée stratégique exposée</strong> : les documents de vision vivent dans le jardin secret (racine hors-CVS). Les snapshots sont dans <code>configuration/</code> (coffre-fort privé). Personne, même en cercle de confiance élargi, ne lit la genèse de la stratégie.</p> </li> <li> <p><strong>Auto-priorisation</strong> : le LLM observe le delta entre l’algèbre relationnelle (ce qui existe) et les cartographies d’experts (ce qui est nécessaire). La prochaine tâche de développement émerge de ce delta.</p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_larchitecture_comme_discours">9. Conclusion : l’Architecture comme Discours</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je ne mets pas de manifeste politique dans le footer de mon site. Je ne mets pas de règles éthiques dans mes prompts. L’alignement n’est pas dans le texte — il est dans le <strong>système de fichiers</strong>.</p> </div> <div class="paragraph"> <p>Quand un LLM travaille dans cet espace, il ne peut pas fuiter un secret (le chemin l’en empêche). Il ne peut pas confondre une donnée pédagogique avec du code source (la zone physique est différente). Il ne peut pas oublier une règle de sécurité à 80 000 tokens — parce que la règle n’est pas dans le prompt, elle est dans le <code>workspace/</code> → <code>configuration/</code> → <code>office/</code> → <code>foundry/</code> que chaque lecture de fichier réactive.</p> </div> <div class="paragraph"> <p>C’est le principe de la <strong>secure by design</strong> appliqué à l’alignement agent : ne pas demander au LLM de se souvenir des règles. Faire en sorte que l’architecture rende l’erreur structurellement impossible.</p> </div> <div class="paragraph"> <p>Et au passage, ça donne au LLM ce qu’aucun prompt ne peut lui donner : la capacité de <strong>percevoir</strong> où il est, ce qui existe, ce qui manque — et d’en déduire ce qu’il doit faire.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="références">10. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Article sur la gouvernance agent Eager/Lazy : <a href="../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">Gouverner un Agent IA avec du AsciiDoc</a></p> </li> <li> <p>Article sur le mécanisme Hot/Warm/Cold : <a href="../2026/0110_mecanisme_backup_contexte_agent_post.html">Sliding Window et Vague Froide</a></p> </li> <li> <p>Article sur l’audit de contexte : <a href="../2026/0111_audit_contexte_agent_post.html">Quand Votre Propre Gouvernance Devient le Probleme</a></p> </li> <li> <p>Article sur la comparaison des trois LLMs : <a href="../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html">DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0113_integration_firebase_contact_form_post.html Wed, 29 Apr 2026 00:00:00 +0000 blog/2026/0113_integration_firebase_contact_form_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#la_scène_un_formulaire_qui_ne_stocke_rien">1. La scène : un formulaire qui ne stocke rien</a> <ul class="sectlevel2"> <li><a href="#lhéritage_supabase">1.1. L’héritage Supabase</a></li> <li><a href="#la_double_soumission_fantôme">1.2. La double soumission fantôme</a></li> </ul> </li> <li><a href="#pourquoi_firebase_plutôt_que_supabase">2. Pourquoi Firebase plutôt que Supabase ?</a></li> <li><a href="#phase_1_créer_le_projet_firebase">3. Phase 1 : Créer le projet Firebase</a> <ul class="sectlevel2"> <li><a href="#initialisation">3.1. Initialisation</a></li> <li><a href="#règles_de_sécurité_firestore">3.2. Règles de sécurité Firestore</a></li> </ul> </li> <li><a href="#phase_2_réécrire_le_javascript_de_soumission">4. Phase 2 : Réécrire le JavaScript de soumission</a> <ul class="sectlevel2"> <li><a href="#la_dépendance_window_firebase">4.1. La dépendance <code>window.<em>FIREBASE</em></code></a></li> <li><a href="#le_nouveau_contact_js">4.2. Le nouveau <code>contact.js</code></a></li> </ul> </li> <li><a href="#phase_3_nettoyer_le_code_mort_supabase">5. Phase 3 : Nettoyer le code mort Supabase</a></li> <li><a href="#phase_4_configurer_le_footer">6. Phase 4 : Configurer le footer</a></li> <li><a href="#phase_5_architecture_finale">7. Phase 5 : Architecture finale</a></li> <li><a href="#ce_que_cette_migration_dit_du_dogfooding">8. Ce que cette migration dit du dogfooding</a> <ul class="sectlevel2"> <li><a href="#récapitulatif_des_modifications">8.1. Récapitulatif des modifications</a></li> </ul> </li> <li><a href="#prochaines_étapes_backlog">9. Prochaines étapes (backlog)</a></li> <li><a href="#références">10. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 12 minutes</div> <p>Pendant des mois, le formulaire de contact de ce site a tourné sur un mock JavaScript — une promesse à 85 % de succès, un faux Firestore, zéro données stockées. Le plan initial prévoyait un backend Supabase avec Google Apps Script pour les notifications mail. Abandonné. Aujourd’hui, je raconte la migration vers Firebase Firestore : création du projet, règles de sécurité, réécriture du JS, nettoyage du code mort Supabase. Et pourquoi ce choix dit quelque chose de plus large sur la philosophie de développement.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="la_scène_un_formulaire_qui_ne_stocke_rien">1. La scène : un formulaire qui ne stocke rien</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce site est généré par JBake, mon plugin Gradle <code>bakery</code>. Il est 100 % statique — pas de backend, pas de base de données. Sauf que j’ai un formulaire de contact. La page <code>contact.html</code> existe, le HTML est prêt (champs nom, email, téléphone, sujet, message, validation HTML5, honeypot anti-spam), les styles Bootstrap sont en place. Visuellement, tout est parfait.</p> </div> <div class="paragraph"> <p>Sauf qu’à la soumission, rien ne se passe.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-javascript hljs" data-lang="javascript">const firebaseMock = new Promise((resolve, reject) => { setTimeout(() => { if (Math.random() < 0.85) { resolve({ status: 201, message: 'Message stored in Firestore.' }); } else { reject({ status: 500, message: 'Firestore write failed.' }); } }, 1500); });</code></pre> </div> </div> <div class="paragraph"> <p>Un mock. Une promesse qui fait semblant. L’utilisateur voit un spinner, puis un message « Message envoyé avec succès ! ». Mais les données partent dans le vide. Aucun message n’est stocké nulle part.</p> </div> <div class="paragraph"> <p>La situation est pire qu’un formulaire cassé — c’est un formulaire qui ment.</p> </div> <div class="sect2"> <h3 id="lhéritage_supabase">1.1. L’héritage Supabase</h3> <div class="paragraph"> <p>Le plan initial, documenté dans <code>content/draft/integration_formulaire_contact_supabase.adoc</code>, prévoyait :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Une base Supabase avec table <code>contacts</code> et Row Level Security</p> </li> <li> <p>Une RPC <code>handle_contact_form</code> côté serveur</p> </li> <li> <p>Un trigger SQL appelant un webhook Google Apps Script</p> </li> <li> <p>Google Apps Script qui envoie un mail Gmail de notification</p> </li> </ol> </div> <div class="paragraph"> <p>Le code JavaScript correspondant existe encore dans <code>script.js</code>. Il y a une classe <code>SupabaseManager</code> qui initialise un client Supabase avec des variables globales <code>SUPABASE_URL</code> et <code>SUPABASE_KEY</code>, et une classe <code>ContactFormHandler</code> qui écoute l’événement submit du formulaire et appelle <code>SupabaseManager.submitContactForm()</code>.</p> </div> <div class="paragraph"> <p>Problème : ces variables globales ne sont plus injectées dans le footer. Le <code><script src="supabase-js"></code> a été retiré. Le code appelle <code>supabase.createClient()</code> sur une variable <code>supabase</code> qui n’existe plus. Donc :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">console.error : 'Supabase client library (supabase-js) is not loaded.'</code></pre> </div> </div> <div class="paragraph"> <p>Non seulement les données ne sont pas stockées, mais le code de soumission est mort.</p> </div> </div> <div class="sect2"> <h3 id="la_double_soumission_fantôme">1.2. La double soumission fantôme</h3> <div class="paragraph"> <p>Pour empirer les choses, il y a une <strong>concurrence silencieuse</strong> entre deux handlers sur le même formulaire :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><code>contact.js</code> écoute le submit, appelle le mock Firebase</p> </li> <li> <p><code>script.js</code> — via <code>ContactFormHandler</code> — écoute aussi le submit, appelle <code>SupabaseManager</code></p> </li> </ol> </div> <div class="paragraph"> <p>Les deux font <code>event.preventDefault() + event.stopPropagation()</code>. Comme <code>contact.js</code> est chargé en premier dans <code>footer.thyme</code>, son handler est attaché en premier. Il bloque la propagation. <code>ContactFormHandler</code> ne sera jamais déclenché.</p> </div> <div class="paragraph"> <p>Ce n’est même pas un bug actif — c’est un zombie. Du code qui n’a jamais l’occasion de s’exécuter.</p> </div> <div id="diag-before" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-1dca60606b3e7ccf37af78f090e4df27.svg" alt="État initial — double handler et mock" width="1972" height="215"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_firebase_plutôt_que_supabase">2. Pourquoi Firebase plutôt que Supabase ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>La décision de migration est documentée dans <code>AGENT.adoc</code> :</p> </div> <div class="quoteblock"> <blockquote> Firebase est désormais choisi pour les raisons suivantes : meilleur plan gratuit, Firestore natif, Cloud Functions intégrées, écosystème Google plus adapté. L’implémentation Supabase existante est marquée « ⚠️ Abandonné ». </blockquote> <div class="attribution"> — AGENT.adoc </div> </div> <div class="paragraph"> <p>Au-delà du plan gratuit, il y a une raison architecturale. Ce site vit dans l’écosystème Google : le dépôt cible est <code>cheroliv.github.io</code>, le CNAME pointe sur GitHub Pages, le build Gradle push sur GitHub via JGit. Ajouter un service Google (Firebase) plutôt qu’un service tiers (Supabase) réduit la surface de dispersion.</p> </div> <div class="paragraph"> <p>Firestore en mode natif (pas en mode Datastore) est aussi plus proche du modèle mental NoSQL document que j’ai en tête : collections, documents, champs typés, timestamps serveur, règles de sécurité intégrées.</p> </div> </div> </div> <div class="sect1"> <h2 id="phase_1_créer_le_projet_firebase">3. Phase 1 : Créer le projet Firebase</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="initialisation">3.1. Initialisation</h3> <div class="paragraph"> <p>La CLI Firebase n’étant pas installée sur ma machine, je passe par la console web :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Aller sur <a href="https://console.firebase.google.com/">Firebase Console</a></p> </li> <li> <p>Créer un projet <code>cheroliv-contact</code> (ou réutiliser un projet existant)</p> </li> <li> <p>Activer Firestore en mode natif (pas Datastore)</p> </li> <li> <p>Créer une base de données en région <code>eur3</code> (Europe)</p> </li> </ol> </div> <div class="paragraph"> <p>Pour un usage minimaliste comme le nôtre (une seule collection, écriture publique), le mode natif est le bon choix. Pas besoin de règles Datastore complexes.</p> </div> </div> <div class="sect2"> <h3 id="règles_de_sécurité_firestore">3.2. Règles de sécurité Firestore</h3> <div class="paragraph"> <p>Le formulaire est public — n’importe qui peut envoyer un message. Mais je veux limiter les abus :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-javascript hljs" data-lang="javascript">rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /contact_messages/{messageId} { // Lecture : admin uniquement (authentifié) allow read: if request.auth != null; // Écriture : publique, mais limitée allow create: if request.auth == null && request.resource.data.name is string && request.resource.data.name.size() >= 1 && request.resource.data.name.size() <= 100 && request.resource.data.email is string && request.resource.data.email.matches('.*@.*\\..*') && request.resource.data.email.size() <= 254 && request.resource.data.subject is string && request.resource.data.subject.size() >= 3 && request.resource.data.subject.size() <= 200 && request.resource.data.message is string && request.resource.data.message.size() >= 10 && request.resource.data.message.size() <= 5000 && request.resource.data.created_at == request.time && request.resource.data.user_agent is string && request.resource.data.user_agent.size() <= 500; } } }</code></pre> </div> </div> <div class="paragraph"> <p>Points clés :</p> </div> <div class="ulist"> <ul> <li> <p><code>allow read</code> — seuls les utilisateurs authentifiés peuvent lire les messages (moi, via la console Firebase)</p> </li> <li> <p><code>allow create</code> — n’importe qui peut créer un document, mais avec validation des champs</p> </li> <li> <p>Validation côté serveur : tailles min/max, format email, <code>created_at</code> doit correspondre à <code>request.time</code> (anti-falsification)</p> </li> <li> <p><code>user_agent</code> est envoyé pour traçabilité (pas critique mais utile)</p> </li> </ul> </div> <div class="paragraph"> <p>Ces règles sont plus strictes qu’un simple <code>allow write: if true;</code>. Elles empêchent un attaquant d’injecter des payloads énormes ou des champs mal formés.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="phase_2_réécrire_le_javascript_de_soumission">4. Phase 2 : Réécrire le JavaScript de soumission</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le contrat est simple :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Lire les données du formulaire</p> </li> <li> <p>Vérifier le honeypot (champ <code>hp_name</code> — s’il est rempli, c’est un bot, on simule un succès sans rien envoyer)</p> </li> <li> <p>Appeler <code>addDoc(window.<em>FIREBASE</em>.collection(db, "contact_messages"), {…​})</code></p> </li> <li> <p>Afficher succès ou erreur</p> </li> </ol> </div> <div class="sect2"> <h3 id="la_dépendance_window_firebase">4.1. La dépendance <code>window.<em>FIREBASE</em></code></h3> <div class="paragraph"> <p>Dans <code>footer.thyme</code>, un script module initialise Firebase SDK et expose un objet global :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><script type="module"> import { initializeApp } from "https://www.gstatic.com/firebasejs/11.6.0/firebase-app.js"; import { getFirestore, collection, addDoc, serverTimestamp } from "https://www.gstatic.com/firebasejs/11.6.0/firebase-firestore.js"; const firebaseConfig = { /* valeurs réelles */ }; const app = initializeApp(firebaseConfig); const db = getFirestore(app); window.__FIREBASE__ = { db, collection, addDoc, serverTimestamp }; </script></code></pre> </div> </div> <div class="paragraph"> <p>Les scripts module s’exécutent avant <code>DOMContentLoaded</code>, donc <code>window.<em>FIREBASE</em></code> est garanti disponible quand le handler <code>contact.js</code> se déclenche. Par précaution, j’ajoute quand même un polling de 5 secondes au cas où le CDN serait lent.</p> </div> </div> <div class="sect2"> <h3 id="le_nouveau_contact_js">4.2. Le nouveau <code>contact.js</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-javascript hljs" data-lang="javascript">document.addEventListener('DOMContentLoaded', function () { 'use strict'; const form = document.getElementById('contact-form'); if (!form) return; const submitButton = form.querySelector('button[type="submit"]'); const successMessage = document.getElementById('contact-success-message'); const errorMessage = document.getElementById('contact-error-message'); // Éléments de validation const nameInput = form.querySelector('input[name="name"]'); const emailInput = form.querySelector('input[name="email"]'); const phoneInput = form.querySelector('input[name="phone"]'); const subjectInput = form.querySelector('input[name="subject"]'); const messageInput = form.querySelector('textarea[name="message"]'); const honeypotInput = form.querySelector('input[name="hp_name"]'); /** * Attend que window.__FIREBASE__ soit disponible. * Timeout de 5 secondes — si le CDN Firebase est lent, on abandonne. */ function waitForFirebase(timeoutMs = 5000) { return new Promise((resolve, reject) => { if (window.__FIREBASE__) { resolve(window.__FIREBASE__); return; } const start = Date.now(); const interval = setInterval(() => { if (window.__FIREBASE__) { clearInterval(interval); resolve(window.__FIREBASE__); } else if (Date.now() - start > timeoutMs) { clearInterval(interval); reject(new Error('Firebase SDK non disponible après timeout')); } }, 100); }); } // --- Validation (identique à l'existant) --- function validateForm() { nameInput.setCustomValidity(''); emailInput.setCustomValidity(''); if (phoneInput) phoneInput.setCustomValidity(''); subjectInput.setCustomValidity(''); messageInput.setCustomValidity(''); if (nameInput.value.trim().length < 1) { nameInput.setCustomValidity('Veuillez saisir votre nom.'); } const emailPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; if (!emailPattern.test(emailInput.value.trim())) { emailInput.setCustomValidity('Veuillez saisir une adresse email valide.'); } if (phoneInput && phoneInput.value.trim() !== '') { const phonePattern = /^\d{10,15}$/; if (!phonePattern.test(phoneInput.value.trim())) { phoneInput.setCustomValidity('Veuillez saisir un numéro valide (10 à 15 chiffres).'); } } if (subjectInput.value.trim().length < 3) { subjectInput.setCustomValidity('Veuillez saisir un sujet (3 caractères minimum).'); } if (messageInput.value.trim().length < 10) { messageInput.setCustomValidity('Veuillez saisir un message (10 caractères minimum).'); } form.classList.add('was-validated'); return form.checkValidity(); } // --- Handler de soumission --- form.addEventListener('submit', async function (event) { event.preventDefault(); event.stopPropagation(); if (!validateForm()) return; // Honeypot : si rempli, simuler un succès sans rien envoyer if (honeypotInput && honeypotInput.value.trim() !== '') { successMessage.style.display = 'block'; form.reset(); form.classList.remove('was-validated'); return; } // UI : état d'envoi submitButton.disabled = true; submitButton.innerHTML = ` <span class="spinner-border spinner-border-sm" role="status" aria-hidden="true"></span> Envoi en cours... `; successMessage.style.display = 'none'; errorMessage.style.display = 'none'; try { const fb = await waitForFirebase(); const messagesCollection = fb.collection(fb.db, 'contact_messages'); await fb.addDoc(messagesCollection, { name: nameInput.value.trim(), email: emailInput.value.trim(), phone: phoneInput ? phoneInput.value.trim() : '', subject: subjectInput.value.trim(), message: messageInput.value.trim(), created_at: fb.serverTimestamp(), user_agent: navigator.userAgent.substring(0, 500) }); successMessage.style.display = 'block'; form.reset(); form.classList.remove('was-validated'); } catch (error) { console.error('Erreur Firestore:', error); errorMessage.style.display = 'block'; } finally { submitButton.disabled = false; submitButton.innerHTML = ` <i class="bi bi-send me-2"></i> Envoyer le Message `; } }, false); });</code></pre> </div> </div> <div class="paragraph"> <p>Les changements par rapport au mock :</p> </div> <div class="ulist"> <ul> <li> <p><code>waitForFirebase()</code> — polling avec timeout, robuste même si le CDN est lent</p> </li> <li> <p><code>honeypot</code> — si le champ caché <code>hp_name</code> est rempli, simuler un succès sans appel Firestore. Le bot croit avoir réussi mais rien n’est stocké</p> </li> <li> <p><code>addDoc(collection, {…​})</code> — vrai appel Firestore avec <code>serverTimestamp()</code> et <code>user_agent</code></p> </li> <li> <p>Gestion d’erreur avec <code>try/catch</code> asynchrone</p> </li> <li> <p>Nettoyage du <code>finally</code> (restauration du bouton)</p> </li> </ul> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Pourquoi <code>user_agent</code> ? C’est optionnel, mais utile pour le diagnostic. Si un message étrange arrive, savoir si ça vient d’un navigateur desktop, mobile, ou d’un script curl aide au tri.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="phase_3_nettoyer_le_code_mort_supabase">5. Phase 3 : Nettoyer le code mort Supabase</h2> <div class="sectionbody"> <div class="paragraph"> <p><code>script.js</code> contient 250 lignes de dead code :</p> </div> <div class="ulist"> <ul> <li> <p><code>SupabaseManager</code> (lignes 417-481) — 65 lignes</p> </li> <li> <p><code>ContactFormHandler</code> (lignes 490-551) — 62 lignes</p> </li> <li> <p>Bloc d’initialisation (lignes 645-654) — 10 lignes</p> </li> </ul> </div> <div class="paragraph"> <p>Total : ~140 lignes à supprimer.</p> </div> <div class="paragraph"> <p>Le bloc <code>DOMContentLoaded</code> crée un <code>SupabaseManager</code> puis un <code>ContactFormHandler</code> rattaché au formulaire. Comme expliqué plus haut, ce code ne s’exécute jamais (bloqué par <code>contact.js</code>), et même s’il s’exécutait, il échouerait (pas de SDK Supabase chargé).</p> </div> <div class="paragraph"> <p>Je supprime :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>La classe <code>SupabaseManager</code></p> </li> <li> <p>La classe <code>ContactFormHandler</code></p> </li> <li> <p>Le bloc d’initialisation dans <code>DOMContentLoaded</code> (lignes 645-654)</p> </li> </ol> </div> <div class="paragraph"> <p>Le reste de <code>script.js</code> est intact : <code>ThemeManager</code>, <code>ScrollToTopButton</code>, <code>MobileMenuManager</code>, <code>SmoothScrollWithOffset</code>, <code>NavbarHeightUpdater</code>, <code>DynamicNavbarBreakpoint</code>, <code>CodeBlockManager</code>, <code>TooltipManager</code>, <code>PhoneInputManager</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="phase_4_configurer_le_footer">6. Phase 4 : Configurer le footer</h2> <div class="sectionbody"> <div class="paragraph"> <p><code>footer.thyme</code> a déjà le boilerplate Firebase mais avec des valeurs placeholder. Je remplace :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-javascript hljs" data-lang="javascript">const firebaseConfig = { apiKey: "REMPLACER_PAR_VOTRE_API_KEY", authDomain: "REMPLACER_PAR_VOTRE_AUTH_DOMAIN", projectId: "REMPLACER_PAR_VOTRE_PROJECT_ID", storageBucket: "REMPLACER_PAR_VOTRE_STORAGE_BUCKET", messagingSenderId: "REMPLACER_PAR_VOTRE_SENDER_ID", appId: "REMPLACER_PAR_VOTRE_APP_ID" };</code></pre> </div> </div> <div class="paragraph"> <p>Par les valeurs réelles récupérées depuis <strong>Project Settings > General > Your apps > Web app</strong> dans la console Firebase.</p> </div> <div class="paragraph"> <p>Les valeurs sont sensibles (<code>apiKey</code> est publique par design chez Firebase, mais je préfère ne pas les commiter en clair). Je les stocke dans <code>site.yml</code> (déjà dans <code>.gitignore</code>) et le plugin <code>bakery</code> les injecte dans le template via une logique à ajouter côté build.</p> </div> <div class="paragraph"> <p>Pour l’instant, je les mets directement dans <code>footer.thyme</code> — le build <code>./gradlew serve</code> les chargera localement. Au déploiement, je migrerai l’injection vers <code>site.yml</code> ou vers une variable Gradle.</p> </div> <div class="admonitionblock warning"> <table> <tr> <td class="icon"> <i class="fa icon-warning" title="Warning"></i> </td> <td class="content"> <div class="paragraph"> <p>L'`apiKey` Firebase n’est <strong>pas</strong> un secret. Elle est publique par conception. Ce qui protège vos données, ce sont les <strong>règles de sécurité Firestore</strong>, pas la clé API. Ne la mettez pas dans un <code>.env</code> chargé côté serveur — elle est destinée à être exposée au navigateur.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="phase_5_architecture_finale">7. Phase 5 : Architecture finale</h2> <div class="sectionbody"> <div id="diag-after" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-97da02b2e5039b13e18110950d9d0e1b.svg" alt="Architecture finale — Firebase Firestore" width="512" height="505"> </div> </div> </div> </div> <div class="sect1"> <h2 id="ce_que_cette_migration_dit_du_dogfooding">8. Ce que cette migration dit du dogfooding</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce site est généré par mon propre plugin Gradle <code>bakery</code>. Le formulaire de contact vit à l’intérieur du site. La migration Supabase → Firebase est documentée dans <code>AGENT.adoc</code>, elle est discutée dans le backlog, elle est testée via <code>./gradlew serve</code>, et elle génère un article de blog (celui que vous lisez).</p> </div> <div class="paragraph"> <p>C’est du dogfooding pur. Le site est le produit du plugin, le plugin est le produit du développeur, le développeur documente le processus dans le site lui-même.</p> </div> <div class="paragraph"> <p>La boucle est bouclée.</p> </div> <div class="paragraph"> <p>Le fait d’avoir traîné un mock pendant des mois (des sessions entières où le formulaire mentait silencieusement) m’a fait réaliser quelque chose : le backlog d’un site statique personnel n’est jamais « fini ». Il y a toujours une US prioritaire, toujours un article en draft, toujours une section commentée dans un template. La discipline n’est pas de tout finir — c’est de finir ce qui est visible par l’utilisateur.</p> </div> <div class="paragraph"> <p>Un formulaire de contact cassé, c’est pire que pas de formulaire du tout. C’est une promesse non tenue.</p> </div> <div class="sect2"> <h3 id="récapitulatif_des_modifications">8.1. Récapitulatif des modifications</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 16.6666%;"> <col style="width: 50%;"> <col style="width: 33.3334%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Fichier</th> <th class="tableblock halign-left valign-top">Modification</th> <th class="tableblock halign-left valign-top">Impact</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>blog/2026/0113_*.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Création de l’article</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Documentation</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>assets/js/contact.js</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Réécriture (mock → Firestore réel)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fonctionnel</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>assets/js/script.js</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Suppression SupabaseManager + ContactFormHandler + init bloc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Nettoyage</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>templates/footer.thyme</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Remplacement config placeholder → valeurs réelles</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Configuration</p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="prochaines_étapes_backlog">9. Prochaines étapes (backlog)</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><strong>Notification email</strong> : Une Cloud Function <code>onCreate</code> sur <code>contact_messages</code> qui envoie un mail via SendGrid. Le formulaire stocke, mais je ne suis pas notifié. Priorité moyenne — les messages sont visibles dans la console Firebase.</p> </li> <li> <p><strong>Rate limiting côté client</strong> : Ajouter un timestamp localStorage pour empêcher les soumissions multiples en rafale. Le honeypot bloque les bots naïfs, un rate limiter bloquerait les bots un peu plus malins.</p> </li> <li> <p><strong>Tests</strong> : Un test Playwright qui soumet le formulaire et vérifie que le document apparaît dans Firestore. Pour l’instant, je teste manuellement via <code>./gradlew serve</code>.</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="références">10. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://firebase.google.com/docs/firestore/security/get-started">Documentation Firestore Security Rules</a></p> </li> <li> <p><a href="https://firebase.google.com/docs/firestore/manage-data/add-data#add_a_document">Documentation Firestore addDoc — Web v9 modulaire</a></p> </li> <li> <p><a href="/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">Série gouvernance agent — Partie 1 : Eager/Lazy</a></p> </li> <li> <p><a href="/blog/2026/0110_mecanisme_backup_contexte_agent_post.html">Série gouvernance agent — Partie 2 : Hot/Warm/Cold</a></p> </li> <li> <p><a href="/blog/2026/0111_audit_contexte_agent_post.html">Série gouvernance agent — Partie 3 : Audit</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html Tue, 28 Apr 2026 00:00:00 +0000 blog/2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#contexte_pas_un_banc_dessai_un_chantier">1. Contexte : pas un banc d’essai, un chantier</a></li> <li><a href="#mon_environnement_de_test">2. Mon environnement de test</a></li> <li><a href="#la_grille_dévaluation">3. La Grille d’Évaluation</a></li> <li><a href="#round_1_kimi_k2_6_le_faux_départ">4. Round 1 : Kimi K2.6 — Le Faux Départ</a> <ul class="sectlevel2"> <li><a href="#session_9_lembellie">4.1. Session 9 : l’embellie</a></li> <li><a href="#session_10_le_naufrage_silencieux">4.2. Session 10 : le naufrage silencieux</a></li> </ul> </li> <li><a href="#round_2_glm_5_1_le_combattant_honorable">5. Round 2 : GLM-5.1 — Le Combattant Honorable</a> <ul class="sectlevel2"> <li><a href="#architecture_le_dsa_contre_le_mla_pur">5.1. Architecture : le DSA contre le MLA pur</a></li> <li><a href="#sessions_11_13_solide_mais_frustrant">5.2. Sessions 11-13 : solide mais frustrant</a></li> </ul> </li> <li><a href="#round_3_deepseek_v4_pro_la_machine_de_guerre">6. Round 3 : DeepSeek-V4-Pro — La Machine de Guerre</a> <ul class="sectlevel2"> <li><a href="#architecture_csa_hca_le_double_filet">6.1. Architecture : CSA + HCA, le double filet</a></li> <li><a href="#sessions_1_8_le_soulagement">6.2. Sessions 1-8 : le soulagement</a></li> <li><a href="#le_test_décisif_refactoring_à_100k_tokens">6.3. Le test décisif : refactoring à 100K tokens</a></li> </ul> </li> <li><a href="#le_face_à_face_metrics_comparatives">7. Le Face-à-Face : Metrics Comparatives</a></li> <li><a href="#pourquoi_deepseek_v4_pro_gagne_en_développement_logiciel">8. Pourquoi DeepSeek-V4-Pro Gagne en Développement Logiciel</a> <ul class="sectlevel2"> <li><a href="#1_larchitecture_csahca_est_taillée_pour_le_code">8.1. 1. L’architecture CSA+HCA est taillée pour le code</a></li> <li><a href="#2_le_contexte_eager_est_sa_zone_de_confort">8.2. 2. Le contexte EAGER est sa zone de confort</a></li> <li><a href="#3_le_rapport_qualitélatence_est_optimal_pour_le_flow">8.3. 3. Le rapport qualité/latence est optimal pour le flow</a></li> </ul> </li> <li><a href="#leçons_apprises_comment_choisir_son_llm_pour_le_vibe_coding">9. Leçons Apprises : Comment Choisir son LLM pour le Vibe Coding</a></li> <li><a href="#et_la_gouvernance_agent_dans_tout_ça">10. Et la Gouvernance Agent dans tout ça ?</a></li> <li><a href="#sources_techniques">11. Sources Techniques</a></li> <li><a href="#conclusion_le_choix_de_lartisan">12. Conclusion : Le Choix de l’Artisan</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 18 minutes</div> <p>La guerre des LLMs se joue aussi dans le terminal d’un développeur. Pas sur des benchmarks académiques stériles. Dans la vraie vie : un prompt de 30 000 tokens, une gouvernance agent en AsciiDoc, des plugins Gradle Kotlin DSL à debugger et des sessions qui s’enchaînent sur trois semaines. J’ai testé pour vous DeepSeek-V4-Pro, Kimi K2.6 et GLM-5.1. Voici le verdict, preuves techniques à l’appui.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="contexte_pas_un_banc_dessai_un_chantier">1. Contexte : pas un banc d’essai, un chantier</h2> <div class="sectionbody"> <div class="paragraph"> <p>Il y a trois semaines, je travaillais sur <code>codebase-gradle</code>, mon meta-build system qui centralise la configuration YAML de quatre projets : un générateur de README PlantUML, un constructeur de slides AsciiDoc, un site statique JBake et un chatbot LLM. L’agent Opencode, gouverné par ma méthodologie de fichiers agents en AsciiDoc, chargeait ~30K tokens de contexte EAGER à chaque début de session — règles absolues, backlog, historique des 10 dernières sessions.</p> </div> <div class="paragraph"> <p>C’est sur ce terrain que j’ai confronté trois modèles :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Kimi K2.6</strong> (Moonshot AI, 1T params / 32B activés, 256K contexte max, MLA)</p> </li> <li> <p><strong>GLM-5.1</strong> (Zhipu AI/Tsinghua, 744B params / DSA, 200K contexte max)</p> </li> <li> <p><strong>DeepSeek-V4-Pro</strong> (DeepSeek, 1.6T params / 49B activés, 1M contexte max, CSA+HCA)</p> </li> </ul> </div> <div class="paragraph"> <p>Tous servis via Ollama sur serveur cloud, tous en mode thinking (phase de réflexion activée). L’enjeu : produire du code correct, maintenir la cohérence sur des sessions longues, et ne pas halluciner quand le contexte dépasse les 80K tokens.</p> </div> </div> </div> <div class="sect1"> <h2 id="mon_environnement_de_test">2. Mon environnement de test</h2> <div class="sectionbody"> <div id="diag-dev-env" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-b1ac0f8f2064fca47d705e64ced8b52f.svg" alt="Environnement de développement — LLM + Opencode + Gradle" width="693" height="770"> </div> </div> <div class="paragraph"> <p>Chaque session démarrait avec environ 30K tokens de contexte EAGER : <code>AGENT.adoc</code> (287 lignes), <code>PROMPT_REPRISE.adoc</code> (51 lignes), <code>.agents/INDEX.adoc</code> (218 lignes), <code>LAZY_EAGER_ESSENTIALS.adoc</code> (50 lignes). Le contexte grossissait rapidement avec les échanges — une session typique de 10 messages ajoutait 15-20K tokens au prompt cumulé.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_grille_dévaluation">3. La Grille d’Évaluation</h2> <div class="sectionbody"> <div class="paragraph"> <p>J’ai évalué chaque modèle sur quatre axes critiques pour le développement logiciel assisté :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Axe</th> <th class="tableblock halign-left valign-top">Critère concret</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Cohérence long contexte</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">L’agent se souvient-il des conventions décidées il y a 40 messages ?</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Qualité du code produit</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le code compile-t-il du premier coup ? Respecte-t-il les patterns existants ?</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Raisonnement architectural</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">L’agent comprend-il les relations entre modules sans que je les lui réexplique ?</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Résistance aux hallucinations</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">À partir de combien de tokens l’agent commence-t-il à inventer des API ou des classes inexistantes ?</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Et une métrique synthétique maison : le <strong>coefficient de reprise</strong> (combien de temps je passe à corriger l’agent plutôt qu’à coder avec lui).</p> </div> </div> </div> <div class="sect1"> <h2 id="round_1_kimi_k2_6_le_faux_départ">4. Round 1 : Kimi K2.6 — Le Faux Départ</h2> <div class="sectionbody"> <div class="paragraph"> <p>Kimi K2.6 a été mon premier choix. Ses benchmarks sur SWE-Bench Verified (80.2) et Terminal-Bench 2.0 (66.7) sont excellents. Son architecture MLA promet une bonne efficacité sur les longues séquences.</p> </div> <div class="sect2"> <h3 id="session_9_lembellie">4.1. Session 9 : l’embellie</h3> <div class="paragraph"> <p>Première session avec Kimi. Tâche : implémenter la méthode <code>resolveActiveKey()</code> dans <code>codebase.kt</code> — une fonction de résolution de clé API avec fallback CLI. Le contexte est à 30K tokens, Kimi raisonne vite, produit un code propre avec gestion d’expiration des clés.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">fun resolveActiveKey( cfg: CodebaseConfiguration, logger: Logger, cliProvider: String? = null, cliAccount: String? = null, cliKey: String? = null ): NamedApiKey? { // Résolution provider → compte → clé avec CLI override // Kimi a parfaitement compris la chaîne de priorité }</code></pre> </div> </div> <div class="paragraph"> <p>Le code compile. Les 7 cas de test passent. Je suis optimiste.</p> </div> </div> <div class="sect2"> <h3 id="session_10_le_naufrage_silencieux">4.2. Session 10 : le naufrage silencieux</h3> <div class="paragraph"> <p>Deuxième session. Le contexte grimpe à ~90K tokens avec les échanges. Je demande à Kimi d’ajouter un mécanisme de snapshot AsciiDoc qui anonymise les secrets avant écriture.</p> </div> <div class="paragraph"> <p>C’est là que ça dérape. Kimi commence à inventer des classes qui n’existent pas. Il me propose <code>AnonymizedObjectMapper</code> — une classe fictive. Il confond <code>ReadmeYmlAnonymizer</code> et <code>CodebaseYmlAnonymizer</code>. Il me suggère d’importer <code>com.fasterxml.jackson.anonymize.*</code> — un package qui n’a jamais existé.</p> </div> <div class="paragraph"> <p>Pire : dans sa phase de réflexion, je vois qu’il construit des raisonnements sur des prémisses fausses. Il "se souvient" que <code>GitConfig</code> a un champ <code>anonymizedToken</code> — non, c’est <code>resolvedToken()</code>. Il attribue à <code>SiteYmlAnonymizer</code> une méthode <code>maskSupabaseCredentials()</code> — qui n’existe pas.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Ce n’était pas un bug. C’était une dissolution progressive de la cohérence. Comme si chaque token ajouté au contexte diluait un peu plus la mémoire des 30 000 premiers.</p> </div> </blockquote> </div> <div class="paragraph"> <p>J’arrête Kimi après deux sessions. Le diagnostic est clair : le MLA compresse bien le KV cache, mais sans mécanisme de sélection sparse fine-grained, l’attention se dilue mécaniquement au-delà de 60K tokens. Chaque token "voit" de moins en moins bien le contexte lointain — et commence à combler les trous par du bruit.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="round_2_glm_5_1_le_combattant_honorable">5. Round 2 : GLM-5.1 — Le Combattant Honorable</h2> <div class="sectionbody"> <div class="paragraph"> <p>GLM-5.1 arrive avec une architecture différente : MLA pour le base model, puis un <strong>continued pre-training</strong> avec DSA (DeepSeek Sparse Attention) — un indexer léger qui sélectionne dynamiquement les top-2048 tokens pertinents parmi tout l’historique.</p> </div> <div class="sect2"> <h3 id="architecture_le_dsa_contre_le_mla_pur">5.1. Architecture : le DSA contre le MLA pur</h3> <div class="paragraph"> <p>La différence est fondamentale. Là où Kimi compresse l’historique dans un espace latent unique (et perd progressivement la capacité à discriminer l’information pertinente), GLM greffe un indexer post-entraînement qui fait une sélection sparse explicite.</p> </div> <div id="diag-mla-vs-dsa" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-96552207a44b513333686c1c93d0cef9.svg" alt="Comparaison architecture MLA (Kimi) vs MLA+DSA (GLM)" width="1074" height="364"> </div> </div> <div class="paragraph"> <p>Le rapport technique le dit explicitement : DSA est <em>"lossless by construction"</em> — contrairement aux alternatives comme SWA (pattern search), Gated DeltaNet ou SimpleGDN qui perdent jusqu’à 5.69 pts sur RULER@128K.</p> </div> </div> <div class="sect2"> <h3 id="sessions_11_13_solide_mais_frustrant">5.2. Sessions 11-13 : solide mais frustrant</h3> <div class="paragraph"> <p>GLM-5.1 tient mieux la distance. Sur la session 11 (~60K tokens), il reste cohérent. Il produit un <code>SnapshotManager</code> fonctionnel avec gestion correcte des quatre anonymiseurs.</p> </div> <div class="paragraph"> <p>Mais la latence est un problème. Les phases de réflexion DSA sont plus lourdes que le MLA pur — l’indexer doit rescanner l’historique à chaque étape. Une réponse qui prenait 8 secondes avec Kimi en prend 15 avec GLM. Sur une session de 30 messages, ça se fait sentir.</p> </div> <div class="paragraph"> <p>Et puis il y a les erreurs subtiles. GLM ne délire pas comme Kimi — mais il fait des erreurs de <strong>nommage</strong>. Il appelle <code>toAnonymizedYaml()</code> la méthode qui devrait s’appeler <code>anonymize()</code>. Il inverse <code>loadReadmeConfiguration()</code> et <code>loadCodebaseConfiguration()</code> dans le <code>renderFileSection()</code>. Ce ne sont pas des hallucinations, ce sont des confusions de surface — mais en production, une confusion de surface peut casser un build.</p> </div> <div class="paragraph"> <p>J’ai tenu trois sessions avec GLM. Il est meilleur que Kimi, sans conteste. Mais trois sessions de correction manuelle sur des détails de nommage, ça use.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="round_3_deepseek_v4_pro_la_machine_de_guerre">6. Round 3 : DeepSeek-V4-Pro — La Machine de Guerre</h2> <div class="sectionbody"> <div class="paragraph"> <p>DeepSeek-V4-Pro arrive avec l’architecture la plus ambitieuse des trois : un système hybride qui combine deux mécanismes d’attention complémentaires.</p> </div> <div class="sect2"> <h3 id="architecture_csa_hca_le_double_filet">6.1. Architecture : CSA + HCA, le double filet</h3> <div id="diag-csa-hca" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-aad75fde6f9e97e39f6617b3b9f836d7.svg" alt="Architecture hybride CSA+HCA de DeepSeek-V4-Pro" width="741" height="459"> </div> </div> <div class="paragraph"> <p>Deux niveaux de compression, deux granularités d’attention :</p> </div> <div class="ulist"> <ul> <li> <p><strong>CSA</strong> : compresse le KV cache tous les <code>m</code> tokens, puis applique une attention sparse (DeepSeek Sparse Attention) — seul le top-k des entrées compressées est consulté. Précis, local, efficace.</p> </li> <li> <p><strong>HCA</strong> : compression extrême (facteur <code>m'</code> bien plus grand que <code>m</code>), mais attention dense sur le résidu compressé — garde les connexions globales sans explosion quadratique.</p> </li> </ul> </div> <div class="paragraph"> <p>Résultat : à 1M de tokens, DeepSeek-V4-Pro ne consomme que <strong>27% des FLOPs d’inférence</strong> et <strong>10% de la taille du KV cache</strong> par rapport à DeepSeek-V3.2. Le modèle précédent.</p> </div> <div class="paragraph"> <p>Et surtout, le rapport technique (Figure 9) annonce : <em>"Retrieval performance remains highly stable within a 128K context window."</em></p> </div> </div> <div class="sect2"> <h3 id="sessions_1_8_le_soulagement">6.2. Sessions 1-8 : le soulagement</h3> <div class="paragraph"> <p>J’ai passé huit sessions avec DeepSeek-V4-Pro sur <code>codebase-gradle</code>. Huit sessions sans une seule hallucination, sans une seule classe inventée, sans une seule confusion de nommage.</p> </div> <div class="paragraph"> <p>Session 1 : implémentation de <code>CodebaseYmlConfig</code> et <code>CodebaseYmlAnonymizer</code>. 350 lignes de Kotlin, tests inline, tout compile. Session 4 : ajout du <code>SnapshotManager</code> avec tree view, collecte de fichiers, rendu AsciiDoc par fichier. 279 lignes, zéro erreur. Session 7 : debug du <code>renderFileSection()</code> qui devait gérer quatre types d’anonymiseurs différents sans ambiguïté de résolution. Résolu en trois messages.</p> </div> <div class="paragraph"> <p>La latence est plus élevée que Kimi — environ 10-12 secondes par réponse en mode thinking. Mais le taux de correction est quasi nul. Je ne passe pas mon temps à réparer les erreurs de l’agent. Je code <strong>avec</strong> lui.</p> </div> </div> <div class="sect2"> <h3 id="le_test_décisif_refactoring_à_100k_tokens">6.3. Le test décisif : refactoring à 100K tokens</h3> <div class="paragraph"> <p>À la session 8, le contexte cumulé dépasse les 100K tokens. Je demande un refactoring lourd : extraire les quatre tâches de vérification inline du <code>build.gradle.kts</code> vers des fichiers de test JUnit5 dans <code>buildSrc/src/test/</code>.</p> </div> <div class="paragraph"> <p>L’agent propose un plan en trois phases : . Créer les classes de test avec migration des cas existants . Ajouter les dépendances JUnit5 et Kotest dans <code>buildSrc/build.gradle.kts</code> . Supprimer le code inline de <code>build.gradle.kts</code></p> </div> <div class="paragraph"> <p>Le plan est correct. L’exécution est propre. Il identifie même un edge case que j’avais manqué : les dépendances Jackson dupliquées entre <code>buildscript {}</code> et <code>buildSrc/build.gradle.kts</code> qui doivent être unifiées pendant la migration.</p> </div> <div class="paragraph"> <p>100K tokens de contexte, et l’agent se souvient que <code>CodebaseYmlAnonymizer.TOKEN_MASK</code> est <code>"<strong>*</strong>"</code>, que <code>GitConfig.resolvedToken()</code> est une extension function définie dans <code>readme.kt</code>, et que <code>SnapshotManager.PRUNED_DIRS</code> exclut <code>build</code>, <code>.gradle</code> et <code>.git</code>.</p> </div> <div class="paragraph"> <p>C’est ça, la différence.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_face_à_face_metrics_comparatives">7. Le Face-à-Face : Metrics Comparatives</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 14.2857%;"> <col style="width: 28.5714%;"> <col style="width: 28.5714%;"> <col style="width: 28.5715%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Critère</th> <th class="tableblock halign-left valign-top">Kimi K2.6</th> <th class="tableblock halign-left valign-top">GLM-5.1</th> <th class="tableblock halign-left valign-top">DeepSeek-V4-Pro</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top" colspan="4"><p class="tableblock"><strong>Architecture</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Contexte max</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">256K</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">200K</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1M</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Mécanisme attention</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">MLA pur</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">MLA + DSA</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">CSA + HCA hybride</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Paramètres totaux</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1T</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">744B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1.6T</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Paramètres activés</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">32B</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">non publié</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">49B</p></td> </tr> <tr> <td class="tableblock halign-left valign-top" colspan="4"><p class="tableblock"><strong>Performance long-contexte</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Seuil dégradation observé</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~60K tokens</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~120K tokens</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~128K tokens</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Comportement au-delà</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Hallucinations massives</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Confusions de surface</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Dégradation progressive lente</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Stabilité NIAH</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">non publié</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">100% @128K (DSA)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">stable jusqu’à 128K (Figure 9)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">MRCR @128K</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">non publié</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">non publié</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">supérieur à Gemini 3.1 Pro</p></td> </tr> <tr> <td class="tableblock halign-left valign-top" colspan="4"><p class="tableblock"><strong>Expérience développeur</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Sessions tenues avant abandon</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8 (et continue)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Temps de correction / temps de code</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">60%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">30%</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><5%</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Latence moyenne (mode think)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8 s</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">15 s</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">11 s</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coefficient de confiance*</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2/10</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">6/10</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">9/10</p></td> </tr> </tbody> </table> <div class="paragraph"> <p><em>*Coefficient de confiance = mesure subjective de ma capacité à prendre le code de l’agent et le commit sans relecture ligne à ligne.</em></p> </div> <div id="diag-radar" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-1ac33bab88740dda58ef1579a97513c4.svg" alt="Radar comparatif — Kimi K2.6 vs GLM-5.1 vs DeepSeek-V4-Pro" width="1135" height="844"> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_deepseek_v4_pro_gagne_en_développement_logiciel">8. Pourquoi DeepSeek-V4-Pro Gagne en Développement Logiciel</h2> <div class="sectionbody"> <div class="paragraph"> <p>La supériorité de DeepSeek-V4-Pro n’est pas due à un seul facteur — c’est une convergence :</p> </div> <div class="sect2"> <h3 id="1_larchitecture_csahca_est_taillée_pour_le_code">8.1. 1. L’architecture CSA+HCA est taillée pour le code</h3> <div class="paragraph"> <p>Le développement logiciel assisté est un cas d’usage <strong>extrême</strong> pour l’attention long-contexte. Vous avez besoin de : - Précision locale (cette classe hérite de quoi ? cette méthode est définie où ?) → <strong>CSA</strong> - Vision globale (pourquoi ce module existe ? comment les quatre anonymiseurs interagissent ?) → <strong>HCA</strong></p> </div> <div class="paragraph"> <p>Kimi avec MLA seul gère la précision locale mais perd la vision globale au-delà de 60K. GLM avec DSA améliore la vision globale mais reste mono-niveau. DeepSeek combine les deux explicitement.</p> </div> </div> <div class="sect2"> <h3 id="2_le_contexte_eager_est_sa_zone_de_confort">8.2. 2. Le contexte EAGER est sa zone de confort</h3> <div class="paragraph"> <p>Mon système de gouvernance charge ~30K tokens de règles et de backlog au démarrage. Avec une fenêtre stable jusqu’à 128K, DeepSeek dispose de ~100K tokens de marge pour les échanges de la session. C’est 3 à 4 fois plus que ce que Kimi peut gérer sans dégradation.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>La fenêtre de 128K de stabilité parfaite correspond exactement à mes besoins : 30K d’EAGER + 70K d’échanges = une session productive de 20-30 messages sans jamais sortir de la zone verte.</p> </div> </blockquote> </div> </div> <div class="sect2"> <h3 id="3_le_rapport_qualitélatence_est_optimal_pour_le_flow">8.3. 3. Le rapport qualité/latence est optimal pour le flow</h3> <div class="paragraph"> <p>Oui, DeepSeek-V4-Pro est plus lent que Kimi (11s vs 8s). Mais le temps <strong>total</strong> d’une tâche est bien inférieur parce que je ne passe pas 20 minutes à corriger les hallucinations de l’agent.</p> </div> <div class="paragraph"> <p>Le développeur ne mesure pas la latence d’une réponse. Il mesure le temps entre "je pose la question" et "le code est dans mon repo et il fonctionne". Sur cette métrique, DeepSeek-V4-Pro est le plus rapide des trois.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="leçons_apprises_comment_choisir_son_llm_pour_le_vibe_coding">9. Leçons Apprises : Comment Choisir son LLM pour le Vibe Coding</h2> <div class="sectionbody"> <div class="paragraph"> <p>Au-delà du classement ponctuel, cette expérience m’a appris à évaluer un LLM pour le développement logiciel assisté sur des critères qui ne figurent dans aucun benchmark :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Regarde l’architecture, pas la taille de contexte annoncée</strong> — Un modèle qui annonce 256K de contexte mais n’a qu’un MLA finira comme Kimi : théoriquement capable, pratiquement inutilisable au-delà de 60K.</p> </li> <li> <p><strong>Teste sur TON contexte, pas sur un benchmark générique</strong> — Mon prompt initial de 30K tokens AsciiDoc avec règles absolues et backlog n’a rien à voir avec les questions de HLE ou AIME.</p> </li> <li> <p><strong>La latence n’est pas l’ennemie si la qualité suit</strong> — Un modèle lent qui produit du code juste est plus rapide qu’un modèle rapide qui produit du code faux.</p> </li> <li> <p><strong>Méfie-toi des modèles sans technical report public</strong> — Si l’équipe ne documente pas son architecture d’attention, c’est qu’elle n’a pas confiance dans sa tenue en long contexte.</p> </li> </ol> </div> <div id="diag-decision-tree" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-764212652633dc337e38e51de5fc291e.svg" alt="Arbre de décision pour choisir un LLM pour le développement logiciel assisté" width="827" height="461"> </div> </div> </div> </div> <div class="sect1"> <h2 id="et_la_gouvernance_agent_dans_tout_ça">10. Et la Gouvernance Agent dans tout ça ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette expérience valide un point que je défends depuis mon article sur la gouvernance Eager/Lazy : <strong>la qualité du LLM et la qualité de la gouvernance sont multiplicatives, pas additives</strong>.</p> </div> <div class="paragraph"> <p>Avec Kimi K2.6, ma gouvernance était impeccable — mais le modèle diluait l’information. Résultat : gouvernance parfaite × hallucination = zéro.</p> </div> <div class="paragraph"> <p>Avec DeepSeek-V4-Pro, la gouvernance EAGER (30K tokens de règles) + LAZY (archives de sessions, références techniques) + Hot/Warm/Cold (backup rotatif) forme un écosystème où chaque couche amplifie l’autre. L’agent a les règles sous les yeux (EAGER), peut consulter l’historique (LAZY), et le contexte ne sature jamais (rotation backup).</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Un bon LLM sans gouvernance, c’est un moteur de Ferrari sans volant. Une bonne gouvernance sans bon LLM, c’est un volant sans moteur. DeepSeek-V4-Pro + ma gouvernance agent = la première fois que j’ai l’impression de conduire.</p> </div> </blockquote> </div> <div class="paragraph"> <p>Le mécanisme de backup rotatif (rotation toutes les 10 sessions ou >500 lignes EAGER) prend tout son sens avec un modèle qui tient 128K de contexte : la sliding window de 10 sessions actives maintient le contexte frais sans jamais dépasser la zone de dégradation.</p> </div> </div> </div> <div class="sect1"> <h2 id="sources_techniques">11. Sources Techniques</h2> <div class="sectionbody"> <div class="paragraph"> <p>J’ai croisé mon expérience empirique avec les rapports techniques officiels pour valider mes observations :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>DeepSeek-V4 Technical Report</strong> — PDF récupéré depuis <a href="https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash">HuggingFace</a>. Figure 9 : "Retrieval performance remains highly stable within a 128K context window. While a performance degradation becomes visible beyond the 128K mark, the model’s retrieval capabilities at 1M tokens remain remarkably strong." Architecture CSA+HCA documentée section 2.3.</p> </li> <li> <p><strong>GLM-5 Technical Report</strong> — <a href="https://arxiv.org/abs/2602.15763">arXiv:2602.15763</a>. DSA introduit via continued pre-training, "lossless by construction". Contexte max 202,752 tokens. Tables 3/5/6 documentent les performances long-contexte vs alternatives (SWA, Gated DeltaNet, SimpleGDN).</p> </li> <li> <p><strong>Kimi K2.6 Model Card</strong> — <a href="https://huggingface.co/moonshotai/Kimi-K2.6">HuggingFace</a>. MLA, 256K contexte max. Stratégie de discard-all au-delà du seuil sur les tâches agentiques (confirmant implicitement la limite pratique du MLA en long contexte).</p> </li> <li> <p><strong>Kimi K2 Technical Report</strong> — <a href="https://arxiv.org/abs/2507.20534">arXiv:2507.20534</a>. Architecture MoE, MuonClip optimizer, performances agentiques (HLE, BrowseComp, Terminal-Bench).</p> </li> </ol> </div> <div class="paragraph"> <p>Le point le plus révélateur : dans leur propre évaluation, Moonshot applique une stratégie de <strong>discard-all</strong> (suppression du contexte ancien) dès que la fenêtre de contexte est dépassée. Cela confirme exactement ce que j’ai observé : le MLA seul ne peut pas maintenir la cohérence sur toute la fenêtre de 256K. L’architecture ne suit pas.</p> </div> </div> </div> <div class="sect1"> <h2 id="conclusion_le_choix_de_lartisan">12. Conclusion : Le Choix de l’Artisan</h2> <div class="sectionbody"> <div class="paragraph"> <p>Après trois semaines et treize sessions de développement réel, le verdict est sans appel :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 33.3333%;"> <col style="width: 33.3333%;"> <col style="width: 33.3334%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Kimi K2.6</th> <th class="tableblock halign-left valign-top">GLM-5.1</th> <th class="tableblock halign-left valign-top">DeepSeek-V4-Pro</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Excellent sous 60K</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Solide jusqu’à 120K</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Domine partout</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Inutilisable au-delà</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Confusions de surface</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Stable jusqu’à 128K</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">2 sessions, abandonné</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3 sessions, abandonné</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8 sessions, adopté</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>DeepSeek-V4-Pro est devenu mon LLM par défaut pour toutes les sessions de développement logiciel assisté avec Opencode. Pas parce qu’il est le plus récent. Pas parce qu’il a les meilleurs benchmarks académiques. Mais parce que dans la vraie vie d’un développeur qui pousse des plugins Gradle Kotlin DSL avec un contexte agent de 30K tokens, c’est le seul qui ne me trahit pas quand le contexte s’allonge.</p> </div> <div class="paragraph"> <p>Le CSA+HCA est un <strong>game changer</strong> architectural. La compression double niveau + sparsification n’est pas un détail d’implémentation — c’est ce qui fait la différence entre un assistant de code et un coéquipier fiable.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>J’ai choisi DeepSeek-V4-Pro parce qu’il est le seul des trois qui transforme ma gouvernance agent d’une contrainte défensive ("comment éviter que l’agent oublie ?") en un avantage offensif ("que peut-on construire maintenant que l’agent se souvient de tout ?").</p> </div> </blockquote> </div> <hr> <div class="paragraph"> <p><strong>Cet article est le fruit de 13 sessions de développement réel sur le projet <code>codebase-gradle</code>, documentées dans <code>.agents/sessions/</code> selon ma méthodologie de gouvernance agent Eager/Lazy/Hot/Warm/Cold. Les sources techniques citées sont accessibles publiquement sur HuggingFace et arXiv.</strong></p> </div> </div> </div> https://pages-content.github.io//blog/2026/0111_audit_contexte_agent_post.html Mon, 27 Apr 2026 00:00:00 +0000 blog/2026/0111_audit_contexte_agent_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#la_scène_session_051_quelque_chose_cloche">1. La scène : session 051, quelque chose cloche</a></li> <li><a href="#laudit_décortiquer_les_627_lignes">2. L’audit : décortiquer les 627 lignes</a></li> <li><a href="#la_peur_de_perdre_lingénierie">3. La peur de perdre l’ingénierie</a></li> <li><a href="#la_solution_split_encyclopédique">4. La solution : split encyclopédique</a></li> <li><a href="#le_contenu_du_fichier_essentials">5. Le contenu du fichier ESSENTIALS</a></li> <li><a href="#le_résultat_50_de_contexte_eager">6. Le résultat : -50% de contexte EAGER</a></li> <li><a href="#pourquoi_le_dossier_sappelle_encyclopedies">7. Pourquoi le dossier s’appelle <code>encyclopedies/</code></a></li> <li><a href="#la_suite_logique_de_la_série">8. La suite logique de la série</a></li> <li><a href="#ce_que_jaurais_fait_différemment">9. Ce que j’aurais fait différemment</a></li> <li><a href="#le_guide_pour_auditer_votre_propre_contexte">10. Le guide pour auditer votre propre contexte</a></li> <li><a href="#une_gouvernance_vivante">11. Une gouvernance vivante</a></li> <li><a href="#liens">12. Liens</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 14 minutes</div> <p>Vous avez passé des semaines à construire une gouvernance agent impeccable. Eager/Lazy, procédure de fin de session, backups rotatifs. Le système tourne. Puis un jour, l’agent devient lent. Les réponses sont diluées. Vous mesurez : 1414 lignes chargées automatiquement. Et le pire, c’est que le coupable n’est pas le code, ni le backlog, ni les archives de sessions. Le coupable, c’est le fichier qui documente votre méthode.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="la_scène_session_051_quelque_chose_cloche">1. La scène : session 051, quelque chose cloche</h2> <div class="sectionbody"> <div class="paragraph"> <p>30 avril 2026, 16h00. Je suis en pleine session sur <code>magic-stick</code>, mon projet de build d’ISO Linux live. L’agent Opencode a chargé automatiquement mes fichiers Eager comme d’habitude — <code>AGENT.adoc</code>, <code>PROMPT_REPRISE.adoc</code>, <code>.agents/INDEX.adoc</code>. Tout est normal.</p> </div> <div class="paragraph"> <p>Sauf que les réponses sont molles. L’agent met deux secondes de plus à raisonner. Il oublie un détail qu’il avait sous les yeux trois messages plus tôt. Ce n’est pas un crash, pas une erreur — c’est une dégradation lente, le genre qu’on ne remarque pas tout de suite.</p> </div> <div class="paragraph"> <p>J’avais déjà vécu ça à la session 048, quand j’avais découvert que les fichiers de gouvernance pesaient 5200 lignes cumulées. J’avais alors conceptualisé le mécanisme Hot/Warm/Cold avec sa sliding window de 10 sessions, ses vagues froides identiques, son capteur à deux déclencheurs. Le problème était réglé. En théorie.</p> </div> <div class="paragraph"> <p>Mais là, on est à la session 051. La rotation backup a bien eu lieu — les fichiers EAGER sont passés de 2087 à 500 lignes. Pourtant, le contexte reste lourd. Quelque chose m’échappe.</p> </div> <div class="paragraph"> <p>J’ouvre un terminal et je tape :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">wc -l AGENT.adoc AGENT_MODUS_OPERANDI.adoc PROMPT_REPRISE.adoc \ .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \ .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs"> 287 AGENT.adoc 627 AGENT_MODUS_OPERANDI.adoc 51 PROMPT_REPRISE.adoc 218 .agents/INDEX.adoc 18 .agents/SESSIONS_HISTORY.adoc 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc 1414 total</code></pre> </div> </div> <div class="paragraph"> <p>1414 lignes. La rotation backup a bien taillé dans INDEX, SESSIONS_HISTORY et COMPLETED_TASKS — ils sont propres. Mais il y a un éléphant dans la pièce que je n’avais pas vu : <strong>627 lignes</strong> dans un seul fichier. <code>AGENT_MODUS_OPERANDI.adoc</code>.</p> </div> <div class="paragraph"> <p>Ce fichier, c’est celui que j’ai écrit à la session 1 pour documenter la stratégie Eager/Lazy. C’est le manuel de la méthode. Et il est devenu, à lui seul, 44% du contexte EAGER.</p> </div> <div id="diag-before-audit" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-055a31fdef8c78e522a1ab22c6f74925.svg" alt="Répartition des 1414 lignes EAGER avant audit" width="721" height="200"> </div> </div> <div class="paragraph"> <p>L’ironie est totale. Le fichier conçu pour <strong>économiser</strong> du contexte est devenu le principal <strong>consommateur</strong> de contexte. C’est comme si le manuel d’utilisation de votre voiture pesait plus lourd que le moteur.</p> </div> </div> </div> <div class="sect1"> <h2 id="laudit_décortiquer_les_627_lignes">2. L’audit : décortiquer les 627 lignes</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je décide de faire un audit section par section. Pas pour supprimer — pour <strong>comprendre</strong> ce qui mérite d’être en EAGER et ce qui pourrait vivre ailleurs sans perte de connaissance.</p> </div> <div class="paragraph"> <p>Voici la structure exacte de <code>AGENT_MODUS_OPERANDI.adoc</code> et ce que j’y trouve :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 16.6666%;"> <col style="width: 16.6666%;"> <col style="width: 33.3333%;"> <col style="width: 33.3335%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Section</th> <th class="tableblock halign-left valign-top">Lignes</th> <th class="tableblock halign-left valign-top">Contenu</th> <th class="tableblock halign-left valign-top">Déjà présent dans…​</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P1 — Vue d’ensemble</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">64</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Problème résolu, principes fondamentaux, analogie tableau de bord vs manuel</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P2 — Structure des fichiers</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">97</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Arborescence, politique de chargement, quand charger quoi</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P3 — Règles absolues</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">34</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Git interdit, commandes destructrices interdites, secrets interdits</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>AGENT.adoc</code> + <code>INDEX.adoc</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P4 — Cycle de vie session</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">133</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Template ouverture, règles de travail, 6 étapes fin de session, checklist</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>AGENT.adoc</code> §Fin session + <code>INDEX.adoc</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P5 — Métriques et seuils</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">49</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Session idéale (15-30 min, 1-3 fichiers), signes d’alerte</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P6 — Types de sessions</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">72</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tableau de détection, format de proposition, exceptions</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P7 — Amélioration continue</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">39</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Métriques de suivi, revue hebdomadaire</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P8 — Checklist démarrage</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">13</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Bootstrap nouveau projet</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>P9 — Références</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">30</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fichiers de référence, ressources externes</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>AGENT.adoc</code> (fichiers EAGER/LAZY)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Annexes A+B</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">42</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Glossaire, historique versions</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le verdict est sans appel :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Doublons intégraux</strong> (167 lignes) : P3, P4, P9 — tout est déjà dans <code>AGENT.adoc</code> ou <code>INDEX.adoc</code>, souvent mot pour mot</p> </li> <li> <p><strong>Jamais consulté en pratique</strong> (215 lignes) : P5, P6, P7, P8, Annexes — de la méta-gouvernance qui n’a jamais servi dans aucune session</p> </li> <li> <p><strong>Connaissance unique</strong> (161 lignes) : P1 et P2 — le vocabulaire LAZY/EAGER, l’analogie, la politique de chargement</p> </li> </ul> </div> <div class="paragraph"> <p>Sur 627 lignes, <strong>382 sont du bruit</strong>. Et ces 382 lignes sont chargées <strong>à chaque début de session</strong>, consommées par l’agent, diluant son attention avant même que je dise bonjour.</p> </div> <div id="diag-audit-result" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-e3ec2f50f58c8bbd108e7f63232946be.svg" alt="Résultat de l’audit — 627 lignes réparties en doublons, jamais consulté, connaissance unique" width="514" height="665"> </div> </div> <div class="paragraph"> <p>Ce diagramme est la clé de tout. Les doublons (jaune) sont du bruit pur — l’agent les lit deux fois, dans deux fichiers différents. Le jamais consulté (rouge) est de la documentation morte — écrite avec soin, jamais utilisée. Seul le vert contient de la connaissance que l’agent ne peut pas trouver ailleurs.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_peur_de_perdre_lingénierie">3. La peur de perdre l’ingénierie</h2> <div class="sectionbody"> <div class="paragraph"> <p>À ce stade, j’ai l’évidence sous les yeux : je dois réduire <code>AGENT_MODUS_OPERANDI.adoc</code>. Mais j’hésite.</p> </div> <div class="paragraph"> <p>Ce fichier, je l’ai écrit à la main. Chaque section est le résultat d’une leçon apprise en session réelle. La partie P3 est née d’un <code>rm -rf</code> accidentel sur <code>bakery-plugin</code> qui m’a coûté des tokens Firebase réels. La partie P4 est le résultat de quinze sessions où j’oubliais d’archiver et je perdais le fil. La procédure en 6 étapes n’est pas sortie d’un livre — elle est sortie de la douleur.</p> </div> <div class="paragraph"> <p>Supprimer ces sections, ce serait jeter l’historique de ma propre ingénierie. Les leçons qui les ont produites, les sessions pendant lesquelles je les ai découvertes, les erreurs que je ne veux plus jamais refaire. Ce n’est pas du texte — c’est de l’expérience cristallisée.</p> </div> <div class="paragraph"> <p>C’est là que je formule le principe qui va guider la solution :</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p><strong>Ne jamais supprimer. Toujours relocaliser.</strong> La connaissance n’a pas à disparaître du projet. Elle a juste à ne pas être chargée automatiquement quand elle n’est pas nécessaire.</p> </div> </blockquote> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_split_encyclopédique">4. La solution : split encyclopédique</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le modèle que je propose est simple et s’inspire de la façon dont Wikipédia a grandi : quand un article devient trop long, on ne le coupe pas — on crée un article détaillé et on garde un résumé dans l’article principal.</p> </div> <div class="paragraph"> <p>Pour <code>AGENT_MODUS_OPERANDI.adoc</code>, cela donne :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Extraire</strong> les 161 lignes de connaissance unique (P1 + P2) dans un nouveau fichier <code>LAZY_EAGER_ESSENTIALS.adoc</code> — compacté à ~50 lignes, strictement EAGER</p> </li> <li> <p><strong>Renommer</strong> <code>AGENT_MODUS_OPERANDI.adoc</code> en <code>.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc</code> — le fichier original de 627 lignes, préservé <strong>intact</strong>, en cold storage</p> </li> <li> <p><strong>Ne jamais charger</strong> le fichier encyclopédie automatiquement — il est là pour l’humain, pour la distillation future, pour l’agent qu’on invoquera dans six mois avec un meilleur modèle</p> </li> </ol> </div> <div id="diag-split-solution" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-1ca7b1421a06e9049df1c3513a7924d2.svg" alt="Architecture du split encyclopédique — ESSENTIALS EAGER + ENCYCLOPEDIE cold storage" width="762" height="530"> </div> </div> <div class="paragraph"> <p>Le nom <code>encyclopedies/</code> n’est pas anodin. Une encyclopédie, ce n’est pas un dossier d’archives — c’est une collection de connaissance organisée, consultable mais pas portable. On ne lit pas l’Encyclopédie Universalis dans le métro. On la garde dans la bibliothèque, et on y va quand on a une question précise.</p> </div> <div class="paragraph"> <p>C’est exactement le rôle de ce dossier : une bibliothèque de référence froide, structurée, exhaustive — que l’agent ne touche pas automatiquement.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_contenu_du_fichier_essentials">5. Le contenu du fichier ESSENTIALS</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici à quoi ressemble concrètement le nouveau fichier <code>LAZY_EAGER_ESSENTIALS.adoc</code>, extrait et compacté à partir de P1 et P2 :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">= Stratégie LAZY/EAGER — Principes Essentiels [abstract] Ce fichier définit la stratégie de gestion du contexte agent. Chargé automatiquement (EAGER) en début de session. == Principes |=== | EAGER | LAZY | Tableau de bord | Manuel du propriétaire | Chargé automatiquement | Chargé sur demande | <= 100 lignes, <= 10k tokens | Illimité, détaillé | Règles absolues, mission courante | Archives, historique, références |=== == Politique de Chargement |=== | Fichier | Type | Quand charger | PROMPT_REPRISE.adoc | EAGER | Début session (auto) | *_ESSENTIALS.adoc | EAGER | Début session si EPIC active | .agents/INDEX.adoc | EAGER | Début session (auto) | *_REFERENCE.adoc | LAZY | Sur besoin (détails architecture) | .agents/sessions/N-*.adoc | LAZY | Sur demande (détails session) | .agents/encyclopedies/*.adoc | COLD | Jamais auto (humain seulement) |=== == Comment l'Agent Sait Quoi Charger Début session → PROMPT_REPRISE + INDEX + ESSENTIALS actifs. Besoin de détails → charger les *_REFERENCE et sessions/ en LAZY. Connaissance froide → encyclopedies/, jamais automatique.</code></pre> </div> </div> <div class="paragraph"> <p>Cinquante lignes. C’est tout ce dont l’agent a besoin pour comprendre la mécanique. Tout le reste — l’historique des leçons, les analogies détaillées, les procédures pas à pas, les annexes — vit dans l’encyclopédie.</p> </div> <div class="paragraph"> <p>Et le plus important : <strong>rien n’a été supprimé</strong>. Les 627 lignes d’ingénierie sont toujours là, dans <code>.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc</code>. Elles sont juste rangées dans la bibliothèque plutôt que sur le plan de travail.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_résultat_50_de_contexte_eager">6. Le résultat : -50% de contexte EAGER</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant le split :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs"> 287 AGENT.adoc 627 AGENT_MODUS_OPERANDI.adoc 51 PROMPT_REPRISE.adoc 218 .agents/INDEX.adoc 18 .agents/SESSIONS_HISTORY.adoc 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc 1414 total</code></pre> </div> </div> <div class="paragraph"> <p>Après le split :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs"> 287 AGENT.adoc 50 LAZY_EAGER_ESSENTIALS.adoc ← remplace 627 lignes 51 PROMPT_REPRISE.adoc 218 .agents/INDEX.adoc 18 .agents/SESSIONS_HISTORY.adoc 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc 837 total ← -41%</code></pre> </div> </div> <div id="diag-after-audit" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-4ca8c26a5cbdc6d1078c3680e6b90bec.svg" alt="Répartition des 837 lignes EAGER après audit — gain de 41%" width="687" height="230"> </div> </div> <div class="paragraph"> <p>Le plus gros consommateur (AGENT_MODUS_OPERANDI, 627 lignes) a été remplacé par un fichier de 50 lignes. Le gain est immédiat : 577 lignes de contexte libérées. L’agent respire.</p> </div> <div class="paragraph"> <p>Et dans <code>.agents/encyclopedies/</code>, le fichier original de 627 lignes attend. Intact. Avec toutes ses sections — y compris celles qui sont des doublons, y compris celles qui n’ont jamais servi. Parce qu’un jour, un meilleur modèle ou un data scientist humain voudra croiser ces angles, ces redondances assumées, ces leçons apprises. Et ce jour-là, la matière première sera là.</p> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_le_dossier_sappelle_encyclopedies">7. Pourquoi le dossier s’appelle <code>encyclopedies/</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>Le choix du nom n’est pas cosmétique. Il encode la philosophie du mécanisme.</p> </div> <div class="paragraph"> <p>Une <strong>archive</strong> (<code>archives/</code>) contient des données historiques organisées chronologiquement — comme les COMPLETED_TASKS mensuels. Un <strong>backup</strong> (<code>backup/</code>) est un snapshot horodaté — une copie de sécurité d’un état passé.</p> </div> <div class="paragraph"> <p>Une <strong>encyclopédie</strong>, c’est autre chose. C’est une collection de connaissance thématique, structurée par sujet, exhaustive mais non linéaire. On ne lit pas une encyclopédie du début à la fin. On y plonge pour répondre à une question précise.</p> </div> <div class="paragraph"> <p>C’est exactement le contrat de ce dossier :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Dossier</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Rôle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Accès</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Granularité</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>archives/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Données historiques (tâches terminées par mois)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">LAZY, structuré</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Chronologique</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>backup/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Snapshots froids (vagues de 10 sessions)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">COLD, copie intégrale</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Chronologique</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>encyclopedies/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Connaissance thématique exhaustive (méthodologie, patterns)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">COLD, jamais auto</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Thématique</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Cette distinction évite le fourre-tout. Chaque fichier sait où il doit vivre selon <strong>ce qu’il contient</strong>, pas selon <strong>quand il a été créé</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_suite_logique_de_la_série">8. La suite logique de la série</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si vous avez lu les deux premiers articles, voici comment les trois pièces s’emboîtent :</p> </div> <div id="diag-trilogie" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-7a93be1f2d7bbeab8cf9d47564547c7c.svg" alt="Les trois articles de la série gouvernance — progression logique" width="1216" height="493"> </div> </div> <div class="ulist"> <ul> <li> <p><strong>0108</strong> répond à : « Comment donner une mémoire à l’agent entre deux sessions ? »</p> </li> <li> <p><strong>0110</strong> répond à : « Comment empêcher cette mémoire d’étouffer l’agent ? »</p> </li> <li> <p><strong>0111</strong> répond à : « Et si le problème n’est pas la taille des archives, mais ce qu’on a <strong>choisi</strong> de mettre en EAGER ? »</p> </li> </ul> </div> <div class="paragraph"> <p>Le premier article a construit la structure. Le deuxième a ajouté le mécanisme de vieillissement. Le troisième audite le contenu — et découvre que la méthodologie elle-même est devenue le problème.</p> </div> </div> </div> <div class="sect1"> <h2 id="ce_que_jaurais_fait_différemment">9. Ce que j’aurais fait différemment</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avec le recul, je vois l’erreur de conception initiale. <code>AGENT_MODUS_OPERANDI.adoc</code> a été créé comme un document unique — un manifeste. C’était la bonne approche pour formaliser la pensée. Mais une fois la pensée formalisée, le document aurait dû être splité immédiatement : l’essentiel en EAGER, l’exhaustif en cold.</p> </div> <div class="paragraph"> <p>Je ne l’ai pas fait parce que j’étais fier du document. 627 lignes d’ingénierie pure, écrites à la main, chaque section fruit d’une leçon de session. C’était mon œuvre. Et comme tout auteur, j’ai eu du mal à la découper.</p> </div> <div class="paragraph"> <p>La leçon : <strong>ce n’est pas parce qu’un document est bon qu’il doit être chargé automatiquement</strong>. La qualité du contenu n’a aucun rapport avec sa pertinence pour le contexte immédiat de l’agent.</p> </div> <div class="paragraph"> <p>Aujourd’hui, la règle est simple : tout document de plus de 100 lignes dans le contexte EAGER est un suspect. Il mérite un audit. Pas une condamnation — un audit. Et la question n’est jamais « faut-il le supprimer ? » mais « faut-il le charger à chaque session ? »</p> </div> </div> </div> <div class="sect1"> <h2 id="le_guide_pour_auditer_votre_propre_contexte">10. Le guide pour auditer votre propre contexte</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si vous avez suivi les deux premiers articles et mis en place votre propre gouvernance Eager/Lazy, voici une procédure d’audit en cinq étapes :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Mesurer</strong> : <code>wc -l</code> sur tous vos fichiers EAGER. Le total devrait être sous 1000 lignes.</p> </li> <li> <p><strong>Identifier le plus gros</strong> : le fichier qui pèse plus de 20% du total est le suspect numéro un.</p> </li> <li> <p><strong>Auditer section par section</strong> : pour chaque section, demandez-vous « Est-ce que cette information est déjà ailleurs ? Est-ce que l’agent l’a déjà lue dans un autre fichier ? Est-ce qu’elle a servi dans les 5 dernières sessions ? »</p> </li> <li> <p><strong>Classifier</strong> : doublon, jamais utilisé, connaissance unique.</p> </li> <li> <p><strong>Splitter ou relocaliser</strong> : ce qui est unique et critique → ESSENTIALS compacté. Tout le reste → <code>encyclopedies/</code>.</p> </li> </ol> </div> <div id="diag-audit-checklist" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-5bc9a34fb18adeac0f7da7af8a309acd.svg" alt="Procédure d’audit en 5 étapes" width="430" height="741"> </div> </div> <div class="paragraph"> <p>Cette procédure prend 15 minutes. Sur un projet de 50 sessions, elle économise des centaines de tokens par session future. Le ROI est immédiat.</p> </div> </div> </div> <div class="sect1"> <h2 id="une_gouvernance_vivante">11. Une gouvernance vivante</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce que cette série de trois articles m’a appris, c’est que la gouvernance agent n’est pas un produit fini. C’est un <strong>organisme vivant</strong>. Elle grandit avec le projet. Elle attrape des maladies de croissance. Elle nécessite des check-ups réguliers.</p> </div> <div class="paragraph"> <p>La session 048 a révélé que les archives gonflent. La session 051 a révélé que la méthodologie elle-même gonfle. La session 060 révélera probablement autre chose. C’est normal. C’est sain. Une gouvernance qui ne se remet jamais en question est une gouvernance morte.</p> </div> <div class="paragraph"> <p>Les trois mécanismes mis en place — Eager/Lazy, Hot/Warm/Cold, split encyclopédique — forment un système de défense en profondeur contre la saturation du contexte. Aucun n’est suffisant seul. Ensemble, ils se complètent :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Eager/Lazy</strong> structure l’information <strong>par disponibilité</strong></p> </li> <li> <p><strong>Hot/Warm/Cold</strong> structure l’information <strong>par fraîcheur</strong></p> </li> <li> <p><strong>Audit encyclopédique</strong> structure l’information <strong>par densité</strong></p> </li> </ul> </div> <div id="diag-defense-in-depth" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-c815b1bc714a7df30a365994ac557d7d.svg" alt="Les trois couches de défense contre la saturation du contexte" width="672" height="345"> </div> </div> <div class="paragraph"> <p>Avec ces trois couches, le contexte agent sur <code>magic-stick</code> est passé de 2087 lignes (avant toute optimisation) à environ 800 lignes — une division par 2,6. Sans avoir perdu une seule ligne de documentation, une seule archive de session, une seule leçon apprise.</p> </div> <div class="paragraph"> <p>Tout est là. Juste mieux rangé.</p> </div> </div> </div> <div class="sect1"> <h2 id="liens">12. Liens</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Article 0108 — Stratégie Eager/Lazy : <a href="/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">Gouverner un Agent IA avec du AsciiDoc</a></p> </li> <li> <p>Article 0110 — Mécanisme Hot/Warm/Cold : <a href="/blog/2026/0110_mecanisme_backup_contexte_agent_post.html">Sliding Window et Vague Froide</a></p> </li> <li> <p>Mon site : <a href="https://cheroliv.com" class="bare">https://cheroliv.com</a></p> </li> <li> <p>Le projet <code>magic-stick</code> : <a href="https://github.com/cheroliv/magic-stick" class="bare">https://github.com/cheroliv/magic-stick</a></p> </li> </ul> </div> <hr> <div class="paragraph"> <p><strong>La connaissance n’a pas à disparaître. Elle a juste à ne pas être chargée quand elle n’est pas nécessaire.</strong></p> </div> </div> </div> https://pages-content.github.io//blog/2026/0110_mecanisme_backup_contexte_agent_post.html Sun, 26 Apr 2026 00:00:00 +0000 blog/2026/0110_mecanisme_backup_contexte_agent_post.html <div class="sect1"> <h2 id="résumé">Résumé</h2> <div class="sectionbody"> <div class="paragraph"> <p>Après 48 sessions sur un seul projet et 150+ au total, le système de gouvernance Eager/Lazy que j’avais construit avec soin commençait à s’étouffer. Les fichiers agents, censés être légers, pesaient 5200 lignes cumulées. Le contexte auto-chargé montait plus vite que ma capacité à le contrôler. Cet article raconte comment j’ai conceptualisé un mécanisme de backup — entre sliding window et vague froide identique — pour maintenir un contexte actif léger sans jamais rien perdre.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_signal_5200_lignes">1. Le Signal : 5200 Lignes</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je suis en pleine session 048 sur <code>magic-stick</code>, mon projet de build d’ISO Linux live. Opencode me regarde. Comme toujours, il a chargé automatiquement mes fichiers Eager en début de session — <code>AGENT.adoc</code>, <code>PROMPT_REPRISE.adoc</code>, <code>.agents/INDEX.adoc</code>. Rien d’anormal.</p> </div> <div class="paragraph"> <p>Sauf que quelque chose cloche. Les réponses sont plus lentes. Le raisonnement est plus dilué. L’agent oublie des détails qu’il avait sous les yeux il y a deux messages.</p> </div> <div class="paragraph"> <p>J’ouvre un terminal et je tape :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">wc -l .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \ .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc</code></pre> </div> </div> <div class="paragraph"> <p>260 lignes pour INDEX. 55 pour SESSIONS_HISTORY. <strong>1756 pour COMPLETED_TASKS_ARCHIVE</strong>.</p> </div> <div class="paragraph"> <p>Le dossier <code>sessions/</code> ajoute encore ~3200 lignes. Total : <strong>5200 lignes</strong> de contexte qui se chargent, d’une manière ou d’une autre, dans le cerveau temporaire de l’agent.</p> </div> <div class="paragraph"> <p>La stratégie Eager/Lazy que j’avais théorisée à l’article précédent fonctionne — mais elle a un défaut de naissance que je n’avais pas anticipé : elle n’a <strong>pas de mécanisme de vieillissement</strong>. Chaque session ajoute une ligne à INDEX, un paragraphe à COMPLETED_TASKS, un fichier dans sessions/. Rien ne sort jamais. Le contexte est une boule de neige qui grossit à chaque nouvelle session.</p> </div> <div id="diag-growth" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-95c83a721c5c943661137fb4c7f9bc23.svg" alt="Courbe de croissance des fichiers agents — de la session 1 à 48" width="427" height="591"> </div> </div> <div class="paragraph"> <p>Ce n’est pas un bug, c’est une conséquence directe de la procédure de fin de session qui archive méticuleusement chaque détail. Le système est victime de son propre succès.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_diagnostic_triple_redondance">2. Le Diagnostic : Triple Redondance</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je demande à l’agent de diagnostiquer le problème. Sa réponse est immédiate et chirurgicale.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Fichier</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Lignes</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Rôle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Problème</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.agents/INDEX.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">260+</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">EAGER (chargé auto)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Table de toutes les sessions depuis la 001 — <strong>+1 ligne par session</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.agents/SESSIONS_HISTORY.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">55</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">EAGER</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Table récapitulative — <strong>redondance avec INDEX</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>COMPLETED_TASKS_ARCHIVE_2026-04.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1756</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">EAGER (implicite)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Détails complets de toutes les sessions d’avril</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.agents/sessions/*.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~5200 total</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">LAZY (supposé)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Archives individuelles, mais <strong>pas utilisées</strong> car tout est déjà dans COMPLETED_TASKS</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>L’agent identifie quatre causes racines :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>COMPLETED_TASKS_ARCHIVE absorbe tout</strong> — Au lieu de pointer vers les archives <code>.sessions/</code>, il recopie intégralement chaque session.</p> </li> <li> <p><strong>INDEX.adoc fait office d’historique complet</strong> — Le tableau "Sessions Récentes" contient 30+ entrées.</p> </li> <li> <p><strong>SESSIONS_HISTORY.adoc redondant</strong> — Même info que INDEX, format différent.</p> </li> <li> <p><strong>La règle LAZY n’est pas respectée</strong> — COMPLETED_TASKS est implicitement EAGER car il contient tout.</p> </li> </ol> </div> <div class="paragraph"> <p>Sa proposition est radicale : limiter INDEX à 10 sessions, vider COMPLETED_TASKS, déplacer SESSIONS_HISTORY en LAZY pur. Gain immédiat : <strong>~1900 lignes économisées</strong>.</p> </div> <div class="paragraph"> <p>C’est propre, efficace, logique. Mais j’ai un problème avec cette approche.</p> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_jai_refusé_la_solution_évidente">3. Pourquoi J’ai Refusé la Solution Évidente</h2> <div class="sectionbody"> <div class="paragraph"> <p>La solution de l’agent est celle d’un ingénieur qui optimise un cache. Limiter. Tronquer. Supprimer les redondances.</p> </div> <div class="paragraph"> <p>Mais ces "redondances" n’en sont pas. Chaque fichier de gouvernance capture un <strong>angle différent</strong> sur la même réalité :</p> </div> <div class="ulist"> <ul> <li> <p><strong>INDEX</strong> = vue macro, tableau de bord exécutif</p> </li> <li> <p><strong>SESSIONS_HISTORY</strong> = table chronologique linéaire, scorée</p> </li> <li> <p><strong>COMPLETED_TASKS_ARCHIVE</strong> = narrative détaillée avec métriques</p> </li> <li> <p><strong>sessions/*.adoc</strong> = archives individuelles, contexte complet</p> </li> </ul> </div> <div class="paragraph"> <p>Ce n’est pas de la duplication bête. C’est de la <strong>perspective multiple structurée</strong>. C’est exactement ce dont on a besoin pour distiller — pour que plus tard, un humain (ou un futur LLM mieux entraîné) puisse croiser les angles et extraire des patterns.</p> </div> <div class="paragraph"> <p>Imaginez un data scientist qui vous dit : « Supprimons 3 colonnes sur 6, elles sont corrélées. » Vous lui répondez quoi ? Que la corrélation n’est pas de la redondance quand chaque colonne capture une dimension différente du même phénomène. Que c’est précisément cette richesse dimensionnelle qui rend le dataset exploitable.</p> </div> <div class="paragraph"> <p>C’est mon intuition. Et je la défends contre la rationalité froide de l’agent.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Je ne vois pas de fourre-tout silencieux dans mon idée. On ne fourre pas tout, on déplace le résultat structuré de la procédure de fin de session — chaque fichier avec son angle, ses redondances qui sont en réalité un enrichissement. C’est ce matériel multidimensionnel qui sera meilleur pour la distillation.</p> </div> </blockquote> </div> <div class="paragraph"> <p>L’agent accuse le coup. Et se corrige.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_proposition_vague_froide_identique">4. La Proposition : Vague Froide Identique</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’agent propose alors un mécanisme plus fin, qui respecte mon intuition de dataset riche tout en résolvant le problème technique du contexte qui explose.</p> </div> <div class="paragraph"> <p>Le principe est simple et s’inspire directement du pattern <strong>Hot/Warm/Cold Storage</strong> appliqué à la gestion d’archives :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Hot (EAGER)</strong> = les 10 dernières sessions dans INDEX, PROMPT_REPRISE de la session N+1, les 2 derniers fichiers de session</p> </li> <li> <p><strong>Warm (LAZY)</strong> = SESSIONS_HISTORY récent, SCRIPT_VERIFICATION, toute la documentation de référence</p> </li> <li> <p><strong>Cold (backup/)</strong> = tout le reste, déplacé <strong>intact</strong>, sans transformation, sans réindexation</p> </li> </ul> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>.agents/ ├── INDEX.adoc → Sessions N-9 à N (10 dernières) ├── SESSIONS_HISTORY.adoc → Sessions N-9 à N ├── SCRIPT_VERIFICATION.adoc → Dernière vérif (pas d'historique) ├── PROMPT_REPRISE.adoc → Session N+1 uniquement ├── sessions/ → Sessions N-1 à N uniquement └── backup/ └── Y2026-sessions-001-039/ ← Vague froide, COPIE INTÉGRALE ├── INDEX.adoc → Sessions 001 à 039 (complet) ├── SESSIONS_HISTORY.adoc → Sessions 001 à 039 (complet) ├── COMPLETED_TASKS_ARCHIVE.adoc → Sessions 001 à 039 (complet) └── sessions/ → 001.adoc, 002.adoc...</code></pre> </div> </div> <div class="paragraph"> <p>La clé du mécanisme : <strong>le backup n’est pas un index central, c’est une copie conforme de la vague passée</strong>. Quand on dépasse l’horizon des 10 sessions actives, on ne supprime rien. On ne réindexe rien. On ne fusionne rien. On prend le paquet de fichiers agents tel qu’il était à la session N-10, et on le déplace dans <code>backup/</code>.</p> </div> <div class="paragraph"> <p>Les fichiers actifs, eux, sont tronqués : * INDEX : uniquement les 10 dernières lignes (sliding window) * SESSIONS_HISTORY : idem * COMPLETED_TASKS_ARCHIVE : nouveau fichier pour la période en cours * sessions/ : uniquement les 2 dernières sessions</p> </div> <div id="diag-hot-warm-cold" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-f285f9dd9156e0cc545b09f47a25aaf1.svg" alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup" width="1516" height="655"> </div> </div> <div class="paragraph"> <p>Le gain immédiat est massif : le contexte EAGER passe de <strong>~5200 lignes à ~300 lignes</strong>. Une division par 17. Sans avoir perdu une seule ligne de données historiques.</p> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_ce_nest_pas_un_fourre_tout">5. Pourquoi Ce N’est Pas un Fourre-Tout</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’agent, dans sa première itération, craignait que <code>backup/</code> devienne une boîte noire — un dossier où l’on jette des fichiers qu’on ne relira jamais. C’est une peur légitime. Mais elle repose sur une confusion.</p> </div> <div class="paragraph"> <p>Un fourre-tout, c’est quand on jette des fichiers <strong>sans structure, sans convention, sans logique de regroupement</strong>. Ici, le backup est structuré par période (Y2026-001-039), et chaque dossier de backup contient <strong>la même structure</strong> que le dossier <code>.agents/</code> actif : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.</p> </div> <div class="paragraph"> <p>Ce n’est pas un fourre-tout. C’est un <strong>snapshot horodaté</strong>. On pourrait même dire que c’est un mécanisme de versioning simplifié — à ceci près qu’il ne versionne pas les fichiers individuellement, mais le paquet complet de la gouvernance à un instant T.</p> </div> <div class="paragraph"> <p>Quand vous voulez retrouver une information ancienne, vous n’avez pas besoin d’un index central. Vous avez deux options :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong><code>grep</code> ciblé</strong> : <code>grep -r "zsh" backup/Y2026-001-039/</code> — et vous trouvez tout ce qui mentionne zsh dans la période, quel que soit l’angle (INDEX, SESSIONS_HISTORY, archive de session).</p> </li> <li> <p><strong>Réintégration manuelle</strong> : vous copiez temporairement le dossier de backup dans le contexte actif, et vous demandez à l’agent d’analyser cette période spécifique.</p> </li> </ol> </div> <div class="paragraph"> <p>L’index est implicite. Il est dans la structure même des fichiers — chacun étant déjà un index depuis son propre angle.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_méthaphore_des_étagères">6. La Méthaphore des Étagères</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour rendre le mécanisme intuitif, je l’ai conceptualisé en trois étagères :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Étagère 1 (EAGER)</strong> — le plan de travail. Ce dont j’ai besoin <strong>maintenant</strong>. INDEX récent, PROMPT_REPRISE, règles absolues. Léger, immédiat, critique.</p> </li> <li> <p><strong>Étagère 2 (LAZY)</strong> — la bibliothèque de consultation. Ce que je peux aller chercher sur demande. Références techniques, historique récent, procédures. Plus volumineux, mais pas chargé en mémoire.</p> </li> <li> <p><strong>Cave (backup/)</strong> — les archives froides. Tout ce qui est passé mais que je ne veux pas jeter. L’agent n’y entre jamais. L’humain y descend quand il veut distiller.</p> </li> </ul> </div> <div class="paragraph"> <p>L’agent a proposé initialement une quatrième étagère — un <code>index-backup.adoc</code> qui serait LAZY et contiendrait une table des matières de tout le backup. J’ai refusé. Ce serait une redondance de plus dans un système qui souffre déjà de croissance linéaire. La structure des fichiers archivés est déjà un index.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_capteur_à_deux_déclencheurs">7. Le Capteur à Deux Déclencheurs</h2> <div class="sectionbody"> <div class="paragraph"> <p>La conceptualisation était solide, mais il restait un angle mort : <strong>quand exactement déclencher la rotation ?</strong> L’article initial l’identifiait comme une question ouverte. Deux jours plus tard, la réponse est codifiée dans les fichiers de gouvernance de six projets : un capteur à deux déclencheurs.</p> </div> <div class="sect2"> <h3 id="le_déclencheur_automatique_n_10_0">7.1. Le Déclencheur Automatique — <code>N % 10 == 0</code></h3> <div class="paragraph"> <p>Le premier déclencheur est mathématique. Quand le numéro de session est un multiple de 10 — session 10, 20, 30, 40 — la rotation backup s’exécute automatiquement au sein de la procédure de fin de session, juste après l’étape 6.</p> </div> <div class="paragraph"> <p>Pourquoi 10 ? C’est le compromis entre deux forces contraires : une fenêtre trop courte (5 sessions) perd le contexte nécessaire à la continuité ; une fenêtre trop longue (20 sessions) ne résout pas le problème d’embonpoint du contexte. Dix sessions, sur un rythme de une à deux sessions par jour, couvrent environ une semaine de travail — assez pour que l’agent se souvienne des décisions récentes, pas assez pour que le contexte explose.</p> </div> </div> <div class="sect2"> <h3 id="le_déclencheur_par_seuil_500_lignes_eager">7.2. Le Déclencheur par Seuil — 500 Lignes EAGER</h3> <div class="paragraph"> <p>Le second déclencheur est dynamique. Indépendamment du numéro de session, si les fichiers EAGER cumulés dépassent <strong>500 lignes</strong>, la rotation se déclenche.</p> </div> <div class="paragraph"> <p>Ce seuil protège contre le scénario où les sessions sont exceptionnellement productives — beaucoup de contenu écrit en peu de sessions. Une session qui produit 120 lignes de contenu éditorial fait grossir COMPLETED_TASKS_ARCHIVE bien plus vite qu’une session de debug qui corrige deux lignes. Le seuil de 500 lignes, mesuré via <code>wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc</code>, capte cette asymétrie.</p> </div> </div> <div class="sect2"> <h3 id="le_déclencheur_manuel_rotation_backup">7.3. Le Déclencheur Manuel — "rotation backup"</h3> <div class="paragraph"> <p>Enfin, l’humain garde la main. Les mots-clés <code>rotation backup</code>, <code>backup rotation</code> ou <code>lance la rotation backup</code> déclenchent la procédure sur demande, indépendamment de la fin de session. Utile quand on sent que le contexte devient lourd mais qu’on n’est pas encore à un multiple de 10, ou quand on veut archiver une phase de travail avant d’en commencer une nouvelle.</p> </div> <div id="diag-capteur-trigger" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-55d4d9514d8094929a67ce6a6f84538c.svg" alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel" width="573" height="615"> </div> </div> <div class="paragraph"> <p>Ce diagramme montre l’insertion exacte du capteur dans la procédure de fin de session. L’étape 7 est optionnelle — elle ne s’exécute que si une des deux conditions est vraie — mais elle est systématiquement <strong>vérifiée</strong>. La checklist finale inclut <code>[✅] 7. Backup roté (si applicable)</code>.</p> </div> </div> <div class="sect2"> <h3 id="la_boucle_fermée">7.4. La Boucle Fermée</h3> <div class="paragraph"> <p>Ce capteur referme la boucle ouverte par l’article précédent. La gouvernance Eager/Lazy avait résolu le problème de la mémoire agent entre deux sessions. Le mécanisme Hot/Warm/Cold a résolu le problème de la mémoire qui grossit. Le capteur à deux déclencheurs résout le problème du <strong>quand</strong> — retirant à l’humain la charge mentale de surveiller la taille du contexte.</p> </div> <div id="diag-boucle-fermee" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-60666d745fc1e928553aeb38ee39000b.svg" alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur" width="1012" height="488"> </div> </div> <div class="paragraph"> <p>Les trois couches s’empilent logiquement. La première donne une mémoire à l’agent. La deuxième empêche cette mémoire d’étouffer l’agent. La troisième automatise la maintenance de cette mémoire pour que l’humain n’ait pas à y penser.</p> </div> </div> <div class="sect2"> <h3 id="la_migration_effective_sur_cheroliv_com">7.5. La Migration Effective sur cheroliv.com</h3> <div class="paragraph"> <p>Le mécanisme n’est pas resté théorique. Sur <code>cheroliv.com</code>, la première rotation backup a été exécutée le 29 avril 2026 — les sessions -6 à 2 ont migré vers <code>.agents/backup/Y2026-sessions-neg6-a-002/</code> :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Fichier</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Avant rotation</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Après rotation</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Gain</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.agents/INDEX.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">19 sessions listées</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">10 sessions (3-12)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">-9 entrées</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.agents/SESSIONS_HISTORY.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">18 sessions</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">10 sessions</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">-8 entrées</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>COMPLETED_TASKS_ARCHIVE</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">161 lignes (sessions 1-12)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">135 lignes (sessions 3-12)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">-26 lignes</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>sessions/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">20 fichiers</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">10 fichiers</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">-10 fichiers</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>backup/</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Inexistant</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">1 vague froide (10 sessions archivées)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">+1 paquet froid</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le gain en lignes était modeste — le projet est jeune, 12 sessions — mais l’important est que le <strong>mécanisme est en place</strong>. La prochaine rotation automatique se déclenchera à la session 20, ou plus tôt si les 500 lignes EAGER sont atteintes.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_leçon_humain_agent">8. La Leçon Humain-Agent</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette session 048 m’a appris quelque chose de fondamental sur la collaboration avec un agent IA.</p> </div> <div class="paragraph"> <p>L’agent a un biais naturel : il cherche à <strong>optimiser</strong>, à <strong>simplifier</strong>, à <strong>éliminer les redondances</strong>. C’est le biais d’un système entraîné à produire des réponses propres et concises. Face à un dataset riche et multidimensionnel, son premier réflexe est de le réduire à sa plus simple expression.</p> </div> <div class="paragraph"> <p>L’humain, lui, a une intuition différente : il pressent que la redondance structurée est un <strong>atout</strong>, pas un défaut. Que la diversité des angles sur une même réalité est précisément ce qui permettra, plus tard, une distillation de qualité.</p> </div> <div class="paragraph"> <p>Ce n’est pas que l’agent a tort. C’est que son "optimum" n’est pas le mien. L’agent optimise pour le <strong>présent</strong> — le contexte immédiat, la réponse rapide à la question posée. L’humain optimise pour le <strong>futur</strong> — la capacité à retrouver, croiser, distiller dans trois mois ou trois ans.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Ce que je veux, c’est le matériel brut. Tes réflexions, tes hésitations, tes réponses à mes questions. Pas ta synthèse. La synthèse, je sais la faire mieux que toi. Je veux la matière première.</p> </div> </blockquote> </div> <div class="paragraph"> <p>Cette phrase que je lui ai dite en fin de session résume tout. L’agent est un outil de production. L’humain est l’outil de distillation. La gouvernance n’est pas faite pour que l’agent comprenne tout tout seul — elle est faite pour que l’humain puisse, plus tard, travailler le matériau produit.</p> </div> <div class="paragraph"> <p>La vague froide identique est la traduction architecturale de cette philosophie : on ne jette rien, on ne fusionne rien, on ne réindexe rien. On déplace le paquet intact. La distillation viendra plus tard, à la main, par l’humain.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_suite_logique_de_larticle_précédent">9. La Suite Logique de l’Article Précédent</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si vous avez lu <a href="/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">l’article sur la stratégie Eager/Lazy</a>, vous reconnaîtrez la progression naturelle :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Article 0108</strong> — La gouvernance Eager/Lazy : <strong>comment</strong> structurer le contexte agent en deux niveaux de disponibilité</p> </li> <li> <p><strong>Cet article 0110</strong> — Le mécanisme de backup : <strong>comment</strong> faire vieillir ce contexte sans le perdre quand il devient trop volumineux</p> </li> </ol> </div> <div class="paragraph"> <p>Le premier article répondait à la question : « L’agent ne se souvient de rien entre deux sessions, comment lui donner une mémoire ? »</p> </div> <div class="paragraph"> <p>Celui-ci répond à la question qui découle inévitablement de la première : « La mémoire grossit à chaque session, comment l’empêcher d’étouffer l’agent sans l’effacer ? »</p> </div> <div class="paragraph"> <p>La réponse tient en un pattern : <strong>Hot/Warm/Cold</strong>, appliqué aux fichiers de gouvernance. Et en un principe : <strong>ne jamais rien perdre, toujours tout relocaliser</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="liens">10. Liens</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Article précédent : <a href="/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html">Gouverner un Agent IA avec du AsciiDoc</a></p> </li> <li> <p>Mon site : <a href="https://cheroliv.com" class="bare">https://cheroliv.com</a></p> </li> <li> <p>Le projet <code>magic-stick</code> : <a href="https://github.com/cheroliv/magic-stick" class="bare">https://github.com/cheroliv/magic-stick</a></p> </li> </ul> </div> <hr> <div class="paragraph"> <p><strong>Un bon système de gouvernance ne supprime jamais de données. Il les range.</strong></p> </div> </div> </div> https://pages-content.github.io//blog/2026/0109_gradle_jhipster_docker_testcontainers_debugging_post.html Sat, 25 Apr 2026 00:00:00 +0000 blog/2026/0109_gradle_jhipster_docker_testcontainers_debugging_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#la_scène_un_projet_jhipster_un_build_qui_ne_charge_plus">1. La scène : un projet JHipster, un build qui ne charge plus</a></li> <li><a href="#erreur_1_la_variable_fantôme_reportsdir">2. Erreur 1 : la variable fantôme <code>reportsDir</code></a></li> <li><a href="#erreur_2_main_nexiste_plus_sous_gradle_9">3. Erreur 2 : <code>main = "…​"</code> n’existe plus sous Gradle 9</a></li> <li><a href="#erreur_3_sourcecompatibility_nest_plus_une_propriété_de_projet">4. Erreur 3 : <code>sourceCompatibility</code> n’est plus une propriété de projet</a></li> <li><a href="#erreur_4_lassertion_groovy_à_trois_opérandes">5. Erreur 4 : l’assertion Groovy à trois opérandes</a></li> <li><a href="#erreur_5_la_dépendance_implicite_compilekotlin_openapigenerate">6. Erreur 5 : la dépendance implicite <code>compileKotlin</code> → <code>openApiGenerate</code></a></li> <li><a href="#erreur_6_generategitproperties_casse_sur_filteroutputstream_write">7. Erreur 6 : <code>generateGitProperties</code> casse sur <code>FilterOutputStream.write()</code></a></li> <li><a href="#enfin_testcontainers_entre_en_scène">8. Enfin : Testcontainers entre en scène</a></li> <li><a href="#phase_1_la_piste_docker_java">9. Phase 1 : la piste docker-java</a></li> <li><a href="#phase_2_recherche_web_et_fil_dariane_github">10. Phase 2 : recherche web et fil d’ariane GitHub</a></li> <li><a href="#phase_3_le_piège_des_artifacts_renommés">11. Phase 3 : le piège des artifacts renommés</a></li> <li><a href="#phase_4_forcer_la_résolution">12. Phase 4 : forcer la résolution</a></li> <li><a href="#résultat_final">13. Résultat final</a></li> <li><a href="#tableau_récapitulatif_des_corrections">14. Tableau récapitulatif des corrections</a></li> <li><a href="#conclusion">15. Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 15 minutes</div> <p>Vous avez déjà connu ce moment où un simple <code>./gradlew build</code> que vous lancez cent fois par jour se met soudain à planter sur une erreur jamais vue ? Multipliez ça par onze erreurs successives, ajoutez une bonne dose d’incompatibilité Docker Engine 29, saupoudrez de Gradle 9 qui fait disparaître des API qu’on utilisait depuis dix ans. Voici le carnet de bord complet.</p> </div> <hr> <div class="paragraph"> <div class="title">Diagramme 1 — Migration Gradle 9 (chaîne d’erreurs)</div> <p>Objectif : montrer la série d’incompatibilités.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-6215da1a3f4f27918205b5c8ff34a48c.png" alt="Diagram" width="579" height="106"> </div> <div class="title">Figure 1. 👉 Clair, centré sur Gradle.</div> </div> <hr> <div class="paragraph"> <div class="title">Diagramme 2 — Plugins JHipster incompatibles</div> <p>Objectif : isoler les plugins cassés.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-07ed01d932957e366cd8fed4b8aee2a3.png" alt="Diagram" width="569" height="123"> </div> <div class="title">Figure 2. 👉 Vision propre des dépendances.</div> </div> <hr> <div class="paragraph"> <div class="title">Diagramme 3 — Docker 29 / Testcontainers</div> <p>Objectif : problème runtime.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-544e3a93289a5db5b898714292d384f4.png" alt="Diagram" width="788" height="123"> </div> <div class="title">Figure 3. 👉 Histoire claire du runtime.</div> </div> <hr> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-5d4d1754844f7121ef284aa0cc588011.png" alt="Diagram" width="1072" height="193"> </div> <div class="title">Figure 4. une autre maniere de se le representer</div> </div> </div> </div> <div class="sect1"> <h2 id="la_scène_un_projet_jhipster_un_build_qui_ne_charge_plus">1. La scène : un projet JHipster, un build qui ne charge plus</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le projet <code>edster</code> est une application JHipster générée en 2024. Le build script racine <code>build.gradle</code> est resté stable pendant des mois. Puis on décide de monter en version :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 40%;"> <col style="width: 60%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Composant</th> <th class="tableblock halign-left valign-top">Version cible</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">9.4.1</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Java</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">21.0.11-tem (Eclipse Temurin)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">JHipster</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8.x (framework <code>tech.jhipster:jhipster-framework:8.11.0</code>)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Spring Boot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">3.4.5</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Kotlin</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">2.3.0</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Docker Engine</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">29.4.1 (API 1.54)</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le changement de version Java passe via SDKMAN :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sdk use java 21.0.11-tem</code></pre> </div> </div> <div class="paragraph"> <p>Premier lancement :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew build --no-daemon FAILURE: Build failed with an exception. * Where: Build file '/home/.../edster/build.gradle' line: 18 * What went wrong: An exception occurred applying plugin request [id: 'jhipster.cucumber-conventions'] > Failed to apply plugin 'jhipster.cucumber-conventions'. > Could not create task ':cucumberTest'. > Could not create task ':consoleLauncherTest'. > Could not set unknown property 'reportsDir' for task ':consoleLauncherTest'</code></pre> </div> </div> <div class="paragraph"> <p>On ne décolle même pas du chargement du build script. Le problème est dans <code>buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="erreur_1_la_variable_fantôme_reportsdir">2. Erreur 1 : la variable fantôme <code>reportsDir</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>Le script <code>jhipster.cucumber-conventions.gradle</code> contient :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">tasks.register('consoleLauncherTest', JavaExec) { dependsOn(testClasses) String cucumberReportsDir = file("$buildDir/reports/tests") outputs.dir(reportsDir) // <-- reportsDir n'existe PAS classpath = sourceSets["test"].runtimeClasspath main = "org.junit.platform.console.ConsoleLauncher" // ... }</code></pre> </div> </div> <div class="paragraph"> <p>La variable définie est <code>cucumberReportsDir</code>. Celle utilisée est <code>reportsDir</code> — qui n’est définie nulle part.</p> </div> <div class="paragraph"> <p><strong>Correction</strong> : <code>outputs.dir(cucumberReportsDir)</code></p> </div> </div> </div> <div class="sect1"> <h2 id="erreur_2_main_nexiste_plus_sous_gradle_9">3. Erreur 2 : <code>main = "…​"</code> n’existe plus sous Gradle 9</h2> <div class="sectionbody"> <div class="paragraph"> <p>Relance immédiate :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Could not set unknown property 'main' for task ':consoleLauncherTest' of type org.gradle.api.tasks.JavaExec.</code></pre> </div> </div> <div class="paragraph"> <p>Gradle 9 supprime la propriété <code>main</code> au profit de <code>mainClass</code> sur les tâches <code>JavaExec</code>.</p> </div> <div class="paragraph"> <p><strong>Correction</strong> : <code>mainClass = "org.junit.platform.console.ConsoleLauncher"</code></p> </div> </div> </div> <div class="sect1"> <h2 id="erreur_3_sourcecompatibility_nest_plus_une_propriété_de_projet">4. Erreur 3 : <code>sourceCompatibility</code> n’est plus une propriété de projet</h2> <div class="sectionbody"> <div class="paragraph"> <p>Nouvelle erreur :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Could not set unknown property 'sourceCompatibility' for root project 'edster' of type org.gradle.api.Project.</code></pre> </div> </div> <div class="paragraph"> <p>Le script racine avait :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">sourceCompatibility=17 targetCompatibility=17</code></pre> </div> </div> <div class="paragraph"> <p>Gradle 9 supprime ces propriétés au niveau root. Elles doivent vivre dans un bloc <code>java</code>.</p> </div> <div class="paragraph"> <p><strong>Correction</strong> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">java { sourceCompatibility = JavaVersion.VERSION_21 targetCompatibility = JavaVersion.VERSION_21 }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="erreur_4_lassertion_groovy_à_trois_opérandes">5. Erreur 4 : l’assertion Groovy à trois opérandes</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’ancien script contenait :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">assert System.properties["java.specification.version"] == "17" || "21" || "24"</code></pre> </div> </div> <div class="paragraph"> <p>En Groovy, <code>"21"</code> et <code>"24"</code> sont des strings truthy. L’expression résout en <code>(…​ == "17") || true || true</code>, ce qui est toujours vraie — mais la syntaxe est invalide pour l’assertion stricte souhaitée.</p> </div> <div class="paragraph"> <p><strong>Correction</strong> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">assert System.properties["java.specification.version"] in ["17", "21", "23", "24"]</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="erreur_5_la_dépendance_implicite_compilekotlin_openapigenerate">6. Erreur 5 : la dépendance implicite <code>compileKotlin</code> → <code>openApiGenerate</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>Le build progresse. Compilation Kotlin réussie. Puis :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Task ':compileKotlin' uses this output of task ':openApiGenerate' without declaring an explicit or implicit dependency.</code></pre> </div> </div> <div class="paragraph"> <p>Gradle 9 refuse les dépendances implicites entre tâches. Puisque <code>compileKotlin</code> lit les sources générées par <code>openApiGenerate</code>, il faut déclarer le lien.</p> </div> <div class="paragraph"> <p><strong>Correction</strong> dans <code>build.gradle</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">afterEvaluate { tasks.named("compileKotlin").configure { dependsOn(tasks.named("openApiGenerate")) } }</code></pre> </div> </div> <div class="paragraph"> <p>Le <code>afterEvaluate</code> est nécessaire car <code>openApiGenerate</code> est une extension (plugin OpenAPI Generator) et non une tâche directement accessible pendant la phase de configuration.</p> </div> </div> </div> <div class="sect1"> <h2 id="erreur_6_generategitproperties_casse_sur_filteroutputstream_write">7. Erreur 6 : <code>generateGitProperties</code> casse sur <code>FilterOutputStream.write()</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>La compilation Java passe. Les ressources sont processées. Puis :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">> Task :generateGitProperties FAILED No signature of method: java.io.FilterOutputStream.write() is applicable for argument types: (Integer) values: [103]</code></pre> </div> </div> <div class="paragraph"> <p>Le plugin <code>gradle-git-properties</code> version 2.5.0 est incompatible avec Java 21 / Gradle 9. Un bug interne tente d’appeler <code>write(int)</code> via Groovy sur un flux qui l’a fermé.</p> </div> <div class="paragraph"> <p><strong>Correction</strong> dans <code>gradle.properties</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-properties hljs" data-lang="properties">gitPropertiesPluginVersion=2.5.7</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="enfin_testcontainers_entre_en_scène">8. Enfin : Testcontainers entre en scène</h2> <div class="sectionbody"> <div class="paragraph"> <p>Jusqu’ici, c’était du "build script debugging" pur. Chaque erreur était une incompatibilité Gradle 9 ou Java 21 dans les scripts de build. Après les six corrections ci-dessus, le <code>./gradlew assemble</code> passe avec succès.</p> </div> <div class="paragraph"> <p>Mais <code>./gradlew build</code> exécute aussi les tests, et les tests Cucumber utilisent Testcontainers pour lancer un PostgreSQL éphémère.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">Could not find a valid Docker environment. EnvironmentAndSystemPropertyClientProviderStrategy: failed with exception BadRequestException (Status 400: {"message":"client version 1.32 is too old. Minimum supported API version is 1.40"} UnixSocketClientProviderStrategy: failed with exception BadRequestException (Status 400: {"message":"client version 1.32 is too old. Minimum supported API version is 1.40"}</code></pre> </div> </div> <div class="paragraph"> <p>Testcontainers est incapable de communiquer avec Docker. Deux stratégies différentes (variables d’environnement + socket Unix) échouent sur la même erreur.</p> </div> <div id="diag-docker-handshake" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-f31d9e10795d818ce3068413fb5fdd1e.svg" alt="Handshake Docker API refusé par le daemon" width="731" height="616"> </div> </div> </div> </div> <div class="sect1"> <h2 id="phase_1_la_piste_docker_java">9. Phase 1 : la piste docker-java</h2> <div class="sectionbody"> <div class="paragraph"> <p>Premier réflexe : le client Docker Java utilisé par Testcontainers envoie la version API <code>1.32</code> dans son handshake HTTP, mais Docker Engine 29.4.1 exige un minimum de <code>1.40</code>. Le problème est au niveau du client, pas du daemon.</p> </div> <div class="paragraph"> <p>Vérification de la version de docker-java résolue par Testcontainers 1.20.6 :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew dependencies --configuration testRuntimeClasspath | grep docker-java +--- com.github.docker-java:docker-java-api:3.4.1 +--- com.github.docker-java:docker-java-transport:3.4.1</code></pre> </div> </div> <div class="paragraph"> <p>docker-java 3.4.1, datant de Testcontainers 1.20.6. La dernière version publique de docker-java est 3.5.1. Tentons de forcer la montée de version via <code>resolutionStrategy</code> dans le bloc <code>configurations</code> de <code>build.gradle</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">configurations { all { resolutionStrategy.eachDependency { details -> if (details.requested.group == "com.github.docker-java" && details.requested.name.startsWith("docker-java")) { details.useVersion("3.5.1") } } } }</code></pre> </div> </div> <div class="paragraph"> <p>Relance du build. Même erreur : <code>client version 1.32 is too old</code>.</p> </div> <div class="paragraph"> <p>Vérification du cache Gradle : les JARs ont bien été re-téléchargés, mais l’erreur persiste. docker-java 3.5.1 envoie toujours <code>1.32</code>. Cette version n’est donc PAS suffisante pour Docker Engine 29.4.1.</p> </div> <div class="paragraph"> <p><strong>Action de purification</strong> : vider complètement le cache Gradle, juste pour être sûr :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">rm -rf ~/.gradle/caches rm -rf /path/to/project/.gradle</code></pre> </div> </div> <div class="paragraph"> <p>Relance complète après purge. Même erreur.</p> </div> </div> </div> <div class="sect1"> <h2 id="phase_2_recherche_web_et_fil_dariane_github">10. Phase 2 : recherche web et fil d’ariane GitHub</h2> <div class="sectionbody"> <div class="paragraph"> <p>docker-java 3.5.1 est insuffisant. Ne reste plus qu’à chercher si quelqu’un a rencontré ce problème exact.</p> </div> <div class="paragraph"> <p>Recherche ciblée sur les issues testcontainers-java et docker-java :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">site:github.com/testcontainers "client version 1.32 is too old" site:github.com/docker-java "client version 1.32" Docker Engine 29</code></pre> </div> </div> <div class="paragraph"> <p>Premiers résultats immédiats :</p> </div> <div class="ulist"> <ul> <li> <p><a href="https://github.com/testcontainers/testcontainers-java/issues/11210">testcontainers-java#11210</a> — <code>[Bug]: client version 1.32 is too old. Minimum supported API version is 1.44</code></p> </li> <li> <p><a href="https://github.com/testcontainers/testcontainers-java/issues/11212">testcontainers-java#11212</a> — <code>[Bug]: Docker 29.0.0 could not find a valid Docker environment</code></p> </li> <li> <p><a href="https://github.com/testcontainers/testcontainers-java/issues/11491">testcontainers-java#11491</a> — <code>[Bug]: Incompatibility in Ubuntu Github runners with Docker Engine 29.1.*</code></p> </li> </ul> </div> <div class="paragraph"> <p>Le fil d’Ariane est clair : Docker Engine 29.x a élevé son minimum API version de <code>1.24</code> (ancien défaut) à <code>1.40</code>. Testcontainers 1.20.x utilise docker-java 3.4.x qui négocie la version API en envoyant <code>1.32</code>. Le daemon refuse poliment mais fermement.</p> </div> <div class="paragraph"> <p>Dans l’issue #11491, un mainteneur répond :</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Hi, I have a project running with version 2.0.3 on a GH runner with engine 29.1 and it works. Can you all please check there is no version conflict? Please, remember all modules were prefixed with <code>testcontainers-</code>. So, starting with version 2.x we went from <code>postgresql</code> to <code>testcontainers-postgresql</code></p> </div> </blockquote> </div> <div class="paragraph"> <p>Cette réponse contient <strong>deux informations critiques</strong> :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Testcontainers 2.0.3+ résout le problème</p> </li> <li> <p>Les modules ont été <strong>renommés avec le préfixe <code>testcontainers-</code></strong></p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="phase_3_le_piège_des_artifacts_renommés">11. Phase 3 : le piège des artifacts renommés</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le renommage est brutal. En Testcontainers 2.x, plus aucun des anciens noms ne fonctionne sous ce nom-là :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 50%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Ancien nom (1.x)</th> <th class="tableblock halign-left valign-top">Nouveau nom (2.x)</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:postgresql</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:testcontainers-postgresql</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:jdbc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:testcontainers-jdbc</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:junit-jupiter</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:testcontainers-junit-jupiter</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>org.testcontainers:testcontainers</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">inchangé</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Première tentative : appliquer la BOM Testcontainers 2.0.5 et les nouveaux noms d’artifacts dans <code>build.gradle</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">dependencies { testImplementation platform("org.testcontainers:testcontainers-bom:2.0.5") testImplementation "org.testcontainers:testcontainers-postgresql" testImplementation "org.testcontainers:testcontainers-jdbc" testImplementation "org.testcontainers:testcontainers-junit-jupiter" testImplementation "org.testcontainers:testcontainers" }</code></pre> </div> </div> <div class="paragraph"> <p><code>./gradlew build</code></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">FAILURE: Could not find org.testcontainers:jdbc:2.0.5. Could not find org.testcontainers:junit-jupiter:2.0.5.</code></pre> </div> </div> <div class="paragraph"> <p><strong>Le BOM de testcontainers-bom ne suffit pas.</strong> Pourquoi ? Parce que Spring Boot 3.4.5 expose son propre BOM de gestion de dépendances (<code>spring-boot-dependencies</code>) qui <strong>gagne</strong> sur le BOM de Testcontainers dans la résolution transitive. Spring Boot fixe <code>testcontainers</code> à <code>1.20.6</code>, et donc tous les artifacts qui ne sont pas explicitement dans le BOM Spring Boot (comme les nouveaux <code>testcontainers-*</code>) résolvent vers les anciens noms <code>1.20.6</code> — qui n’existent plus dans cette version.</p> </div> <div class="paragraph"> <p>En inspectant le <code>dependencies --configuration testRuntimeClasspath</code>, on trouve :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">+--- org.testcontainers:testcontainers -> 1.20.6 (*) | \--- org.testcontainers:testcontainers:2.0.5 -> 1.20.6</code></pre> </div> </div> <div class="paragraph"> <p>Le <code>→</code> indique la substitution : Testcontainers 2.0.5 est <strong>demandé</strong>, mais Spring Boot force <code>1.20.6</code>.</p> </div> <div id="diag-bom-war" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-714056a094f875d4bd0cf8db572918d3.svg" alt="Conflit entre le BOM Spring Boot et le BOM Testcontainers" width="1111" height="321"> </div> </div> </div> </div> <div class="sect1"> <h2 id="phase_4_forcer_la_résolution">12. Phase 4 : forcer la résolution</h2> <div class="sectionbody"> <div class="paragraph"> <p>La stratégie devient double :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Forcer docker-java à sa version 3.7.1 (testée comme compatible Docker Engine 29)</p> </li> <li> <p>Forcer Testcontainers core à 2.0.5 en contournant le BOM Spring Boot</p> </li> </ol> </div> <div id="diag-resolution-override" class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-0e6edf1a58135d9df65ae14483179ddf.svg" alt="resolutionStrategy.eachDependency court-circuite le BOM Spring Boot" width="1103" height="468"> </div> </div> <div class="paragraph"> <p><strong>Correction finale</strong> dans <code>build.gradle</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-groovy hljs" data-lang="groovy">configurations { all { resolutionStrategy.eachDependency { details -> if (details.requested.group == "com.github.docker-java" && details.requested.name.startsWith("docker-java")) { details.useVersion("3.7.1") } if (details.requested.group == "org.testcontainers" && details.requested.name == "testcontainers") { details.useVersion("2.0.5") } } } } dependencies { testImplementation platform("org.testcontainers:testcontainers-bom:2.0.5") testImplementation "org.testcontainers:testcontainers-jdbc" testImplementation "org.testcontainers:testcontainers-junit-jupiter" testImplementation "org.testcontainers:testcontainers-postgresql" testImplementation "org.testcontainers:testcontainers" // ... autres dépendances Spring Boot }</code></pre> </div> </div> <div class="paragraph"> <p>Le <code>resolutionStrategy.eachDependency</code> est le seul moyen d’outrepasser le BOM <code>spring-boot-dependencies</code> géré par le plugin Spring Boot. Le test d’égalité sur <code>details.requested.name == "testcontainers"</code> est volontairement restrictif : on ne force que le module core. Les modules <code>testcontainers-*</code> suivent le BOM de Testcontainers 2.0.5 qu’on a explicitement déclaré.</p> </div> </div> </div> <div class="sect1"> <h2 id="résultat_final">13. Résultat final</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew build --no-daemon > Task :consoleLauncherTest [2 containers found] [2 containers started] [2 containers successful] BUILD SUCCESSFUL in 1m 16s</code></pre> </div> </div> <div class="paragraph"> <p>Testcontainers 2.0.5 + docker-java 3.7.1 parviennent enfin à créer leurs containers PostgreSQL via Docker Engine 29.4.1. L’erreur métier finale (HTTP 500 sur le test Cucumber) est un problème applicatif totalement indépendant du build script.</p> </div> </div> </div> <div class="sect1"> <h2 id="tableau_récapitulatif_des_corrections">14. Tableau récapitulatif des corrections</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 12.5%;"> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 37.5%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">#</th> <th class="tableblock halign-left valign-top">Fichier</th> <th class="tableblock halign-left valign-top">Problème</th> <th class="tableblock halign-left valign-top">Correction</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Variable <code>reportsDir</code> inexistante</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>outputs.dir(cucumberReportsDir)</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>buildSrc/src/main/groovy/jhipster.cucumber-conventions.gradle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>main</code> déprécié Gradle 9</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>mainClass</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>build.gradle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>sourceCompatibility</code> top-level interdit Gradle 9</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Bloc <code>java { sourceCompatibility = JavaVersion.VERSION_21 }</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>build.gradle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Assertion Groovy syntaxiquement invalide</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>assert …​ in ["17", "21", "23", "24"]</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>build.gradle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Dépendance implicite <code>compileKotlin</code> → <code>openApiGenerate</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>afterEvaluate { tasks.named("compileKotlin").dependsOn("openApiGenerate") }</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">6</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>gradle.properties</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>gitPropertiesPluginVersion</code> incompatible Java 21</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>2.5.7</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">7</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Cache Gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">docker-java 3.5.1 testé, résolu mais insuffisant</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Purge + passage docker-java 3.7.1</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">8</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>build.gradle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Testcontainers 1.20.6 incompatible Docker Engine 29</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Forçage Testcontainers 2.0.5 + prefix <code>testcontainers-*</code> + resolutionStrategy vs Spring Boot BOM</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="conclusion">15. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si votre build JHipster/Gradle plante après une montée de version vers Gradle 9 + Docker Engine 29, les erreurs se répartissent en deux catégories :</p> </div> <div class="paragraph"> <p><strong>Erreurs de build script</strong> (les 6 premières) : Gradle 9 supprime des propriétés et des syntaxes qui marchaient depuis des années (<code>sourceCompatibility=</code>, <code>main =</code>, <code>reportsDir</code>). Ce sont des migrations mécaniques une fois qu’on connaît la nouvelle API.</p> </div> <div class="paragraph"> <p><strong>Erreurs de runtime Docker</strong> (les 2 dernières) : Docker Engine 29.4.1 écarte les clients API < 1.40. Testcontainers 1.20.6 (imposé par Spring Boot 3.4.5) utilise docker-java 3.4.1 qui envoie 1.32. Seul Testcontainers 2.0.5 + docker-java 3.7.1 résout le problème, avec le renommage des artifacts et le forçage de version via <code>resolutionStrategy.eachDependency</code> comme seul moyen de contourner le BOM implicite de Spring Boot.</p> </div> <div class="paragraph"> <p>Le build script Gradle à la racine du projet est maintenant propre. <code>./gradlew build</code> passe sur Java 21, Gradle 9.4.1, Spring Boot 3.4.5 et Docker Engine 29.4.1.</p> </div> </div> </div> https://pages-content.github.io//blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html Fri, 24 Apr 2026 00:00:00 +0000 blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html <div class="sect1"> <h2 id="résumé">Résumé</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quand on travaille avec un agent IA comme Opencode sur des projets complexes sur plusieurs sessions, on fait face à un problème fondamental : <strong>la fuite de contexte</strong>. L’agent ne se souvient pas de la session précédente. Tout ce qu’on lui a expliqué — l’architecture, les conventions, l’état du backlog — est perdu. Reconstruire ce contexte à chaque session est coûteux, lent et source d’erreur.</p> </div> <div class="paragraph"> <p>Cet article expose la stratégie artisanale que j’ai construite pour résoudre ce problème : un système de gouvernance persistant basé sur des fichiers AsciiDoc, avec une dichotomie <strong>Eager/Lazy</strong> pour optimiser la consommation du token de contexte, et une <strong>procédure de fin de session incontournable</strong> pour assurer la continuité.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_scène_lundi_21_avril_9h00">1. La Scène : Lundi 21 Avril, 9h00</h2> <div class="sectionbody"> <div class="paragraph"> <p>Je rouvre Opencode pour reprendre mon plugin Gradle <code>plantuml-plugin</code>. Hier soir, j’ai passé trois heures à discuter avec l’agent de l’architecture du pool de clés API — rotation round-robin, gestion des quotas, fallback automatique. Ce matin, l’agent me regarde avec des yeux de poisson rouge.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p> — Bonjour, je suis votre assistant Opencode. Comment puis-je vous aider aujourd’hui ?</p> </div> </blockquote> </div> <div class="paragraph"> <p>Pas de — Ah oui, le pool de clés API, on en était à la structure YAML. Pas de — Attention, <code>PlantumlManager</code> est un objet Kotlin singleton, pas une classe. Pas de — Non, on a décidé hier que <code>SyntaxValidationResult</code> restait une sealed class nested dans <code>PlantumlService</code>.</p> </div> <div class="paragraph"> <p>Tout est à refaire. Ou plutôt : tout est à réexpliquer. Je vais passer les vingt premières minutes de ma session à reconstituer un contexte que l’agent a déjà eu entre les mains hier. Vingt minutes de tokens brûlés. Vingt minutes où je pourrais coder, mais où je fais du pédagogique obligatoire.</p> </div> <div class="paragraph"> <p>Ce n’est pas un bug d’Opencode. C’est la nature même des LLM conversationnels : entre deux sessions, la mémoire de travail est <strong>entièrement effacée</strong>. L’agent ne se souvient pas de la mission précédente, des décisions prises, des pièges identifiés, du code qu’on a écrit ensemble.</p> </div> <div class="paragraph"> <p>J’ai vécu ça des dizaines de fois. Sur quatre projets simultanés. Avec des sessions qui s’enchaînent sur des semaines. J’ai calculé : en moyenne, <strong>30 à 40 % du temps de session</strong> était consacré à recontextualiser l’agent. À la session 87 du projet <code>plantuml-plugin</code>, j’ai craqué. Je ne pouvais plus me permettre de réexpliquer pour la dixième fois que <code>AttemptEntry</code> est une data class top-level dans <code>DiagramProcessor.kt</code>.</p> </div> <div class="paragraph"> <p>Il me fallait un système. Pas un hack. Une vraie gouvernance.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_genèse_du_chaos_à_la_méthode">2. La Genèse : Du Chaos à la Méthode</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="les_premières_sessions_lâge_des_ténèbres">2.1. Les Premières Sessions : L’Âge des Ténèbres</h3> <div class="paragraph"> <p>Mon premier projet avec Opencode, <code>plantuml-plugin</code>, a démarré sans aucune gouvernance. Je pose une question, l’agent répond, on itère, la session se termine, et le lendemain on repart de zéro. C’était la session 1, puis la 2, puis la 3…​ jusqu’à la session 62 où je réalise que j’ai perdu des heures cumulées à réexpliquer la même architecture.</p> </div> <div class="paragraph"> <p>À la session 62, les chiffres sont là : <strong>198 tests unitaires passent</strong>, <strong>42 tests fonctionnels validés</strong>, le plugin fonctionne. Mais le coût cognitif est insupportable. Chaque nouvelle session commence par un monologue de vingt minutes sur la structure du projet.</p> </div> </div> <div class="sect2"> <h3 id="lépisode_du_site_yml_détruit_session_2_bakery_plugin">2.2. L’Épisode du site.yml Détruit (Session 2, bakery-plugin)</h3> <div class="paragraph"> <p>La méthode naît aussi d’une catastrophe. Sur le projet <code>bakery-gradle</code>, à la session 2, je demande à l’agent de modifier le fichier <code>site.yml</code>. L’agent, sans vérifier si le fichier est versionné, fait un <code>Write</code> complet qui écrase le contenu. Résultat : les tokens réels (clés API Firebase, secrets de déploiement) sont remplacés par des placeholders factices. Le fichier n’était pas dans git — il était dans <code>.gitignore</code> pour protéger les secrets.</p> </div> <div class="paragraph"> <p>Sans sauvegarde. Sans <code>git restore</code> possible. Je suis bloqué. Il me faut reconstruire manuellement le fichier de configuration, retrouver les tokens dans mes gestionnaires de mots de passe, tout recoller.</p> </div> <div class="paragraph"> <p>C’est de cette frustration que naît la <strong>Règle Absolue 1b</strong> :</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p><strong>NE JAMAIS écraser</strong> un fichier config avec un <code>Write</code> complet quand un <code>Edit</code> partiel suffit. <strong>NE JAMAIS remplacer</strong> des valeurs sensibles par des valeurs factices. <strong>Vérifier <code>git check-ignore</code> et <code>git ls-files</code></strong> avant toute modification.</p> </div> </blockquote> </div> <div class="paragraph"> <p>Cette règle, aujourd’hui gravée dans le marbre de tous mes fichiers <code>AGENT.adoc</code> et <code>INDEX.adoc</code> sur quatre projets, est née d’une erreur réelle qui m’a coûté une heure de travail manuel.</p> </div> </div> <div class="sect2"> <h3 id="la_migration_markdown_asciidoc_session_1_cheroliv_com">2.3. La Migration Markdown → AsciiDoc (Session 1, cheroliv.com)</h3> <div class="paragraph"> <p>Le 25 avril 2026, sur <code>cheroliv.com</code>, je prends une décision radicale : convertir l’intégralité de la gouvernance de Markdown vers AsciiDoc. Ce n’est pas esthétique. C’est fonctionnel. AsciiDoc offre une structure sémantique que les LLM lisent mieux : sections hiérarchiques, tableaux typés, admonitions (<code>NOTE</code>, <code>WARNING</code>, <code>CAUTION</code>), attributs de document lisibles par la machine.</p> </div> <div class="paragraph"> <p>La session 1 de <code>cheroliv.com</code> formalise la structure :</p> </div> <div class="ulist"> <ul> <li> <p>Conversion de <code>AGENTS.md</code> en <code>AGENT.adoc</code></p> </li> <li> <p>Création des agents spécialisés : <code>CODER.adoc</code>, <code>SCRUM_MASTER.adoc</code>, <code>PLANTUML_DESIGNER.adoc</code></p> </li> <li> <p>Création de la structure Eager/Lazy : <code>INDEX.adoc</code>, <code>SESSIONS_HISTORY.adoc</code>, <code>AGENT_SESSION_MANAGER.adoc</code>, <code>SESSION_CHECKLIST.adoc</code>, <code>PROCEDURES.adoc</code></p> </li> </ul> </div> <div class="paragraph"> <p>Un seul commit : <code>90975e9 refactor: migrate agent governance from Markdown to AsciiDoc</code>. Et le site continue de fonctionner.</p> </div> <div id="diag-timeline" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-1ffbad829836ed4bec6c66e6b3038145.svg" alt="Timeline de croissance des sessions sur les 4 projets" width="2373" height="290"> </div> </div> <div class="paragraph"> <p>La timeline ci-dessus illustre la progression réelle. Le point de bascule est la session 87 : c’est là que la frustration du recontextualisation répétée dépasse le seuil de tolérance, et que la méthode Eager/Lazy cesse d’être une idée pour devenir une obligation.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_stratégie_eagerlazy_en_profondeur">3. La Stratégie : Eager/Lazy en Profondeur</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="philosophie_cache_informatique_appliqué_à_la_cognition">3.1. Philosophie : Cache Informatique Appliqué à la Cognition</h3> <div class="paragraph"> <p>Mon approche s’inspire directement de la gestion de cache informatique. Tout ce qui est <strong>critique et fréquemment utilisé</strong> doit être immédiatement accessible (<strong>Eager</strong>). Tout ce qui est <strong>contextuel ou volumineux</strong> doit être chargé sur demande (<strong>Lazy</strong>).</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 14.2857%;"> <col style="width: 42.8571%;"> <col style="width: 42.8572%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"></th> <th class="tableblock halign-left valign-top">Eager (Tableau de Bord)</th> <th class="tableblock halign-left valign-top">Lazy (Manuel du Propriétaire)</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Taille</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">< 100 lignes, < 10k tokens</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Illimité, détaillé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Chargement</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Auto, en début de session</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Sur demande de l’agent</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Contenu</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Règles absolues, mission courante, état critique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Archives de sessions, historique complet, procédures détaillées, références techniques</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Rôle</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Orienter immédiatement l’agent</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Répondre aux questions de contexte profond</p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="les_fichiers_eager_le_tableau_de_bord">3.2. Les Fichiers Eager : Le Tableau de Bord</h3> <div class="paragraph"> <p>Ces fichiers vivent à la racine de chaque projet et sont chargés automatiquement par l’agent au début de chaque session. Ils forment le <strong>tableau de bord</strong> — information critique, immédiatement accessible.</p> </div> <div id="diag-eager-lazy" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-05c08d0c2b5bf285c4c1fee60314a0e7.svg" alt="Architecture Eager/Lazy des fichiers de gouvernance" width="2181" height="426"> </div> </div> <div class="paragraph"> <p><strong><code>AGENT.adoc</code></strong> — Le fichier maître. Sur <code>cheroliv.com</code>, il fait 200 lignes et contient :</p> </div> <div class="ulist"> <ul> <li> <p>Les règles absolues du projet (pas de commit sans permission, pas de <code>rm</code> sans confirmation)</p> </li> <li> <p>La structure du projet et les conventions de code</p> </li> <li> <p>Les commandes essentielles (<code>./gradlew serve</code>, <code>./gradlew test</code>)</p> </li> <li> <p>Les épopées et le backlog produit (user stories priorisées)</p> </li> <li> <p>Les critères de qualité transverses (accessibilité, responsive, compatibilité)</p> </li> </ul> </div> <div class="paragraph"> <p>Sur <code>bakery-plugin</code>, la Règle 0 est différente : <strong><code>./gradlew -q publishToMavenLocal</code> obligatoire après chaque modification du code source</strong>. Parce que tester le plugin sans republier le JAR local m’a fait perdre une heure à débugger un code qui n’était pas encore empaqueté.</p> </div> <div class="paragraph"> <p><strong><code>PROMPT_REPRISE.adoc</code></strong> — La mission de la session en cours. Mis à jour à chaque fin de session, il contient :</p> </div> <div class="ulist"> <ul> <li> <p>Le numéro de session et la mission prioritaire</p> </li> <li> <p>Le résumé de la session précédente (ce qui a été fait, ce qui reste à faire)</p> </li> <li> <p>Les critères d’acceptation de la session courante</p> </li> <li> <p>Les rappels techniques spécifiques</p> </li> </ul> </div> <div class="paragraph"> <p><strong><code>.agents/INDEX.adoc</code></strong> — Le point d’entrée. Il résume les règles absolues, les sessions récentes, et surtout le <strong>portefeuille de projets</strong> gérés avec la même méthodologie. À ce jour, cinq projets y figurent :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>| magic-stick | Session 23 | SCRIPT_VERIFICATION.adoc | 2026-04-27 | | bakery-gradle | Session 11 | TEST_COVERAGE_ANALYSIS | 2026-04-27 | | cheroliv.com | Session 9 | TEST_COVERAGE_ANALYSIS | 2026-04-27 | | plantuml-gradle| Session 133| TEST_COVERAGE_ANALYSIS | 2026-04-23 | | jhipster-gradle-plugins | Session 1 | TEST_COVERAGE_ANALYSIS | 2026-04-28 |</code></pre> </div> </div> <div class="paragraph"> <p><strong><code>*_ESSENTIALS.adoc</code></strong> — Un ajout récent (Session 109, plantuml-plugin) pour optimiser encore le contexte Eager. Au lieu de charger 200 lignes de contexte métier sur le pool de clés API, je charge 50 lignes de l’essentiel, et les 150 autres lignes restent en LAZY dans <code>*_REFERENCE.adoc</code>.</p> </div> <div class="paragraph"> <p>Résultat mesuré : passage de <strong>~25k tokens EAGER à ~10k tokens</strong> (gain de 60%). L’agent n’a plus besoin de rappels énergivores.</p> </div> <div class="sect3"> <h4 id="le_chaînon_manquant_opencode_json">3.2.1. Le Chaînon Manquant : <code>opencode.json</code></h4> <div class="paragraph"> <p>Je dois vous avouer une chose que j’ai failli oublier de documenter. Au-dessus de tous ces fichiers .adoc, il y a un minuscule fichier JSON sans lequel rien ne fonctionne. Il s’appelle <code>opencode.json</code> et il fait six lignes. Littéralement six lignes.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-json" data-lang="json">{ "$schema": "https://opencode.ai/config.json", "instructions": [ "AGENT.adoc" ] }</code></pre> </div> </div> <div class="paragraph"> <p>C’est ce fichier qui dit à Opencode : « Au démarrage, charge <code>AGENT.adoc</code> automatiquement. » Sans lui, l’agent est une page blanche exactement comme je le décrivais au début de l’article. Avec lui, l’agent a déjà entre les mains les règles absolues, l’architecture du projet, et les commandes essentielles — avant même que je dise bonjour.</p> </div> <div class="paragraph"> <p>J’ai découvert l’importance de ce fichier par hasard. Sur <code>bakery-plugin</code>, il n’existait pas. Je me demandais pourquoi l’agent était systématiquement plus « perdu » sur ce projet que sur les autres. Les règles absolues étaient bien dans <code>AGENT.adoc</code> — mais <code>AGENT.adoc</code> n’était jamais chargé. L’agent ne lisait que ce que je lui disais de lire, manuellement, à chaque session. C’était la session 11 de <code>bakery-plugin</code> quand j’ai réalisé l’absence du <code>opencode.json</code>. Je l’ai créé — et la session 12 a démarré comme les autres.</p> </div> <div class="paragraph"> <p>Ce fichier est tellement évident pour moi maintenant que je ne pensais même plus à lui. Une erreur classique du développeur qui connaît trop son outil. Aujourd’hui, je le crée systématiquement <strong>avant</strong> <code>AGENT.adoc</code>. C’est la première pierre.</p> </div> </div> <div class="sect3"> <h4 id="la_dualité_de_index_adoc">3.2.2. La Dualité de <code>INDEX.adoc</code></h4> <div class="paragraph"> <p>Une autre subtilité qui mérite d’être explicitée : <code>INDEX.adoc</code> vit dans <code>.agents/</code> — un dossier que j’ai présenté comme LAZY. Pourtant, je le liste comme EAGER dans tous mes tableaux. Il y a une tension apparente ici.</p> </div> <div class="paragraph"> <p>La réalité terrain : les fichiers <code>.agents/INDEX.adoc</code> sont bien chargés automatiquement en début de session, au même titre que <code>AGENT.adoc</code> et <code>PROMPT_REPRISE.adoc</code>. Ils sont dans <code>.agents/</code> pour des raisons d’organisation — ne pas envahir la racine — mais leur comportement est EAGER.</p> </div> <div class="paragraph"> <p>Sur <code>plantuml-plugin</code>, <code>INDEX.adoc</code> fait 200 lignes et contient les règles absolues <strong>complètes</strong> avec leur historique (les leçons des sessions passées), les EPICs avec scores, et le portefeuille de projets. C’est le document que l’agent consulte pour savoir « où on en est ». Sur <code>bakery-plugin</code>, il fait 150 lignes avec la roadmap et les sessions récentes.</p> </div> <div class="paragraph"> <p>La redondance volontaire entre <code>AGENT.adoc</code> et <code>INDEX.adoc</code> peut surprendre. Les règles absolues sont présentes dans les deux. Pourquoi ? Parce qu’elles remplissent deux rôles différents : dans <code>AGENT.adoc</code>, elles sont <strong>explicatives</strong> (le storytelling de la règle, la leçon apprise) ; dans <code>INDEX.adoc</code>, elles sont <strong>exécutives</strong> (la règle nue, sans justification, pour une consultation rapide). L’agent lit <code>AGENT.adoc</code> une fois pour <strong>comprendre</strong> ; il relit <code>INDEX.adoc</code> à chaque session pour <strong>appliquer</strong>. Deux usages, deux formats.</p> </div> <div id="diag-dualite-agent-index" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-3c2178e1ba116d50829d1c4dc6dda277.svg" alt="Comparaison entre AGENT.adoc (narratif) et INDEX.adoc (exécutif)" width="996" height="614"> </div> </div> <div class="paragraph"> <p>Cette redondance assumée est un choix de conception. Elle consomme ~50 lignes supplémentaires de tokens EAGER — mais elle garantit que l’agent a toujours les règles sous les yeux, y compris dans le format concis qui facilite l’obéissance immédiate.</p> </div> </div> </div> <div class="sect2"> <h3 id="les_fichiers_lazy_le_manuel_du_propriétaire">3.3. Les Fichiers LAZY : Le Manuel du Propriétaire</h3> <div class="paragraph"> <p>Ces fichiers vivent dans <code>.agents/</code> et ne sont lus que quand l’agent en a besoin. Ils constituent la véritable richesse de la méthode, car ils accumulent la connaissance du projet sans polluer le contexte courant.</p> </div> <div id="diag-agents-tree" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-1161102b78c2ff0d2716a6cd7264b3ff.svg" alt="Arborescence complète du dossier .agents/" width="2853" height="340"> </div> </div> <div class="paragraph"> <p>L’arborescence ci-dessus montre la structure réelle du dossier <code>.agents/</code> sur <code>plantuml-plugin</code>, le projet le plus mature. Notez la profondeur en trois couches : fichiers racine (métadonnées), dossier <code>sessions/</code> (archives chronologiques), et dossier <code>archives/</code> (agrégations et résumés). C’est cette profondeur qui transforme la gouvernance d’un simple fichier TODO en une <strong>mémoire organisationnelle complète</strong>.</p> </div> <div class="paragraph"> <p><strong><code>.agents/sessions/{N}-{titre}.adoc</code></strong> — Les archives détaillées de chaque session. Actuellement :</p> </div> <div class="ulist"> <ul> <li> <p><code>plantuml-plugin</code> : <strong>133 sessions archivées</strong> (de la session 1 à 133)</p> </li> <li> <p><code>bakery-plugin</code> : <strong>11 sessions</strong></p> </li> <li> <p><code>magic-stick</code> : <strong>23 sessions</strong></p> </li> <li> <p><code>cheroliv.com</code> : <strong>9 sessions formelles</strong> + 7 sessions pré-système reconstituées rétroactivement</p> </li> </ul> </div> <div class="paragraph"> <p>Chaque archive contient le contexte complet de la session, les décisions prises, les problèmes rencontrés et leur résolution, les commandes exécutées et leur output.</p> </div> <div class="paragraph"> <p><strong><code>.agents/SESSIONS_HISTORY.adoc</code></strong> — Un tableau récapitulatif de toutes les sessions avec un score. Exemple sur <code>cheroliv.com</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>| -6 | 2025-05 | chore | Initialisation projet Gradle/JBake | 7/10 | 1 | 2026-04-25 | chore | Migration gouvernance agent | 8/10 | 7 | 2026-04-27 | debug/fix | Correction publishSite | 9/10 | 8 | 2026-04-27 | analyse | Analyse article 0108 | 7/10</code></pre> </div> </div> <div class="paragraph"> <p><strong><code>.agents/COMPLETED_TASKS_ARCHIVE_{mois}.adoc</code></strong> — Les tâches terminées archivées par mois, pour ne pas surcharger le backlog actif. Quand une user story est terminée, elle migre ici. Le backlog reste lisible : maximum 10 items actifs.</p> </div> <div class="paragraph"> <p><strong><code>.agents/PROCEDURES.adoc</code></strong> — Templates détaillés de la procédure de fin de session. Long, mais lu une seule fois par l’agent quand il apprend la méthode. Ensuite, la procédure devient mécanique.</p> </div> <div class="paragraph"> <p><strong><code>.agents/AGENT_MODUS_OPERANDI.adoc</code></strong> — La documentation stratégique complète. Sur <code>plantuml-plugin</code>, ce fichier fait <strong>900+ lignes</strong> et se nomme en réalité <code>AGENT_METHODOLOGIES.adoc</code> — j’ai changé le nom entre l’écriture de cet article et la mise en place effective. Ce genre de divergence de naming est inévitable dans un système artisanal qui évolue. L’important est la convention de nommage : si le fichier documente la <strong>méthode</strong>, il commence par <code>AGENT_</code> ou un préfixe explicite. Il documente la méthodologie Eager/Lazy, les patterns à suivre, les anti-patterns à éviter. Il est LAZY parce qu’un agent n’a pas besoin de relire toute la stratégie à chaque session, seulement quand il y a ambiguïté.</p> </div> <div class="paragraph"> <p><strong><code>*_REFERENCE.adoc</code></strong> — Les références techniques spécifiques au projet. Sur <code>magic-stick</code>, deux fichiers LAZY denses :</p> </div> <div class="ulist"> <ul> <li> <p><code>AB_PARTITION_REFERENCE.adoc</code> (147 lignes) — Architecture partition A/B GPT, scripts <code>update-system.sh</code>, tailles estimées, mécanisme de rollback</p> </li> <li> <p><code>BOOT_TEST_REFERENCE.adoc</code> (144 lignes) — Procédure QEMU + VNC pour tester le boot de l’ISO sans matériel physique, checklist BIOS/UEFI, limitations CI/CD</p> </li> </ul> </div> <div class="paragraph"> <p>Sur <code>plantuml-plugin</code> :</p> </div> <div class="ulist"> <ul> <li> <p><code>ARCHITECTURE.adoc</code> (134 lignes) — Structure des 11 data classes, points d’attention (pièges à éviter), commandes de test optimisées</p> </li> <li> <p><code>API_KEY_POOL_REFERENCE.adoc</code> — Détails complets du pool de clés (LAZY pendant que <code>ESSENTIALS</code> est EAGER)</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="les_agents_spécialisés_une_équipe_virtuelle">4. Les Agents Spécialisés : Une Équipe Virtuelle</h2> <div class="sectionbody"> <div class="paragraph"> <p>La gouvernance ne se limite pas à des fichiers passifs. J’ai formalisé des <strong>rôles d’agents spécialisés</strong> dans des fichiers LAZY dédiés, qui définissent le workflow attendu selon le type de tâche.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> <col style="width: 25%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Agent</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fichier</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Rôle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Projet</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>CODER</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>CODER.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Implémentation FTL/CSS/JS, balises sémantiques, critères d’accessibilité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">cheroliv.com</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>SCRUM Master</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SCRUM_MASTER.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Planification US, découpage en sous-tâches, détection des dépendances</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">cheroliv.com</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>PlantUML Designer</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>PLANTUML_DESIGNER.adoc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Création de diagrammes, syntaxe PUML, intégration JBake</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">cheroliv.com</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le fichier <code>CODER.adoc</code> sur <code>cheroliv.com</code> contient des règles concrètes : <em>Un seul <code><h1></code> par page</em>, <em>Préfixer les chemins avec `${content.rootpath}`</em>, <em>Déclarer la langue `<html lang="${content.lang!"fr"}">`</em>. Ces conventions, écrites une fois, sont respectées automatiquement par l’agent depuis la session 1.</p> </div> <div class="paragraph"> <p>Le fichier <code>SCRUM_MASTER.adoc</code> impose une structure de livrable : <strong>Objectif</strong>, <strong>Tâches</strong> (ordonnées avec assignation), <strong>Critères d’acceptation</strong>, <strong>Risques</strong>. Quand je demande un plan d’action, l’agent produit cette structure sans que je l’aie demandée. La gouvernance <strong>programme</strong> l’agent.</p> </div> <div class="sect3"> <h4 id="quand_les_agents_spécialisés_deviennent_indispensables">4.1. Quand les Agents Spécialisés Deviennent Indispensables</h4> <div class="paragraph"> <p>La création des agents spécialisés suit une courbe naturelle. Au début d’un projet, vous n’en avez pas besoin — <code>AGENT.adoc</code> suffit largement. Mais quand le projet grandit (disons, au-delà de 20 sessions), deux signaux doivent vous alerter :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>L’agent mélange les conventions de deux domaines distincts (ex: syntaxe PlantUML et règles CSS)</p> </li> <li> <p>Vous passez plus de temps à corriger l’agent sur des conventions que vous lui avez déjà expliquées 5 fois</p> </li> </ol> </div> <div class="paragraph"> <p>Sur <code>cheroliv.com</code>, c’est arrivé à la session…​ 1. Oui, dès le départ. Parce que ce projet est un site web avec trois langages (FTL, CSS, JS), du contenu AsciiDoc, et des diagrammes PlantUML — trois domaines qui n’ont rien à voir. L’agent CODER a besoin de connaître les tailles de police et les media queries ; l’agent PLANTUML_DESIGNER a besoin de connaître la syntaxe <code>@startuml</code>. Sans séparation, l’agent CODER me proposait des diagrammes, et vice versa. Le chaos.</p> </div> <div class="paragraph"> <p>Sur <code>jhipster-gradle-plugins</code>, j’ai créé deux agents spécialisés adaptés au développement de plugins Gradle : <code>PLUGIN_DEVELOPER.adoc</code> et <code>BACKLOG_MANAGER.adoc</code>. Le premier encode toutes les conventions Kotlin/Gradle (pas de <code>!!</code>, data classes pour les modèles, <code>@TaskAction</code> pour les tâches). Le second sait que <code>persistence</code> doit être stable avant que <code>assistant</code> ne démarre son développement — une dépendance critique dans un mono-repo.</p> </div> <div class="paragraph"> <p>L’erreur à ne pas commettre : créer trop d’agents trop tôt. <code>plantuml-plugin</code> a attendu la session 108 avant de formaliser un agent spécialisé pour le pool de clés API. Avant ça, le contexte métier tenait dans <code>AGENT.adoc</code>. La règle empirique : un agent spécialisé se justifie quand son domaine métier dépasse 100 lignes de documentation.</p> </div> </div> <div class="sect3"> <h4 id="la_convention_de_nommage_des_sessions">4.2. La Convention de Nommage des Sessions</h4> <div class="paragraph"> <p>Un détail qui paraît futile mais qui devient critique quand on atteint 100 sessions. Comment nommer les fichiers d’archive ?</p> </div> <div class="paragraph"> <p>J’ai appris à mes dépens qu’une convention est nécessaire — quatre projets, quatre formats différents au début, et je ne m’y retrouvais plus. Aujourd’hui, la convention que j’ai stabilisée est :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>{N}-{type}-{sujet-kebab-case}.adoc</code></pre> </div> </div> <div class="paragraph"> <p>Exemples concrets : * <code>1-chore-migration-gouvernance-agent.adoc</code> — session 1, type chore * <code>10-solidification-tests.adoc</code> — session 10, sans type explicite (le sujet suffit) * <code>036-debug-graphify-symlink-epic9.adoc</code> — session 36 avec numéro sur 3 chiffres pour le tri</p> </div> <div class="paragraph"> <p>Le numéro de session est le critère de tri principal. Les projets utilisant des numéros sur 3 chiffres (001, 036, 133) évitent les problèmes de tri lexicographique quand on dépasse 99. C’est ce que j’utilise désormais sur <code>magic-stick</code> : <code>001-init-projet.adoc</code>, <code>036-debug-graphify-symlink-epic9.adoc</code>.</p> </div> <div class="paragraph"> <p>Le type est facultatif et dérivé des mots-clés de la session (debug, feature, refactor, docs, chore, test). Le sujet en kebab-case est la partie la plus importante : il doit permettre de retrouver une session sans ouvrir le fichier. Si vous vous demandez « c’était quelle session où on a corrigé le timeout des tests d’intégration ? », la réponse est <code>124-fix-timeout-integration-test.adoc</code>.</p> </div> <div class="paragraph"> <p>Pour les sessions historiques reconstituées (projets nés avant la gouvernance), j’utilise des numéros négatifs. Sur <code>cheroliv.com</code>, les sessions -6 à 0 couvrent toute l’histoire pré-gouvernance du projet. Et pour les sessions « non documentées » ou perdues, je crée une entrée dans <code>SESSIONS_HISTORY.adoc</code> sans archive correspondante, avec un score <code>?</code>. C’est plus honnête que faire semblant.</p> </div> <div id="diag-naming-convention" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-fa800268b39ce04618bb2e1c8d339b9d.svg" alt="Arbre de décision pour le nommage des fichiers de session" width="777" height="916"> </div> </div> </div> <div class="sect3"> <h4 id="test_coverage_analysis_adoc_létape_5_décortiquée">4.3. <code>TEST_COVERAGE_ANALYSIS.adoc</code> — L’Étape 5 Décortiquée</h4> <div class="paragraph"> <p>L’étape 5 de la procédure de fin de session est la plus mystérieuse. Elle dit « Mettre à jour <code>TEST_COVERAGE_ANALYSIS.adoc</code> si des tests ont été ajoutés ou modifiés. » Mais à quoi ressemble ce fichier ?</p> </div> <div class="paragraph"> <p>Sur <code>plantuml-plugin</code>, il a évolué de quelques lignes à une structure complète. Voici sa forme stabilisée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>= Analyse de Couverture de Tests == Suivi des Tests |=== | Classe de test | Type | Tests | Statut | Dernière MAJ | PlantumlServiceTest | unit | 45/45 | ✅ PASS | 2026-04-23 | ApiKeyPoolTest | integration | 15/15 | ✅ PASS | 2026-04-20 |=== == Historique par Session | Session | Tests ajoutés | Tests modifiés | Couverture | 133 | 0 | 2 | 100% | 132 | 5 | 0 | 100% |===</code></pre> </div> </div> <div class="paragraph"> <p>L’intérêt n’est pas le fichier lui-même — c’est l’obligation de <strong>noter</strong> ce qui a changé. Sans cette étape, après 50 sessions, vous ne savez plus quels tests couvrent quoi. L’agent non plus. Le fichier devient le référentiel unique de vérité sur la couverture de tests du projet.</p> </div> <div class="paragraph"> <p>Pour les projets sans tests traditionnels (comme <code>magic-stick</code> qui teste des scripts bash), l’étape 5 est remplacée par <code>SCRIPT_VERIFICATION.adoc</code>. Le mécanisme est le même : un fichier qui suit l’état de validation des scripts. Adaptez l’étape 5 à votre projet, mais ne la sautez jamais. Elle est le filet de sécurité qui empêche la régression silencieuse.</p> </div> <div class="paragraph"> <p>Si votre projet n’a <strong>aucun</strong> test — ni unitaire, ni fonctionnel, ni script — créez quand même le fichier vide avec une section « À faire : définir une stratégie de test. » C’est un marque-page qui rappellera à votre futur vous que ce sujet n’est pas traité.</p> </div> <div id="diag-session-flow" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-d683e193c140cb1a1e50500a82c8af18.svg" alt="Flux d’une session type avec Eager/Lazy et agents" width="852" height="852"> </div> </div> <div class="paragraph"> <p>Le diagramme ci-dessus montre le cycle de vie complet d’une session. Le point clé est la bifurcation après le chargement EAGER : soit la mission est assez claire pour exécuter directement (80% des cas), soit l’agent charge du LAZY pour résoudre une ambiguïté (20% des cas). C’est cette discrimination qui économise les tokens.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_procédure_de_fin_de_session_la_règle_dor">5. La Procédure de Fin de Session : La Règle d’Or</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="pourquoi_elle_est_incontournable">5.1. Pourquoi elle est Incontournable</h3> <div class="paragraph"> <p>Sans cette procédure, la stratégie Eager/Lazy ne sert à rien. C’est elle qui transforme le travail de la session en information persistante. Elle s’exécute <strong>à la demande explicite de l’utilisateur</strong> (mots-clés : "fin de session", "je quitte", etc.), et elle est <strong>obligatoire</strong> — aucune exception, aucune omission.</p> </div> <div class="paragraph"> <p>Le fichier <code>SESSION_CHECKLIST.adoc</code> définit des métriques de session idéale :</p> </div> <div class="ulist"> <ul> <li> <p>Durée : 15-30 minutes</p> </li> <li> <p>Fichiers modifiés : 1-3 maximum</p> </li> <li> <p>Échanges LLM : 5-10 messages</p> </li> <li> <p>Contexte tokens : < 50k</p> </li> </ul> </div> <div class="paragraph"> <p>Et des signes qu’il faut changer de session : <em>Le LLM répète des erreurs déjà corrigées</em>, <em>Plus de 3 fichiers modifiés en parallèle</em>, <em>Conversation > 50 messages</em>. La règle d’or : <strong>Mieux vaut 5 sessions de 20 minutes qu’une session de 2 heures avec debugging chaos.</strong></p> </div> </div> <div class="sect2"> <h3 id="le_flux_des_6_étapes_silencieusement">5.2. Le Flux des 6 Étapes (Silencieusement)</h3> <div id="diag-end-session-flow" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-dfbf84c60d7172a65cc02d1e293610c1.svg" alt="Flux de la procédure de fin de session" width="480" height="750"> </div> </div> </div> <div class="sect2"> <h3 id="les_résultats_de_150_sessions">5.3. Les Résultats de 150+ Sessions</h3> <div class="paragraph"> <p>Voici ce que donne cette procédure appliquée systématiquement sur mes quatre projets :</p> </div> <div class="paragraph"> <p><strong>plantuml-plugin</strong> :</p> </div> <div class="ulist"> <ul> <li> <p><strong>133 sessions</strong> depuis le début du projet</p> </li> <li> <p><strong>240/240 tests PASS</strong> (100% couverture) — EPICs 1-7 terminées</p> </li> <li> <p><strong>57 scénarios Cucumber BDD</strong> validés</p> </li> <li> <p>Règle de sûreté sur les fichiers de config née d’une erreur réelle (Session 2 bakery-plugin)</p> </li> </ul> </div> <div class="paragraph"> <p><strong>bakery-plugin</strong> :</p> </div> <div class="ulist"> <ul> <li> <p><strong>11 sessions</strong> en deux semaines</p> </li> <li> <p>Migration Supabase → Firebase terminée (9 tests corrigés)</p> </li> <li> <p>EPIC 6 (publishProfile) fonctionnel en production</p> </li> <li> <p>Règle 0 créée : <code>publishToMavenLocal</code> obligatoire après chaque modif</p> </li> </ul> </div> <div class="paragraph"> <p><strong>magic-stick</strong> :</p> </div> <div class="ulist"> <ul> <li> <p><strong>23 sessions</strong> pour construire un système live Xubuntu avec partition A/B</p> </li> <li> <p>Première ISO générée à la session 10</p> </li> <li> <p>Tests de boot QEMU + VNC formalisés (documentation LAZY de 144 lignes)</p> </li> <li> <p>CI/CD SourceForge fonctionnel</p> </li> </ul> </div> <div class="paragraph"> <p><strong>cheroliv.com</strong> :</p> </div> <div class="ulist"> <ul> <li> <p><strong>9 sessions formelles</strong> + reconstitution de 7 sessions pré-système</p> </li> <li> <p>Article 0101 (OpenCode PATH) publié</p> </li> <li> <p>Article 0108 (celui-ci) réécrit après analyse de ses lacunes</p> </li> <li> <p>Gouvernance complète migrée de Markdown vers AsciiDoc</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="la_checklist_finale">5.4. La Checklist Finale</h3> <div class="paragraph"> <p>Après exécution silencieuse des 6 étapes, l’agent doit afficher une checklist de confirmation :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>✅ Procédure de fin de session exécutée 📋 Checklist : [✅] 1. Archive session N créée [✅] 2. PROMPT_REPRISE.adoc mis à jour pour session N+1 [✅] 3. SESSIONS_HISTORY.adoc mis à jour [✅] 4. INDEX.adoc mis à jour [✅] 5. TEST_COVERAGE_ANALYSIS.adoc mis à jour (si applicable) [✅] 6. COMPLETED_TASKS_ARCHIVE.adoc mis à jour</code></pre> </div> </div> <div class="paragraph"> <p><strong>Règle absolue</strong> : aucune étape ne peut être marquée <code>[✅]</code> si le fichier n’a pas été effectivement modifié et vérifié.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_guide_de_bootstrap_jour_1_session_0">6. Le Guide de Bootstrap : Jour 1, Session 0</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vous êtes convaincu par la méthode. Vous voulez l’appliquer à un nouveau projet. Par où commencer ?</p> </div> <div class="paragraph"> <p>J’ai vécu ce moment le 28 avril 2026. J’ouvre Opencode sur <code>jhipster-gradle-plugins</code>, mon mono-repo de deux plugins Gradle JHipster. C’est un projet qui existe déjà — le code est là, les tâches Gradle fonctionnent. Mais la gouvernance agent ? Zéro. Page blanche. Comme <code>plantuml-plugin</code> à sa session 1, il y a des mois.</p> </div> <div class="paragraph"> <p>Voici la procédure exacte que j’ai suivie, et que je suivrai pour tout nouveau projet. Notez bien l’ordre — il est important.</p> </div> <div id="diag-bootstrap" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-e11aa343b861c2c558099445242ab4be.svg" alt="Flux de bootstrap en 6 étapes pour initialiser la gouvernance agent sur un nouveau projet" width="1744" height="2785"> </div> </div> <div class="sect2"> <h3 id="étape_0_créer_opencode_json">6.1. Étape 0 : Créer <code>opencode.json</code></h3> <div class="paragraph"> <p>C’est le premier fichier. Pas <code>AGENT.adoc</code>, pas <code>INDEX.adoc</code>. <code>opencode.json</code> d’abord, pour une raison simple : si vous créez <code>AGENT.adoc</code> en premier, vous allez oublier de créer le pont qui le charge automatiquement. Je l’ai fait sur <code>bakery-plugin</code>, je sais de quoi je parle.</p> </div> </div> <div class="sect2"> <h3 id="étape_1_créer_les_dossiers">6.2. Étape 1 : Créer les Dossiers</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">mkdir -p .agents/sessions .agents/archives</code></pre> </div> </div> <div class="paragraph"> <p>Deux dossiers vides. <code>sessions/</code> recevra les archives de chaque session. <code>archives/</code> recevra les COMPLETED_TASKS_ARCHIVE mensuels. Ces dossiers doivent exister <strong>avant</strong> que l’agent n’ait besoin d’écrire dedans. Un agent qui doit créer le dossier ET le fichier en même temps, c’est un agent qui peut échouer silencieusement.</p> </div> </div> <div class="sect2"> <h3 id="étape_2_créer_agent_adoc_le_fichier_maître">6.3. Étape 2 : Créer <code>AGENT.adoc</code> — Le Fichier Maître</h3> <div class="paragraph"> <p>Structure minimale pour la première version (elle grandira) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>= {NOM_PROJET} — Directives Agent [CAUTION] ==== **ARRÊT OBLIGATOIRE** avant rm, Write, suppression : 1. LIRE le fichier en entier 2. VÉRIFIER git ls-files 3. DEMANDER confirmation 4. ATTENDRE "oui" ==== == Projet **Nom** : ... **Stack** : ... **Documentation** : AsciiDoc == Règles Absolues === 0. ENVIRONNEMENT DE DEV Commandes essentielles... === 1. COMMITS/GIT Interdiction formelle... === 1b. FICHIERS DE CONFIGURATION — RÈGLE ABSOLUE DE SÛRETÉ Ne jamais écraser... === 2. TESTS EN FIN DE SESSION Interdiction formelle... === 3. PROCÉDURE DE FIN DE SESSION Les 6 étapes obligatoires... == Gestion du Contexte — LAZY/EAGER Fichiers EAGER / Fichiers LAZY...</code></pre> </div> </div> <div class="paragraph"> <p>Ce template minimal permet à l’agent de démarrer. La version riche — avec la structure du projet, les composants clés, les EPICs, le backlog — viendra à la session 1, quand l’agent aura déjà les règles de base en main et pourra vous aider à enrichir le document.</p> </div> </div> <div class="sect2"> <h3 id="étape_3_créer_prompt_reprise_adoc_la_mission_session_1">6.4. Étape 3 : Créer <code>PROMPT_REPRISE.adoc</code> — La Mission Session 1</h3> <div class="paragraph"> <p>Un fichier qui dit explicitement : « Ceci est la session 1, mission à définir. » Maximum 70 lignes, avec une section Session 0 (résumé du bootstrap) et une section Session 1 (priorités à définir avec l’utilisateur).</p> </div> </div> <div class="sect2"> <h3 id="étape_4_créer_agentsindex_adoc_le_point_dentrée">6.5. Étape 4 : Créer <code>.agents/INDEX.adoc</code> — Le Point d’Entrée</h3> <div class="paragraph"> <p>Le fichier qui contiendra les règles absolues (version exécutive) et le tableau des sessions. Pour le bootstrap, il liste les règles 0 à 3 dans leur format concis, le portefeuille de projets (en incluant le nouveau projet avec un emoji 🆕), et la roadmap vide prête à être remplie.</p> </div> </div> <div class="sect2"> <h3 id="étape_5_créer_les_fichiers_lazy_structurants">6.6. Étape 5 : Créer les Fichiers LAZY Structurants</h3> <div class="paragraph"> <p>Dans l’ordre :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><code>.agents/SESSIONS_HISTORY.adoc</code> — un tableau avec uniquement la session 0</p> </li> <li> <p><code>.agents/SESSION_CHECKLIST.adoc</code> — le template « Quand changer de session »</p> </li> <li> <p><code>.agents/PROCEDURES.adoc</code> — la procédure complète des 6 étapes + EAGER/LAZY</p> </li> <li> <p><code>.agents/AGENT_SESSION_MANAGER.adoc</code> — le template d’archive</p> </li> <li> <p><code>.agents/TEST_COVERAGE_ANALYSIS.adoc</code> — le tableau de suivi des tests, vide au départ</p> </li> </ol> </div> <div class="paragraph"> <p>Si votre projet a un domaine métier complexe (comme <code>jhipster-gradle-plugins</code> avec son mono-repo persistence/assistant), créez les agents spécialisés dès maintenant :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><code>.agents/PLUGIN_DEVELOPER.adoc</code> — les conventions de code et le boundary de dépendances (si plugin)</p> </li> <li> <p><code>.agents/BACKLOG_MANAGER.adoc</code> — la structure de planification et les risques identifiés</p> </li> </ol> </div> <div class="paragraph"> <p>Ne créez pas d’agents que vous n’utiliserez pas. Un agent sans conventions concrètes à encoder est un fichier mort qui pollue <code>.agents/</code>.</p> </div> </div> <div class="sect2"> <h3 id="étape_6_ajouter_le_projet_au_portefeuille_de_tous_les_projets">6.7. Étape 6 : Ajouter le Projet au Portefeuille de TOUS les Projets</h3> <div class="paragraph"> <p>C’est l’étape qu’on oublie systématiquement. Chaque <code>INDEX.adoc</code> de chaque projet contient un tableau « Portefeuille de Projets » qui liste TOUS les projets avec la même méthodologie. Quand vous créez un nouveau projet, vous devez :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Ajouter une ligne dans le portefeuille du nouveau projet (logique)</p> </li> <li> <p>Ajouter une ligne dans le portefeuille de TOUS les projets existants — oui, tous</p> </li> </ol> </div> <div class="paragraph"> <p>Sur mes quatre (maintenant cinq) projets, cela veut dire ouvrir les <code>INDEX.adoc</code> de <code>magic-stick</code>, <code>bakery-gradle</code>, <code>cheroliv.com</code>, <code>plantuml-gradle</code> et y ajouter la ligne <code>jhipster-gradle-plugins | Session 1 | …​ | 2026-04-28 🆕</code>.</p> </div> <div class="paragraph"> <p>C’est fastidieux. C’est manuel. C’est aussi la seule façon de garantir que, quel que soit le projet sur lequel vous travaillez, l’agent sait quels autres projets existent et quel est leur état. À la session 012 de <code>magic-stick</code>, l’agent a détecté deux incohérences dans le portefeuille — <code>bakery-gradle</code> avait son COMPLETED_TASKS_ARCHIVE en retard, et <code>plantuml-gradle</code> avait un décalage entre sa documentation de procédure (5 étapes) et son INDEX (6 étapes). Sans ce tableau transverse, ces incohérences seraient restées invisibles.</p> </div> <div id="diag-portfolio-graph" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-c2b21ca8d7481b154894427d05899032.svg" alt="Graphe du portefeuille de projets — références croisées entre INDEX.adoc" width="1501" height="802"> </div> </div> <div class="paragraph"> <p>Je vous entends d’ici : « Mais c’est de la duplication ! » Oui. C’est de la duplication volontaire. Chaque <code>INDEX.adoc</code> est autonome. Si vous ouvrez une session sur <code>magic-stick</code>, l’agent doit savoir que <code>plantuml-gradle</code> en est à la session 133 sans avoir à ouvrir un fichier dans un autre répertoire. C’est le prix de l’indépendance entre projets — et il est de 5 lignes par portefeuille.</p> </div> </div> <div class="sect2"> <h3 id="ce_que_le_bootstrap_coûte">6.8. Ce que le Bootstrap Coûte</h3> <div class="paragraph"> <p>Tout ça prend 20 minutes. Vingt minutes une fois, pour ne plus jamais en perdre vingt au début de chaque session. Le ROI est immédiat : dès la session 2, l’agent reprend là où vous avez laissé la session 1.</p> </div> <div class="paragraph"> <p>Sur <code>jhipster-gradle-plugins</code>, ce bootstrap m’a pris exactement 18 minutes — de <code>mkdir .agents/</code> au dernier <code>INDEX.adoc</code> mis à jour dans le portefeuille de <code>magic-stick</code>. La session 1, qui suivra, démarrera avec un agent qui connaît déjà la structure du mono-repo, les commandes Gradle, et le boundary critique entre <code>persistence/</code> (lightweight) et <code>assistant/</code> (lourd). Vingt minutes bien investies.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="les_4_maintenant_5_projets_5_gouvernances_1_méthode">7. Les 4 (maintenant 5) Projets, 5 Gouvernances, 1 Méthode</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le système Eager/Lazy n’est pas un boilerplate copié-collé. Chaque projet a adapté la méthode à ses spécificités.</p> </div> <div class="sect2"> <h3 id="cheroliv_com_le_site_personnel">7.1. cheroliv.com : Le Site Personnel</h3> <div class="paragraph"> <p><strong>Spécificité</strong> : Contenu éditorial, accessibilité WCAG 2.1 AA, JBake statique. <strong>Adaptation</strong> : Six épopées priorisées (P0-P4), agents spécialisés (CODER, SCRUM_MASTER, PLANTUML_DESIGNER), critères d’acceptation transverses sur l’accessibilité. <strong>Règle emblématique</strong> : <code>./gradlew serve</code> obligatoire, interdiction formelle du script <code>jbake.sh</code> externe.</p> </div> </div> <div class="sect2"> <h3 id="bakery_gradle_le_plugin_multi_purpose">7.2. bakery-gradle : Le Plugin Multi-Purpose</h3> <div class="paragraph"> <p><strong>Spécificité</strong> : Plugin Gradle avec tâches de publication, génération de code Firebase, parsing YAML. <strong>Adaptation</strong> : Règle 0 (publishToMavenLocal), règle de sûreté sur les fichiers de config renforcée par l’incident du <code>site.yml</code>, EPIC 9 et 10 sur la configuration multi-fichiers. <strong>Règle emblématique</strong> : <code>publishToMavenLocal</code> après chaque modification du code source du plugin.</p> </div> </div> <div class="sect2"> <h3 id="plantuml_gradle_le_plugin_ia">7.3. plantuml-gradle : Le Plugin IA</h3> <div class="paragraph"> <p><strong>Spécificité</strong> : Intégration LangChain4j, génération de diagrammes PlantUML via LLM, tests avec clés API cloud. <strong>Adaptation</strong> : Documentation LAZY dense (ARCHITECTURE, API_KEY_POOL_REFERENCE, DATASET_FINETUNING), EPICs numérotés (1-11 terminés, 107+ en cours), séparation EAGER/LAZY optimisée (gain de 60% de tokens). <strong>Règle emblématique</strong> : Fichiers <code>*_ESSENTIALS.adoc</code> (50 lignes) vs <code>*_REFERENCE.adoc</code> (illimité) pour le pool de clés API.</p> </div> </div> <div class="sect2"> <h3 id="magic_stick_le_système_live">7.4. magic-stick : Le Système Live</h3> <div class="paragraph"> <p><strong>Spécificité</strong> : Build d’ISO Linux live (Xubuntu), partitionnement GPT A/B, CI/CD avec SourceForge. <strong>Adaptation</strong> : Références techniques LAZY complexes (AB_PARTITION, BOOT_TEST), SCRIPT_VERIFICATION.adoc comme étape 5 spécifique (pas de tests traditionnels, mais vérification de scripts bash). <strong>Règle emblématique</strong> : <code>isoTestAB</code> skipé en CI (runners non privilégiés), tests réservés aux environnements locaux avec Docker <code>--privileged</code>.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="règles_absolues_transverses">8. Règles Absolues Transverses</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quelques règles critiques qui apparaissent dans le fichier <code>AGENT.adoc</code> Eager et s’appliquent à toutes les sessions sur tous les projets :</p> </div> <div class="paragraph"> <p><strong>Environnement de dev</strong></p> </div> <div class="ulist"> <ul> <li> <p>✅ Utiliser la commande propre au projet (<code>./gradlew serve</code>, <code>./gradlew functionalTest</code>, etc.)</p> </li> <li> <p>❌ Interdit d’utiliser des scripts externes non versionnés</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Git</strong></p> </div> <div class="ulist"> <ul> <li> <p>✅ Lecture seule autorisée (<code>git status</code>, <code>git diff</code>, <code>git log</code>)</p> </li> <li> <p>❌ <code>git add</code>, <code>git commit</code>, <code>git push</code> interdits sans permission explicite</p> </li> <li> <p>❌ <code>git commit --amend</code> interdit sauf conditions méticuleusement respectées</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Fichiers de Configuration</strong></p> </div> <div class="ulist"> <ul> <li> <p>❌ Ne jamais écraser un fichier config avec un <code>Write</code> complet quand un <code>Edit</code> partiel suffit</p> </li> <li> <p>❌ Ne jamais remplacer des valeurs sensibles par des valeurs factices</p> </li> <li> <p>❌ Vérifier <code>git check-ignore</code> et <code>git ls-files</code> avant toute modification</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Tests</strong></p> </div> <div class="ulist"> <ul> <li> <p>❌ Ne jamais lancer de tests en procédure de fin de session sans permission explicite</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Outils Interdits</strong></p> </div> <div class="ulist"> <ul> <li> <p>❌ <code>TodoWrite</code> et <code>Task</code> — la gouvernance se fait via les fichiers AsciiDoc, pas via des outils externes</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="les_anti_patterns_ce_que_150_sessions_mont_appris">9. Les Anti-Patterns : Ce Que 150+ Sessions M’ont Appris</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avec le recul, certaines erreurs sont devenues des patterns tellement prévisibles que je peux les lister comme des anti-patterns — des pièges dans lesquels tout nouveau projet tombera probablement. Les voici, classés par ordre de fréquence.</p> </div> <div id="diag-antipatterns" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-c4b4c7d8bfdda0f1287bc4f14752a381.svg" alt="Les 7 anti-patterns de la gouvernance agent — arbre des pièges à éviter" width="1071" height="1060"> </div> </div> <div class="sect2"> <h3 id="anti_pattern_1_lagent_sans_opencode_json">9.1. Anti-Pattern 1 : L’Agent sans <code>opencode.json</code></h3> <div class="paragraph"> <p>C’est l’erreur numéro un. Vous avez écrit un magnifique <code>AGENT.adoc</code> de 200 lignes, mais il n’est jamais chargé automatiquement. L’agent démarre nu. Vous passez 20 minutes à le recontextualiser — exactement ce que la méthode est censée éviter.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : L’agent pose des questions basiques sur la structure du projet alors que tout est dans <code>AGENT.adoc</code>. <strong>Correction</strong> : Créer <code>opencode.json</code> avec le bloc <code>instructions: ["AGENT.adoc"]</code>. Vérifier que le fichier existe dans le working directory d’Opencode.</p> </div> </div> <div class="sect2"> <h3 id="anti_pattern_2_trop_dagents_trop_tôt">9.2. Anti-Pattern 2 : Trop d’Agents Trop Tôt</h3> <div class="paragraph"> <p>À la session 2 de votre projet, vous créez 5 agents spécialisés. Aucun n’a de contenu réel, ce sont tous des stubs. Résultat : <code>.agents/</code> est pollué de fichiers vides, et l’agent hésite sur lequel charger.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : Des fichiers d’agent contenant uniquement « À définir » ou une structure vide de 10 lignes. <strong>Correction</strong> : Un agent spécialisé se justifie quand son domaine métier dépasse 100 lignes ou qu’il encode au moins 5 règles concrètes. En dessous, le contenu tient dans <code>AGENT.adoc</code>.</p> </div> </div> <div class="sect2"> <h3 id="anti_pattern_3_le_prompt_reprise_fantôme">9.3. Anti-Pattern 3 : Le PROMPT_REPRISE Fantôme</h3> <div class="paragraph"> <p><code>PROMPT_REPRISE.adoc</code> est mis à jour…​ mais uniquement à la fin de la session, quand l’agent exécute la procédure. Entre-temps, la mission réelle de la session a dérivé — on a corrigé un bug imprévu au lieu d’implémenter la feature planifiée. Le <code>PROMPT_REPRISE.adoc</code> de fin de session ne reflète pas ce qui s’est <strong>vraiment</strong> passé.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : La section « Priorités » de <code>PROMPT_REPRISE.adoc</code> mentionne une feature qui n’a pas été touchée, alors que vous avez passé la session sur un bug critique. <strong>Correction</strong> : Mettre à jour <code>PROMPT_REPRISE.adoc</code> en temps réel quand la session dérive de sa mission initiale. Ne pas attendre la procédure de fin de session pour documenter le changement de cap. 30 secondes d’édition pendant la session valent mieux qu’un <code>PROMPT_REPRISE</code> mensonger.</p> </div> </div> <div class="sect2"> <h3 id="anti_pattern_4_larchive_vide">9.4. Anti-Pattern 4 : L’Archive Vide</h3> <div class="paragraph"> <p>La procédure de fin de session crée l’archive…​ mais l’agent, pressé d’afficher sa checklist, remplit le template avec des placeholders. <code>{detail}</code> devient « Détail à compléter plus tard ». Ce « plus tard » n’arrive jamais.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : Des archives de session contenant les mots « TODO », « à compléter », ou des sections vides. <strong>Correction</strong> : La règle absolue dit qu’aucune étape ne peut être marquée [✅] si le fichier n’a pas été effectivement modifié. Appliquez-la à vous-même : relisez l’archive avant d’afficher la checklist. Si une section est vide, remplissez-la maintenant.</p> </div> </div> <div class="sect2"> <h3 id="anti_pattern_5_le_portefeuille_fantôme">9.5. Anti-Pattern 5 : Le Portefeuille Fantôme</h3> <div class="paragraph"> <p>Vous créez un nouveau projet avec une gouvernance parfaite. Mais vous oubliez de l’ajouter au portefeuille des autres projets. Trois semaines plus tard, vous ouvrez une session sur <code>magic-stick</code> et l’agent vous dit que vous avez 4 projets. Vous en avez 5. L’agent ne le sait pas.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : Le comptage des projets dans les portefeuilles ne correspond pas à la réalité. <strong>Correction</strong> : Scriptez la mise à jour du portefeuille, ou au minimum maintenez une checklist post-bootstrap qui inclut « Mettre à jour le portefeuille de tous les projets existants ». C’est l’étape la plus fastidieuse de la méthode, et donc la plus souvent omise.</p> </div> </div> <div class="sect2"> <h3 id="anti_pattern_6_la_redondance_cachée">9.6. Anti-Pattern 6 : La Redondance Cachée</h3> <div class="paragraph"> <p>Vous copiez-collez le même backlog de 50 lignes dans <code>AGENT.adoc</code> et <code>INDEX.adoc</code>. À la session suivante, vous mettez à jour l’un mais pas l’autre. Vos deux fichiers EAGER se contredisent.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : Des divergences entre les EPICs listées dans <code>AGENT.adoc</code> et celles dans <code>INDEX.adoc</code>. <strong>Correction</strong> : La redondance doit être <strong>assumée et bornée</strong>. <code>AGENT.adoc</code> contient le backlog détaillé avec user stories. <code>INDEX.adoc</code> contient UNIQUEMENT le tableau récapitulatif des EPICs (nom, progression, priorité). Si les deux divergent, c’est <code>INDEX.adoc</code> qui fait foi — parce que c’est lui qui est mis à jour à chaque fin de session. Documentez cette règle dans votre <code>AGENT.adoc</code> : « En cas de divergence entre AGENT.adoc et INDEX.adoc, INDEX.adoc est la source de vérité. »</p> </div> </div> <div class="sect2"> <h3 id="anti_pattern_7_la_session_trop_longue">9.7. Anti-Pattern 7 : La Session Trop Longue</h3> <div class="paragraph"> <p>Vous ignorez les signaux du <code>SESSION_CHECKLIST.adoc</code>. 2 heures, 85 messages, 12 fichiers modifiés. L’agent tourne en boucle, vous aussi. Vous auriez dû changer de session il y a 45 minutes.</p> </div> <div class="paragraph"> <p><strong>Symptôme</strong> : Le LLM répète des erreurs déjà corrigées, le contexte tokens dépasse 80k, vous avez modifié à la fois <code>persistence/</code> et <code>assistant/</code> dans la même session. <strong>Correction</strong> : Le <code>SESSION_CHECKLIST.adoc</code> existe pour une raison. Respectez-le. La règle d’or n’est pas une suggestion. 5 sessions de 20 minutes > 1 session de 2 heures.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_asciidoc">10. Pourquoi AsciiDoc ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>J’ai choisi AsciiDoc pour plusieurs raisons pragmatiques qui ont un impact direct sur l’efficacité de la gouvernance :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Structure sémantique riche</strong> : sections, tableaux, admonitions, attributs de document. Un agent lit mieux un document structuré qu’un fond de texte.</p> </li> <li> <p><strong>Attributs de document</strong> (<code>:jbake-type:</code>, <code>:jbake-status:</code>) qui permettent de définir des métadonnées lisibles par la machine et l’humain.</p> </li> <li> <p><strong>Compatibilité avec JBake</strong> : mon site statique est généré par JBake, qui traite nativement l’AsciiDoc. Les fichiers de gouvernance et les articles de blog partagent le même format. Mon article de blog <strong>sur</strong> la gouvernance est écrit dans le même format que la gouvernance elle-même.</p> </li> <li> <p><strong>Longévité</strong> : AsciiDoc est un format de documentation technique éprouvé, avec une spécification stable.</p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="résultat_une_continuité_sans_couture">11. Résultat : Une Continuité sans Couture</h2> <div class="sectionbody"> <div class="paragraph"> <p>Depuis que j’ai mis ce système en place, passer d’une session Opencode à l’autre est devenu fluide. L’agent reprend exactement où je l’ai laissé, sans que j’aie à recontextualiser quoi que ce soit.</p> </div> <div class="paragraph"> <p>Les décisions prises à la session 3 sont accessibles à la session 133. Le backlog reste cohérent sur cinq projets simultanés. Les règles de sécurité (notamment sur git et les fichiers de config) sont respectées parce qu’elles sont omniprésentes dans le fichier Eager.</p> </div> <div class="paragraph"> <p>Les chiffres parlent :</p> </div> <div class="ulist"> <ul> <li> <p><strong>150+ sessions archivées</strong> au total</p> </li> <li> <p><strong>60% de tokens EAGER économisés</strong> après optimisation (Session 109)</p> </li> <li> <p><strong>Zéro rappel nécessaire</strong> sur le contexte métier du pool de clés API</p> </li> <li> <p><strong>100% des tests PASS</strong> sur plantuml-plugin (240/240)</p> </li> <li> <p><strong>Une seule catastrophe</strong> (Session 2 bakery-plugin) qui a donné naissance à la règle de sûreté absolue</p> </li> </ul> </div> <div class="paragraph"> <p>C’est un <strong>système artisanal</strong>, construit avec les outils du métier (AsciiDoc, git, Gradle), sans dépendance à une plateforme propriétaire. Il reflète ma conviction fondamentale : <strong>un développeur crédible construit et utilise ses propres outils</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="liens">12. Liens</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Mon site : [cheroliv.com](<a href="https://cheroliv.com" class="bare">https://cheroliv.com</a>)</p> </li> <li> <p>Le projet <code>bakery-gradle</code> : [github.com/cheroliv/bakery-gradle-plugin](<a href="https://github.com/cheroliv/bakery-gradle-plugin" class="bare">https://github.com/cheroliv/bakery-gradle-plugin</a>)</p> </li> <li> <p>Le projet <code>plantuml-gradle</code> : [github.com/cheroliv/plantuml-gradle-plugin](<a href="https://github.com/cheroliv/plantuml-gradle-plugin" class="bare">https://github.com/cheroliv/plantuml-gradle-plugin</a>)</p> </li> <li> <p>Le projet <code>magic-stick</code> : [github.com/cheroliv/magic-stick](<a href="https://github.com/cheroliv/magic-stick" class="bare">https://github.com/cheroliv/magic-stick</a>)</p> </li> <li> <p>Le projet <code>cheroliv.com</code> : [github.com/cheroliv/cheroliv.github.io](<a href="https://github.com/cheroliv/cheroliv.github.io" class="bare">https://github.com/cheroliv/cheroliv.github.io</a>)</p> </li> </ul> </div> <hr> <div class="paragraph"> <p><strong>Le code qu’on écrit pour soi est le laboratoire du code qu’on enseigne aux autres.</strong></p> </div> </div> </div> https://pages-content.github.io//blog/2026/0107_jbake_serve_rendering_bug_fix_post.html Wed, 22 Apr 2026 00:00:00 +0000 blog/2026/0107_jbake_serve_rendering_bug_fix_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#la_scène_quatre_screenshots_deux_rendus">1. La scène : quatre screenshots, deux rendus</a> <ul class="sectlevel2"> <li><a href="#rendu_local">1.1. Rendu local</a></li> <li><a href="#rendu_en_ligne">1.2. Rendu en ligne</a></li> </ul> </li> <li><a href="#le_diagnostic_serve_ne_pointait_pas_vers_le_bon_dossier">2. Le diagnostic : <code>serve</code> ne pointait pas vers le bon dossier</a></li> <li><a href="#la_cause_racine_jbake_cli_ne_fonctionne_pas_comme_ça">3. La cause racine : JBake CLI ne fonctionne pas comme ça</a></li> <li><a href="#la_solution_arguments_positionnels_pas_des_flags">4. La solution : arguments positionnels, pas des flags</a></li> <li><a href="#vérification_rapide_avec_curl">5. Vérification rapide avec curl</a></li> <li><a href="#pourquoi_ce_bug_était_vicieux">6. Pourquoi ce bug était vicieux</a></li> <li><a href="#conclusion">7. Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 10 minutes</div> <p>Vous connaissez ce moment où votre site en local ressemble à rien, mais une fois déployé en ligne tout est nickel ? C’est ce qui m’est arrivé avec mon plugin Gradle JBake. La tâche <code>serve</code> affichait des boutons carrés, du texte sombre sur fond noir, et un CSS bizarrement absent. Pourtant <code>publishSite</code> générait le même site, lui, impeccable. Le coupable n’était ni le CSS, ni le navigateur, ni le cache. C’était une ligne de code Kotlin — et une mauvaise habitude avec les arguments en ligne de commande.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="la_scène_quatre_screenshots_deux_rendus">1. La scène : quatre screenshots, deux rendus</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’était après un crash système. J’avais fait quatre captures d’écran pour comparer le rendu local (<code>./gradlew serve</code> sur <code>localhost:8820</code>) avec le rendu en ligne (<code>publishSite</code> sur GitHub Pages). Deux screenshots par page : le haut et le bas.</p> </div> <div class="sect2"> <h3 id="rendu_local">1.1. Rendu local</h3> <div class="paragraph"> <p><strong>Haut de page</strong> — Les boutons <strong>Project</strong> et <strong>Template</strong> sont <strong>petits, rectangulaires</strong>, aux couleurs standards (bleu et vert). La carte <strong>Start Writing</strong> a un <strong>fond noir uni</strong>, sans cadre.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/screen_local1.png" alt="Rendu local - haut de page"> </div> </div> <div class="paragraph"> <p><strong>Bas de page</strong> — Le sous-titre <strong>"Derniers articles et ressources"</strong> est <strong>quasi-illisible</strong>, trop foncé sur fond noir. Les dates sous les images blog ("17 October 2013", etc.) sont <strong>absentes</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/screen_local2.png" alt="Rendu local - bas de page"> </div> </div> </div> <div class="sect2"> <h3 id="rendu_en_ligne">1.2. Rendu en ligne</h3> <div class="paragraph"> <p><strong>Haut de page</strong> — Les mêmes boutons sont <strong>grands, ovaux, vert néon flashy</strong>, texte en majuscules. La carte a un <strong>cadre blanc arrondi avec ombre portée</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/screen_online1.png" alt="Rendu en ligne - haut de page"> </div> </div> <div class="paragraph"> <p><strong>Bas de page</strong> — Le sous-titre est <strong>bien lisible</strong>. Les dates sont <strong>visibles</strong>. Les cartes des articles ont des <strong>coins arrondis</strong> et les titres sont <strong>en gras</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/screen_online2.png" alt="Rendu en ligne - bas de page"> </div> </div> <div class="paragraph"> <p>Premier réflexe : le thème. J’utilise un système de thème dynamique (clair, sombre, high-contrast) basé sur <code>localStorage</code>. Peut-être que le local store déclenchait un thème high-contrast ? Non. J’avais déjà écrit <a href="https://cheroliv.com/blog/2025/0098_preloading_css_variable_post.html">un article entier sur le préchargement des thèmes</a>, je sais comment ça marche. Et puis, même en mode high-contrast, la structure CSS (boutons ovales, ombres) devait être là. Elle ne l’était pas.</p> </div> <div class="paragraph"> <p>Deuxième réflexe : le cache navigateur. Non, j’avais fait le test avec des profils propres. Le diff persistait.</p> </div> <div class="paragraph"> <p>Troisième réflexe : <code>serve</code> ne servait pas les mêmes fichiers que <code>publishSite</code>.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_diagnostic_serve_ne_pointait_pas_vers_le_bon_dossier">2. Le diagnostic : <code>serve</code> ne pointait pas vers le bon dossier</h2> <div class="sectionbody"> <div class="paragraph"> <p>Mon plugin Gradle <code>bakery</code> a deux tâches principales :</p> </div> <div class="ulist"> <ul> <li> <p><code>bake</code> : génère le site statique dans <code>build/bake/</code></p> </li> <li> <p><code>serve</code> : lance un serveur web local</p> </li> <li> <p><code>publishSite</code> : pousse <code>build/bake/</code> vers GitHub Pages</p> </li> </ul> </div> <div class="paragraph"> <p>La divergence ne pouvait venir que de <code>serve</code>. Si <code>publishSite</code> publiait le contenu correct, c’est que <code>build/bake/</code> était bon. Si <code>serve</code> affichait autre chose, c’est qu’il ne servait pas <code>build/bake/</code>.</p> </div> <div class="paragraph"> <p>Regardons le code. Dans <code>SiteManager.kt</code>, la tâche <code>serve</code> est définie comme ceci :</p> </div> <div class="listingblock"> <div class="title">SiteManager.kt — La tâche serve (version buggy)</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">tasks.register("serve", JavaExec::class.java) { task -> task.apply { mainClass.set("org.jbake.launcher.Main") classpath = jbakeRuntime environment("GEM_PATH", jbakeRuntime.asPath) jvmArgs(/* ... */) args = listOf( "-b", file(site.bake.srcPath).absolutePath, "-s", layout.buildDirectory.get() .asFile.resolve(site.bake.destDirPath) .absolutePath ) } }</code></pre> </div> </div> <div class="paragraph"> <p><code>org.jbake.launcher.Main</code> est le point d’entrée de la CLI JBake 2.7.0. L’idée : passer <code>-b</code> pour le dossier source et <code>-s</code> pour le dossier destination, puis lancer le mode serveur. Sauf que…​</p> </div> </div> </div> <div class="sect1"> <h2 id="la_cause_racine_jbake_cli_ne_fonctionne_pas_comme_ça">3. La cause racine : JBake CLI ne fonctionne pas comme ça</h2> <div class="sectionbody"> <div class="paragraph"> <p>JBake 2.7.0 attend des <strong>arguments positionnels</strong> pour source et destination, puis des flags optionnels. La signature est :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">jbake <source> <destination> [options]</code></pre> </div> </div> <div class="paragraph"> <p>Or dans mon code, j’écrivais :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">args = listOf("-b", "/path/to/site", "-s", "/path/to/build/bake")</code></pre> </div> </div> <div class="paragraph"> <p>JBake interprétait ça comme :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><code>-b</code> → parse le flag "bake" (booléen), consommé</p> </li> <li> <p><code>/path/to/site</code> → devient argument positionnel 1 (source)</p> </li> <li> <p><code>-s</code> → parse le flag "serve" (booléen), serveur lancé <strong>immédiatement</strong></p> </li> <li> <p><code>/path/to/build/bake</code> → devient un argument orphelin, ignoré ou mal interprété</p> </li> </ol> </div> <div class="paragraph"> <p>Résultat : JBake prenait <code>/path/to/site</code> comme source, <strong>ne tenait pas compte de la destination</strong> fournie (<code>build/bake</code>), et utilisait son répertoire par défaut (souvent <code>./output</code> ou une copie temporaire). Le fichier <code>css/styles.css</code> du build était donc écrasé ou ignoré, et c’est un vieux CSS par défaut (sans les variables custom, sans les arrondis, sans les ombres) qui était servi.</p> </div> <div class="paragraph"> <p>En comparaison, <code>bake</code> et <code>publishSite</code> utilisent le <strong>plugin Gradle JBake officiel</strong> (<code>jbake-gradle-plugin</code>) qui écrit proprement dans <code>build/bake/</code> via l’API Gradle. Ils ne passent pas par la CLI.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_arguments_positionnels_pas_des_flags">4. La solution : arguments positionnels, pas des flags</h2> <div class="sectionbody"> <div class="paragraph"> <p>La correction est triviale — une fois qu’on sait. Il suffit de passer source et destination comme arguments positionnels, puis <code>-s</code> en dernier :</p> </div> <div class="listingblock"> <div class="title">SiteManager.kt — La tâche serve (version corrigée)</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">args = listOf( file(site.bake.srcPath).absolutePath, layout.buildDirectory.get() .asFile.resolve(site.bake.destDirPath) .absolutePath, "-s" )</code></pre> </div> </div> <div class="paragraph"> <p>C’est tout. Trois lignes changées, bug résolu.</p> </div> <div class="paragraph"> <p>Après publication locale du plugin (<code>publishToMavenLocal</code>), un <code>./gradlew serve</code> lance JBake avec la syntaxe correcte :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">jbake /home/user/project/site /home/user/project/build/bake -s</code></pre> </div> </div> <div class="paragraph"> <p>Et cette fois-ci, le serveur Jetty intégré à JBake sert bien le contenu de <code>build/bake/</code> — identique à ce qui est publié en ligne.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/serve-vs-publish-diagram.svg" alt="serve vs publish diagram" width="1141" height="348"> </div> </div> </div> </div> <div class="sect1"> <h2 id="vérification_rapide_avec_curl">5. Vérification rapide avec curl</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour s’assurer que le serveur sert bien le bon contenu, un simple <code>curl</code> confirme que <code>index.html</code> contient <code>data-bs-theme="light"</code> et que <code>build/bake/css/styles.css</code> pèse bien 31 402 octets — identique au fichier généré par <code>bake</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew serve # Dans un autre terminal : $ curl -s http://localhost:8820/ | grep data-bs-theme <html ... data-bs-theme="light" ...> $ curl -I http://localhost:8820/css/styles.css HTTP/1.1 200 OK Content-Length: 31402 Content-Type: text/css</code></pre> </div> </div> <div class="paragraph"> <p>Le rendu local est désormais <strong>pixel-identique</strong> au rendu déployé.</p> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_ce_bug_était_vicieux">6. Pourquoi ce bug était vicieux</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vous voyez pourquoi c’était difficile à attraper ?</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Pas d’erreur explicite</strong> : JBake ne crashait pas. Il "fonctionnait", simplement avec un mauvais dossier.</p> </li> <li> <p><strong>Le build fonctionnait</strong> : <code>./gradlew bake</code> générait correctement les fichiers dans <code>build/bake/</code>.</p> </li> <li> <p><strong>Le déploiement fonctionnait</strong> : <code>publishSite</code> poussait le bon contenu en ligne.</p> </li> <li> <p><strong>Seul <code>serve</code> était cassé</strong> : la tâche de développement, celle qu’on utilise constamment pour itérer.</p> </li> <li> <p><strong>L’habitude du <code>-key value</code></strong> : en tant que développeur, on est conditionné par des années de CLI Unix (<code>-o output</code>, <code>-i input</code>). JBake CLI est une exception — source et destination sont positionnels.</p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="conclusion">7. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si vous maintenez un plugin Gradle qui wrappe JBake (ou tout outil CLI), <strong>lisez la doc des arguments</strong> même si vous pensez les connaître. Une hypothèse implicite (<code>-s</code> = "set destination") peut vous coûter des heures de debugging visuel.</p> </div> <div class="paragraph"> <p>Ici, le fix était littéralement de changer :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">args = listOf("-b", src, "-s", dest) // ❌ BUG</code></pre> </div> </div> <div class="paragraph"> <p>en :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">args = listOf(src, dest, "-s") // ✅ FIX</code></pre> </div> </div> <div class="paragraph"> <p>Trois tokens déplacés, et mon site local redevient aussi beau que le site en production.</p> </div> <div class="paragraph"> <p><strong>Leçon</strong> : quand le rendu diffère entre local et prod sans raison évidente, suspectez d’abord le <strong>pipeline</strong> — pas le CSS, pas le navigateur, et encore moins le framework. C’est souvent l’étape juste avant le rendu qui triche.</p> </div> </div> </div> https://pages-content.github.io//blog/2026/0106_opencode_path_sdkman_nvm_post.html Tue, 21 Apr 2026 00:00:00 +0000 blog/2026/0106_opencode_path_sdkman_nvm_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#la_scène_un_agent_aveugle_dans_un_monde_doutils">1. La scène : un agent aveugle dans un monde d’outils</a></li> <li><a href="#anatomie_du_bug_deux_shells_deux_mondes">2. Anatomie du bug : deux shells, deux mondes</a></li> <li><a href="#les_coupables_zshrc_vs_zshenv">3. Les coupables : .zshrc vs .zshenv</a></li> <li><a href="#diagnostic_pas_à_pas">4. Diagnostic pas à pas</a> <ul class="sectlevel2"> <li><a href="#1_vérifier_le_path_de_lagent">4.1. 1. Vérifier le PATH de l’agent</a></li> <li><a href="#2_identifier_ce_qui_est_dans_zshrc_mais_pas_dans_zshenv">4.2. 2. Identifier ce qui est dans .zshrc mais pas dans .zshenv</a></li> <li><a href="#3_vérifier_si_zshenv_existe">4.3. 3. Vérifier si .zshenv existe</a></li> </ul> </li> <li><a href="#la_solution_zshenv_les_bons_chemins">5. La solution : .zshenv + les bons chemins</a> <ul class="sectlevel2"> <li><a href="#créer_zshenv_avec_tous_les_chemins_essentiels">5.1. Créer .zshenv avec tous les chemins essentiels</a></li> <li><a href="#pourquoi_pas_source_sdkman_init_sh_dans_zshenv">5.2. Pourquoi pas <code>source sdkman-init.sh</code> dans .zshenv ?</a></li> </ul> </li> <li><a href="#le_cas_nvm_quand_le_gestionnaire_de_versions_oublie_de_laisser_une_trace">6. Le cas NVM : quand le gestionnaire de versions oublie de laisser une trace</a> <ul class="sectlevel2"> <li><a href="#le_problème_nvm">6.1. Le problème NVM</a></li> <li><a href="#la_solution_créer_le_symlink_current_pour_nvm">6.2. La solution : créer le symlink <code>current</code> pour NVM</a></li> <li><a href="#automatiser_la_mise_à_jour_du_symlink">6.3. Automatiser la mise à jour du symlink</a></li> </ul> </li> <li><a href="#tableau_récapitulatif_des_chemins">7. Tableau récapitulatif des chemins</a></li> <li><a href="#pièges_et_mitigations">8. Pièges et mitigations</a></li> <li><a href="#leçons_apprises">9. Leçons apprises</a></li> <li><a href="#vérification_finale">10. Vérification finale</a></li> <li><a href="#liens">11. Liens</a> <ul class="sectlevel2"> <li><a href="#documentation_officielle">11.1. Documentation officielle</a></li> <li><a href="#outils_mentionnés">11.2. Outils mentionnés</a></li> <li><a href="#pour_aller_plus_loin">11.3. Pour aller plus loin</a></li> </ul> </li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 13 minutes</div> <p>Vous lancez OpenCode dans votre terminal, tout fonctionne. L’agent tente un <code>gh</code> — introuvable. Un <code>java -version</code> — absent. Un <code>node</code> — nulle part. Pourtant, ces outils sont bien là dans <em>votre</em> shell. Le problème ? OpenCode lance des shells <strong>non-interactifs</strong> qui ne lisent jamais votre <code>.zshrc</code>. Voici comment diagnostiquer et corriger ça proprement.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="la_scène_un_agent_aveugle_dans_un_monde_doutils">1. La scène : un agent aveugle dans un monde d’outils</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’était un mardi soir. Je venais d’installer <a href="https://opencode.ai">OpenCode</a>, l’agent IA qui promettait de transformer ma façon de coder. Premier test : lui demander de lister mes dépôts GitHub.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ opencode > Utilise gh pour lister mes repos ❌ bash: gh: command not found</code></pre> </div> </div> <div class="paragraph"> <p>Étrange. <code>gh</code> fonctionnait parfaitement dans mon terminal. J’essaie autre chose :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">> Vérifie la version de Java ❌ bash: java: command not found</code></pre> </div> </div> <div class="paragraph"> <p>Puis :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">> Lance le build Gradle ❌ bash: gradle: command not found</code></pre> </div> </div> <div class="paragraph"> <p>Java, Gradle, Node, <code>gh</code> — tout était invisible pour l’agent. Mon terminal, lui, voyait tout. Comme si l’agent et moi vivions dans deux mondes parallèles.</p> </div> <div class="paragraph"> <p>J’ai mis des heures à comprendre. Des heures de <code>echo $PATH</code>, de <code>which java</code>, de frustration croissante. J’ai fini par comprendre que le problème n’était pas les outils — c’était le <strong>shell</strong>. OpenCode, comme tout agent qui lance des sous-processus, travaille dans des shells <strong>non-interactifs</strong>. Et Zsh, dans ces shells-là, ignore purement et simplement votre <code>.zshrc</code>.</p> </div> <div class="paragraph"> <p>Ce qui suit est le récit complet de ce diagnostic, de la résolution, et de la leçon que j’ai tirée. Si vous utilisez un agent IA — OpenCode, Aider, Cursor, ou même des scripts cron — ce problème vous concernera un jour.</p> </div> </div> </div> <div class="sect1"> <h2 id="anatomie_du_bug_deux_shells_deux_mondes">2. Anatomie du bug : deux shells, deux mondes</h2> <div class="sectionbody"> <div class="paragraph"> <p>Quand vous ouvrez un terminal, Zsh le traite comme un shell <strong>interactif</strong>. Il charge <code>.zshrc</code>, qui initialise tout : SDKMAN, NVM, pnpm, les aliases, votre joli prompt. Votre environnement est complet.</p> </div> <div class="paragraph"> <p>Mais quand OpenCode exécute une commande, il ne lance pas un terminal interactif. Il lance un shell <strong>non-interactif</strong> — un shell de tâche, sans humain derrière l’écran. Et Zsh, dans ce contexte, saute <code>.zshrc</code>. Il ne lit que <code>.zshenv</code>.</p> </div> <div class="paragraph"> <p>Pourquoi cette distinction existe-t-elle ? Parce qu’un shell non-interactif est conçu pour exécuter des scripts, pas pour servir un utilisateur humain. Charger les aliases, le prompt et les complétons dans un script qui tourne en background serait un gaspillage. Le problème, c’est que votre PATH — l’information la plus critique pour trouver les exécutables — est souvent initialisé dans <code>.zshrc</code>, pas dans <code>.zshenv</code>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/probleme-path.svg" alt="probleme path" width="558" height="434"> </div> </div> <div class="paragraph"> <p>La racine du problème : <strong>Zsh ne source <code>.zshrc</code> que pour les shells interactifs</strong>. OpenCode, comme tout agent IA qui lance des sous-processus, utilise des shells non-interactifs. Ces shells ne lisent que <code>.zshenv</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="les_coupables_zshrc_vs_zshenv">3. Les coupables : .zshrc vs .zshenv</h2> <div class="sectionbody"> <div class="paragraph"> <p>Zsh dispose de <strong>quatre fichiers d’initialisation</strong>, chacun avec un rôle précis. C’est un design élégant — mais c’est aussi le nœud du problème :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 14.2857%;"> <col style="width: 14.2857%;"> <col style="width: 42.8571%;"> <col style="width: 28.5715%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Fichier</th> <th class="tableblock halign-left valign-top">Sourcé quand</th> <th class="tableblock halign-left valign-top">Rôle</th> <th class="tableblock halign-left valign-top">Modifie le PATH ?</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.zshenv</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Toujours</strong> (interactif + non-interactif + login)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Variables d’environnement essentielles, PATH</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅ Oui — c’est SA place</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.zprofile</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Shells de login uniquement</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Commandes lentes (une fois par session)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Possible</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.zshrc</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Shells interactifs uniquement</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Alias, prompt, complétion, outils interactifs</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Pas pour les variables critiques</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.zlogin</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Shells de login (après .zshrc)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Messages de bienvenue, finalisation</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Rarement</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le tableau donne un indice, mais il faut le comprendre en profondeur. Pensez-y comme les pièces d’une maison :</p> </div> <div class="ulist"> <ul> <li> <p><code>.zshenv</code> est le <strong>hall d’entrée</strong> — tout le monde passe par là, visiteur ou résident. Si vous mettez quelque chose ici, tout shell pourra le voir.</p> </li> <li> <p><code>.zshrc</code> est le <strong>salon</strong> — seuls les résidents (shells interactifs) y entrent. Les visiteurs (shells non-interactifs) restent dans le hall.</p> </li> <li> <p><code>.zprofile</code> et <code>.zlogin</code> sont des pièces spécialisées pour les shells de login (comme quand vous vous connectez en SSH).</p> </li> </ul> </div> <div class="paragraph"> <p>Le drame, c’est que la plupart d’entre nous mettons le PATH dans le salon. Et l’agent IA, lui, n’a jamais le droit d’y entrer.</p> </div> <div class="paragraph"> <p>Le problème en un diagramme :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/zsh-init-flow.svg" alt="zsh init flow" width="543" height="404"> </div> </div> <div class="paragraph"> <p>Quand vous ouvrez un terminal, Zsh est interactif : il lit <code>.zshrc</code>, tout fonctionne. Quand OpenCode lance un shell pour exécuter une commande, Zsh est non-interactif : il saute <code>.zshrc</code>, ne lit que <code>.zshenv</code>. Et si <code>.zshenv</code> n’existe pas ou ne contient pas le PATH — c’est le désert.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Pourquoi Zsh fait-il ça ?</strong> C’est un choix de conception hérité d’Unix. Un shell non-interactif doit être <strong>rapide</strong> et <strong>reproductible</strong>. Charger les aliases, les prompts colorés et les initialisations lourdes de SDKMAN dans un script de cron ou un agent IA serait lent et fragile. La séparation est donc logique : <code>.zshenv</code> pour l’essentiel (variables, PATH), <code>.zshrc</code> pour le confort (aliases, prompt, complétons). Le problème survient quand on met l’essentiel dans le confort.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="diagnostic_pas_à_pas">4. Diagnostic pas à pas</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant de corriger, il faut comprendre exactement ce qui manque. Voici une méthode de diagnostic reproductible — gardez-la en favoris si vous travaillez avec des agents IA.</p> </div> <div class="sect2"> <h3 id="1_vérifier_le_path_de_lagent">4.1. 1. Vérifier le PATH de l’agent</h3> <div class="paragraph"> <p>On compare ce que voit votre terminal interactif avec ce que voit un shell non-interactif — c’est-à-dire ce que voit OpenCode.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Dans votre terminal interactif (tout fonctionne) echo $PATH | tr ':' '\n' | grep -v '^/usr' | sort</code></pre> </div> </div> <div class="paragraph"> <p>Résultat typique :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">/home/cheroliv/apps /home/cheroliv/.nvm/versions/node/v22.19.0/bin /home/cheroliv/.sdkman/candidates/java/current/bin /home/cheroliv/.sdkman/candidates/gradle/current/bin /home/cheroliv/.local/share/pnpm /home/cheroliv/.local/bin</code></pre> </div> </div> <div class="paragraph"> <p>Maintenant, simulons ce que voit l’agent — un shell non-interactif :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Shell non-interactif : pas de .zshrc zsh -c 'echo $PATH' | tr ':' '\n' | grep -v '^/usr' | sort</code></pre> </div> </div> <div class="paragraph"> <p>Résultat :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">/home/cheroliv/.local/bin</code></pre> </div> </div> <div class="paragraph"> <p><strong>Cinq chemins sur six ont disparu.</strong> L’agent est amputé de 83% de son environnement. C’est comme si on vous demandait de cuisiner sans la moitié de vos ustensiles — vous pourriez faire bouillir de l’eau, mais pas grand-chose d’autre.</p> </div> <div class="admonitionblock warning"> <table> <tr> <td class="icon"> <i class="fa icon-warning" title="Warning"></i> </td> <td class="content"> <div class="paragraph"> <p>La commande <code>zsh -c 'echo $PATH'</code> est votre <strong>outil de diagnostic numéro 1</strong>. Si un outil que vous utilisez au quotidien est absent du résultat, votre agent IA ne pourra pas le voir non plus. Testez-la avant et après chaque modification de <code>.zshenv</code>.</p> </div> </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="2_identifier_ce_qui_est_dans_zshrc_mais_pas_dans_zshenv">4.2. 2. Identifier ce qui est dans .zshrc mais pas dans .zshenv</h3> <div class="paragraph"> <p>Maintenant, on cherche le coupable dans <code>.zshrc</code>. On filtre les lignes qui mentionnent nos outils :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">grep -n 'apps\|SDKMAN\|NVM\|PNPM\|PATH' ~/.zshrc</code></pre> </div> </div> <div class="paragraph"> <p>On retrouve typiquement :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">119: PATH="/usr/bin/python3:$HOME/apps:$PATH" # ← pas exporté ! 171: export NVM_DIR="$HOME/.nvm" 172: [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # ← NVM init 176: nvm use --lts --silent # ← active une version 179: export PNPM_HOME="/home/cheroliv/.local/share/pnpm" 187: export SDKMAN_DIR="$HOME/.sdkman" 188: [[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"</code></pre> </div> </div> <div class="paragraph"> <p>Tout ça est <strong>invisible</strong> pour OpenCode. Et le <code>PATH</code> de la ligne 119 n’est même pas <code>export`é — il ne quitte jamais le shell courant. C’est un détail technique crucial : une variable sans `export</code> reste locale au shell qui la définit. Les sous-shells — comme ceux lancés par OpenCode — ne l’héritent jamais.</p> </div> </div> <div class="sect2"> <h3 id="3_vérifier_si_zshenv_existe">4.3. 3. Vérifier si .zshenv existe</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">cat ~/.zshenv 2>/dev/null || echo "FICHIER ABSENT"</code></pre> </div> </div> <div class="paragraph"> <p>Si la réponse est « FICHIER ABSENT », c’est là que tout se joue.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_zshenv_les_bons_chemins">5. La solution : .zshenv + les bons chemins</h2> <div class="sectionbody"> <div class="paragraph"> <p>La stratégie est simple, mais elle demande de la précision : mettre dans <code>.zshenv</code> <strong>uniquement</strong> les chemins essentiels, sans sourcer les scripts d’initialisation lourds. On ne déplace pas <code>.zshrc</code> dans <code>.zshenv</code> — on extrait l’essentiel.</p> </div> <div class="sect2"> <h3 id="créer_zshenv_avec_tous_les_chemins_essentiels">5.1. Créer .zshenv avec tous les chemins essentiels</h3> <div class="paragraph"> <p><code>.zshenv</code> est le <strong>seul fichier</strong> que Zsh garantit de sourcer dans <strong>tous</strong> les contextes. C’est là que doit aller le PATH.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">export SDKMAN_DIR="$HOME/.sdkman" export NVM_DIR="$HOME/.nvm" export PNPM_HOME="$HOME/.local/share/pnpm" export PATH="$HOME/apps:$HOME/.sdkman/candidates/java/current/bin:$HOME/.sdkman/candidates/gradle/current/bin:$HOME/.nvm/current/bin:$PNPM_HOME:$HOME/.local/bin:$HOME/.local/share/JetBrains/Toolbox/scripts:/usr/bin/python3:$PATH"</code></pre> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>On utilise <code>$HOME/.nvm/current/bin</code> et non <code>$HOME/.nvm/versions/node/v22.19.0/bin</code>. La raison : les versions Node changent. Un chemin en dur devient faux au prochain <code>nvm install</code>. Plus de détails dans la section suivante.</p> </div> </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="pourquoi_pas_source_sdkman_init_sh_dans_zshenv">5.2. Pourquoi pas <code>source sdkman-init.sh</code> dans .zshenv ?</h3> <div class="paragraph"> <p>L’approche la plus tentante serait de simplement reproduire dans <code>.zshenv</code> ce qu’on fait dans <code>.zshrc</code> — sourcer les scripts d’initialisation. On <strong>pourrait</strong> être tenté de faire :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># ❌ MAUVAISE IDÉE [[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"</code></pre> </div> </div> <div class="paragraph"> <p>Problèmes :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Lent</strong> : <code>sdkman-init.sh</code> fait des résolutions réseau et des vérifications à chaque shell. Dans un shell non-interactif, c’est un coût inutile.</p> </li> <li> <p><strong>Fragile</strong> : SDKMAN s’attend à un contexte interactif. Son initialisation peut échouer silencieusement dans un pipe ou un sous-shell.</p> </li> <li> <p><strong>Inutile</strong> : SDKMAN place ses candidats dans <code>~/.sdkman/candidates/<tool>/current/bin</code> — des symlinks stables pointant vers la version active. On peut les utiliser <strong>directement</strong>.</p> </li> </ul> </div> <div class="paragraph"> <p>La bonne approche : contourner l’initialisation de SDKMAN et pointer directement sur les symlinks <code>current</code>. C’est la clé de toute la solution : <strong>utiliser la structure de fichiers comme contrat, plutôt que le code d’initialisation</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/sdkman-approach.svg" alt="sdkman approach" width="338" height="321"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_cas_nvm_quand_le_gestionnaire_de_versions_oublie_de_laisser_une_trace">6. Le cas NVM : quand le gestionnaire de versions oublie de laisser une trace</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_problème_nvm">6.1. Le problème NVM</h3> <div class="paragraph"> <p>C’est ici que l’enquête m’a mené le plus loin. SDKMAN a un design élégant : quand on fait <code>sdk install java 25.0.2-tem</code>, il crée un symlink :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">~/.sdkman/candidates/java/current -> ~/.sdkman/candidates/java/25.0.2-tem</code></pre> </div> </div> <div class="paragraph"> <p>Ce symlink est <strong>toujours à jour</strong>. Pointez dessus dans <code>.zshenv</code> et vous êtes couvert, quel que soit le shell. Beautiful.</p> </div> <div class="paragraph"> <p>NVM, lui, ne crée <strong>rien</strong> de tel. Pas de symlink <code>current</code>. Pas de point d’ancrage stable. On doit pointer sur un chemin versionné en dur, qui ressemble à ça :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">~/.nvm/versions/node/v22.19.0/bin/node</code></pre> </div> </div> <div class="paragraph"> <p>Au prochain <code>nvm install 24</code>, ce chemin est mort. Votre <code>.zshenv</code> pointera vers une version qui n’est plus la version active. C’est une bombe à retardement.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Pourquoi NVM fait-il ça ?</strong> NVM fonctionne en modifiant dynamiquement le PATH à chaque <code>nvm use</code>. C’est conçu pour des développeurs qui changent de version souvent, dans un shell interactif. Le symlink <code>current</code> n’était pas dans les spécifications initiales — c’est un oubli de design que nous allons corriger nous-mêmes.</p> </div> </td> </tr> </table> </div> <div class="imageblock"> <div class="content"> <img src="./images/nvm-vs-sdkman.svg" alt="nvm vs sdkman" width="1869" height="217"> </div> </div> </div> <div class="sect2"> <h3 id="la_solution_créer_le_symlink_current_pour_nvm">6.2. La solution : créer le symlink <code>current</code> pour NVM</h3> <div class="paragraph"> <p>Puisque NVM ne le fait pas, on le fait nous-mêmes. Le principe est le même que SDKMAN — un symlink <code>current</code> qui pointe toujours vers la version active. On le crée une fois, puis on l’automatise pour qu’il se mette à jour tout seul.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Créer le symlink initial ln -sfn "$HOME/.nvm/versions/node/v22.19.0" "$HOME/.nvm/current"</code></pre> </div> </div> <div class="paragraph"> <p>Maintenant, dans <code>.zshenv</code>, on utilise :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$HOME/.nvm/current/bin</code></pre> </div> </div> <div class="paragraph"> <p>Plutôt que :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># ❌ Chemin en dur — cassé au prochain changement de version $HOME/.nvm/versions/node/v22.19.0/bin</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="automatiser_la_mise_à_jour_du_symlink">6.3. Automatiser la mise à jour du symlink</h3> <div class="paragraph"> <p>Un symlink ne vaut rien s’il ne se met pas à jour. Le symlink <code>current</code> doit se mettre à jour quand on fait <code>nvm use</code> ou <code>nvm install</code>. La solution : un <strong>wrapper</strong> — une fonction qui enveloppe la vraie commande <code>nvm</code> et met à jour le symlink après chaque appel.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># À la fin de .zshrc, APRÈS le chargement de NVM nvm use --lts --silent ln -sfn "$(nvm_version_path "$(nvm current)")" "$NVM_DIR/current" _nvm() { command nvm "$@" local rc=$? ln -sfn "$(nvm_version_path "$(nvm current)")" "$NVM_DIR/current" return $rc } alias nvm='_nvm'</code></pre> </div> </div> <div class="paragraph"> <p>Comment ça marche, en détail :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/nvm-wrapper-flow.svg" alt="nvm wrapper flow" width="676" height="393"> </div> </div> <div class="paragraph"> <p>Le wrapper <code>_nvm</code> appelle la vraie commande <code>nvm</code>, puis met à jour le symlink. L’alias <code>nvm='_nvm'</code> fait en sorte qu’en tapant <code>nvm</code>, on passe par le wrapper. Et à l’initialisation du shell, on fait de même après <code>nvm use --lts</code>.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="Tip"></i> </td> <td class="content"> <div class="paragraph"> <p><code>nvm_version_path</code> est une fonction interne de NVM qui résout le chemin complet d’une version. Ça évite de reconstruire le chemin manuellement.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="tableau_récapitulatif_des_chemins">7. Tableau récapitulatif des chemins</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant de passer aux pièges, un résumé visuel de la transformation. Sur la gauche, ce que vous aviez (tout dans <code>.zshrc</code>, invisible pour l’agent). Sur la droite, ce que vous avez maintenant (les chemins essentiels dans <code>.zshenv</code>, visibles partout).</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 14.2857%;"> <col style="width: 28.5714%;"> <col style="width: 28.5714%;"> <col style="width: 28.5715%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Outil</th> <th class="tableblock halign-left valign-top">Avant (.zshrc seulement)</th> <th class="tableblock halign-left valign-top">Après (.zshenv + symlink)</th> <th class="tableblock halign-left valign-top">Visible par OpenCode ?</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/apps</code> (gh, vscode)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">PATH non exporté dans .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$HOME/apps</code> dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">SDKMAN Java</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>sdkman-init.sh</code> sourcé dans .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$HOME/.sdkman/candidates/java/current/bin</code> dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">SDKMAN Gradle</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>sdkman-init.sh</code> sourcé dans .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$HOME/.sdkman/candidates/gradle/current/bin</code> dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">NVM Node</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>nvm use --lts</code> dans .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$HOME/.nvm/current/bin</code> dans .zshenv (symlink)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">pnpm</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$PNPM_HOME</code> dans .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$PNPM_HOME</code> dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">JetBrains Toolbox</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Auto-ajouté par Toolbox dans .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>$HOME/.local/share/JetBrains/Toolbox/scripts</code> dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Python 3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>/usr/bin/python3</code> dans PATH .zshrc</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Explicitement dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✅</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="pièges_et_mitigations">8. Pièges et mitigations</h2> <div class="sectionbody"> <div class="paragraph"> <p>Tout n’est pas parfait avec cette approche. Voici les problèmes que j’ai rencontrés, et comment les contourner.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 37.5%;"> <col style="width: 37.5%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Piège</th> <th class="tableblock halign-left valign-top">Description</th> <th class="tableblock halign-left valign-top">Mitigation</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">PATH dupliqué</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Si .zshenv et .zshrc ajoutent le même chemin, il apparaît deux fois</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>.zshenv</code> est sourcé <strong>avant</strong> .zshrc. Les deux sont lus dans un shell interactif. Le PATH peut doublonner. C’est cosmétique, pas fonctionnel. Pour l’éviter : ne mettre dans .zshenv que les chemins <em>absents</em> du PATH par défaut.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">NVM : version en dur dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Mettre <code>~/.nvm/versions/node/v22.19.0/bin</code> en dur devient faux au prochain <code>nvm install</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Utiliser le symlink <code>$HOME/.nvm/current/bin</code> + le wrapper <code>_nvm</code> dans .zshrc</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">SDKMAN : source sdkman-init.sh dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Lent, fragile, inutile dans un shell non-interactif</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Utiliser les symlinks <code>candidates/<tool>/current/bin</code> directement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Alias manquant après modification</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le wrapper <code>nvm='_nvm'</code> dans .zshrc ne prend effet qu’après rechargement</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Relancer le shell ou <code>source ~/.zshrc</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">OpenCode ne voit pas les changements</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">L’agent a déjà lancé ses sous-shells avec l’ancien .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Redémarrer OpenCode après modification de .zshenv</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">.zshenv trop chargé</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Mettre des fonctions lourdes ou des initialisations interactives dans .zshenv</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">.zshenv = variables d’environnement + PATH uniquement. Pas de <code>source</code>, pas de fonctions lourdes, pas de prompts.</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="leçons_apprises">9. Leçons apprises</h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong><code>.zshrc</code> est interactif, <code>.zshenv</code> est universel</strong> — Si une variable doit exister dans <em>tous</em> les shells (agents IA, cron, scripts, IDE), elle va dans <code>.zshenv</code>. Le salon est confortable, mais le hall d’entrée est le seul endroit où tout le monde passe.</p> </li> <li> <p><strong>Les gestionnaires de versions ne sont pas égaux</strong> — SDKMAN crée des symlinks <code>current</code> par design. NVM non. Il faut combler ce manque manuellement. C’est une leçon importante : avant de configurer votre PATH, vérifiez si votre gestionnaire offre un point d’ancrage stable.</p> </li> <li> <p><strong>Ne pas sourcer les init scripts dans .zshenv</strong> — <code>sdkman-init.sh</code> et <code>nvm.sh</code> sont conçus pour un shell interactif. Ils sont lents et fragiles dans un contexte non-interactif. Les symlinks <code>current</code> suffisent et sont instantanés.</p> </li> <li> <p><strong>Toujours tester en shell non-interactif</strong> — <code>zsh -c 'echo $PATH'</code> simule exactement ce que voit un agent. C’est le test de validation. Sans ce test, vous ne savez pas si votre configuration fonctionne pour les agents.</p> </li> <li> <p><strong>Le wrapper pattern est réutilisable</strong> — Le même pattern <code>_nvm</code> + <code>alias nvm='_nvm'</code> s’applique à tout outil qui modifie le PATH dynamiquement sans laisser de trace stable. C’est un outil de plus dans votre boîte à idées.</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="./images/avant-apres.svg" alt="avant apres" width="238" height="306"> </div> </div> </div> </div> <div class="sect1"> <h2 id="vérification_finale">10. Vérification finale</h2> <div class="sectionbody"> <div class="paragraph"> <p>Après avoir créé <code>.zshenv</code> et le symlink NVM, validez que tout fonctionne — dans les deux contextes :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Shell interactif (votre terminal) gh --version && java -version && node --version</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Shell non-interactif (simulation OpenCode) zsh -c 'gh --version && java -version && node --version'</code></pre> </div> </div> <div class="paragraph"> <p>Les deux doivent réussir. Si oui, votre agent IA verra les mêmes outils que vous. Si non, revenez au diagnostic pas à pas — vous avez probablement oublié un chemin ou le symlink NVM n’est pas à jour.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="Tip"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Automatisez ce test.</strong> Ajoutez cette vérification dans un script de healthcheck que vous lancez après chaque mise à jour de vos outils. Un <code>zsh -c 'which java && which node && which gh'</code> en CI, c’est une assurance contre les surprises.</p> </div> </td> </tr> </table> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Un shell non-interactif est comme un invité silencieux : il ne lit que ce qui est affiché sur la porte d’entrée. Si le PATH est dans le salon, il ne le verra jamais.</p> </div> </blockquote> <div class="attribution"> — cheroliv </div> </div> </div> </div> <div class="sect1"> <h2 id="liens">11. Liens</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="documentation_officielle">11.1. Documentation officielle</h3> <div class="ulist"> <ul> <li> <p><a href="https://zsh.sourceforge.io/Doc/Release/Files.html">Zsh documentation : Startup Files</a> — La référence officielle sur les fichiers d’initialisation de Zsh. C’est là que tout est expliqué, même si on l’oublie souvent.</p> </li> <li> <p><a href="https://opencode.ai/docs/config/">OpenCode : configuration</a> — Comment configurer OpenCode et son environnement d’exécution.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="outils_mentionnés">11.2. Outils mentionnés</h3> <div class="ulist"> <ul> <li> <p><a href="https://github.com/nvm-sh/nvm">NVM sur GitHub</a> — Node Version Manager. Gestionnaire de versions Node.js.</p> </li> <li> <p><a href="https://sdkman.io">SDKMAN — site officiel</a> — SDKMAN! Le gestionnaire de versions pour la JVM (Java, Kotlin, Gradle…​)</p> </li> <li> <p><a href="https://sdkman.io/install">SDKMAN : installation</a> — Guide d’installation de SDKMAN.</p> </li> <li> <p><a href="https://cli.github.com"><code>gh</code> — GitHub CLI</a> — L’outil en ligne de commande GitHub, indispensable pour tout développeur.</p> </li> <li> <p><a href="https://gradle.org">Gradle — site officiel</a> — Le système de build que nous installons via SDKMAN.</p> </li> <li> <p><a href="https://pnpm.io">pnpm — site officiel</a> — Le gestionnaire de paquets Node.js rapide et économe en espace.</p> </li> <li> <p><a href="https://www.jetbrains.com/toolbox-app/">JetBrains Toolbox</a> — Le gestionnaire d’IDE JetBrains, qui ajoute ses scripts au PATH.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="pour_aller_plus_loin">11.3. Pour aller plus loin</h3> <div class="ulist"> <ul> <li> <p><a href="https://blog.andy2003.org/posts/2022/zsh-dotfiles/">Zsh dotfiles : un guide complet</a> — Article approfondi sur la gestion des dotfiles Zsh.</p> </li> <li> <p><a href="https://wiki.archlinux.org/title/Zsh">Zsh sur ArchWiki</a> — L’une des meilleures documentations communautaires sur Zsh.</p> </li> <li> <p><a href="https://github.com/nvm-sh/nvm/issues">NVM issues GitHub</a> — Pour voir les discussions autour du symlink <code>current</code> et des problèmes de PATH.</p> </li> </ul> </div> </div> </div> </div> https://pages-content.github.io//blog/2026/0105_integrer_graphify_workflow_gradle_post.html Sun, 19 Apr 2026 00:00:00 +0000 blog/2026/0105_integrer_graphify_workflow_gradle_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_problème_des_diagrammes_toujours_en_retard_sur_le_code">1. Le problème : des diagrammes toujours en retard sur le code</a></li> <li><a href="#la_solution_un_pipeline_déterministe_knowledge_graph_plantuml">2. La solution : un pipeline déterministe Knowledge Graph → PlantUML</a></li> <li><a href="#étape_1_installer_graphify_et_extraire_le_knowledge_graph">3. Étape 1 : Installer Graphify et extraire le Knowledge Graph</a> <ul class="sectlevel2"> <li><a href="#installation">3.1. Installation</a></li> <li><a href="#configurer_les_exclusions">3.2. Configurer les exclusions</a></li> <li><a href="#extraire_le_knowledge_graph">3.3. Extraire le Knowledge Graph</a></li> </ul> </li> <li><a href="#étape_2_le_plugin_gradle_transforme_le_knowledge_graph_en_plantuml">4. Étape 2 : Le plugin Gradle transforme le Knowledge Graph en PlantUML</a> <ul class="sectlevel2"> <li><a href="#architecture_du_pipeline">4.1. Architecture du pipeline</a></li> <li><a href="#les_composants_internes">4.2. Les composants internes</a></li> <li><a href="#règles_de_rendu">4.3. Règles de rendu</a></li> </ul> </li> <li><a href="#étape_3_utilisation_au_quotidien">5. Étape 3 : Utilisation au quotidien</a> <ul class="sectlevel2"> <li><a href="#diagramme_complet">5.1. Diagramme complet</a></li> <li><a href="#filtrer_par_communauté">5.2. Filtrer par communauté</a></li> <li><a href="#filtrer_par_type_darête">5.3. Filtrer par type d’arête</a></li> <li><a href="#filtrer_par_type_de_noeud_et_confiance">5.4. Filtrer par type de noeud et confiance</a></li> <li><a href="#répertoire_de_sortie_personnalisé">5.5. Répertoire de sortie personnalisé</a></li> <li><a href="#référence_complète_des_propriétés">5.6. Référence complète des propriétés</a></li> </ul> </li> <li><a href="#le_pipeline_complet_dans_un_workflow_gradle">6. Le pipeline complet dans un workflow Gradle</a> <ul class="sectlevel2"> <li><a href="#workflow_type">6.1. Workflow type</a></li> <li><a href="#intégration_dans_le_cycle_de_développement">6.2. Intégration dans le cycle de développement</a></li> <li><a href="#mise_à_jour_incrémentale">6.3. Mise à jour incrémentale</a></li> </ul> </li> <li><a href="#le_dogfooding_le_plugin_se_documente_lui_même">7. Le dogfooding : le plugin se documente lui-même</a></li> <li><a href="#pourquoi_cest_déterministe_et_pourquoi_ça_compte">8. Pourquoi c’est déterministe (et pourquoi ça compte)</a></li> <li><a href="#diagrammes_du_pipeline_lui_même">9. Diagrammes du pipeline lui-même</a></li> <li><a href="#intégration_dans_la_gouvernance_de_projet">10. Intégration dans la gouvernance de projet</a></li> <li><a href="#mise_en_place_checklist_en_5_minutes">11. Mise en place : checklist en 5 minutes</a></li> <li><a href="#pièges_et_mitigations">12. Pièges et mitigations</a></li> <li><a href="#ce_quon_obtient_au_final">13. Ce qu’on obtient au final</a></li> <li><a href="#liens">14. Liens</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 12 minutes</div> <p>Votre codebase grandit. Les dépendances entre modules se multiplient. La documentation architecture devient obsolète avant même d’être écrite. Et si votre build Gradle pouvait <em>automatiquement</em> générer des diagrammes à jour à partir de la structure réelle du code ? C’est exactement ce que fait le pipeline Graphify + PlantUML Gradle Plugin : <code>graphify . --no-viz</code> extrait le Knowledge Graph, <code>./gradlew generateKnowledgeGraphDiagram</code> le transforme en diagrammes PlantUML. Zéro LLM, zéro manuel, 100% déterministe.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="le_problème_des_diagrammes_toujours_en_retard_sur_le_code">1. Le problème : des diagrammes toujours en retard sur le code</h2> <div class="sectionbody"> <div class="paragraph"> <p>Tout projet qui dépasse quelques milliers de lignes connaît ce syndrome :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>On dessine un diagramme d’architecture au début du projet</p> </li> <li> <p>Le code évolue, les dépendances changent</p> </li> <li> <p>Le diagramme devient un mensonge décoratif</p> </li> <li> <p>Personne ne le met à jour parce que c’est pénible</p> </li> <li> <p>Les nouveaux arrivants se basent dessus et font des erreurs</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="./images/probleme-diagrammes-obsoletes.svg" alt="probleme diagrammes obsoletes" width="824" height="418"> </div> </div> <div class="paragraph"> <p>La question n’est pas <em>faut-il des diagrammes ?</em> — tout le monde sait que oui. La question est : <strong>qui les maintient à jour ?</strong></p> </div> <div class="paragraph"> <p>La réponse : personne. Sauf si c’est automatique.</p> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_un_pipeline_déterministe_knowledge_graph_plantuml">2. La solution : un pipeline déterministe Knowledge Graph → PlantUML</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le principe est simple : au lieu de dessiner les diagrammes à la main, on les <strong>génère depuis la structure réelle du code</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/pipeline-complet.svg" alt="pipeline complet" width="1258" height="434"> </div> </div> <div class="paragraph"> <p>Deux commandes. C’est tout.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Étape 1 : extraire le Knowledge Graph graphify . --no-viz # Étape 2 : générer les diagrammes PlantUML ./gradlew generateKnowledgeGraphDiagram</code></pre> </div> </div> <div class="paragraph"> <p>Le résultat ? Des fichiers <code>.puml</code> et <code>.png</code> dans <code>diagrams/knowledge-graph/</code>, versionnés dans Git, toujours à jour avec le code.</p> </div> </div> </div> <div class="sect1"> <h2 id="étape_1_installer_graphify_et_extraire_le_knowledge_graph">3. Étape 1 : Installer Graphify et extraire le Knowledge Graph</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="installation">3.1. Installation</h3> <div class="paragraph"> <p>Graphify est un outil Python qui analyse votre codebase et construit un graphe de connaissances structuré :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Méthode recommandée uv tool install graphifyy && graphify install --platform opencode # Alternative avec pip pip install graphifyy && graphify install --platform opencode</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="configurer_les_exclusions">3.2. Configurer les exclusions</h3> <div class="paragraph"> <p>Créer un fichier <code>.graphifyignore</code> à la racine du projet pour exclure les fichiers qui ne font pas partie de la logique métier :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-gitignore hljs" data-lang="gitignore"># Secrets — JAMAIS dans le graphe *-context.yml *.env # Fichiers générés build/ .gradle/ # Tests fonctionnels src/functionalTest/</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="extraire_le_knowledge_graph">3.3. Extraire le Knowledge Graph</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">graphify . --no-viz</code></pre> </div> </div> <div class="paragraph"> <p>Le flag <code>--no-viz</code> saute la génération HTML (inutile dans un pipeline Gradle). Le résultat est un fichier <code>graphify-out/graph.json</code> contenant :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Noeuds</strong> : classes, fonctions, fichiers — avec leur type et communauté</p> </li> <li> <p><strong>Arêtes</strong> : relations entre noeuds (EXTRACTED depuis le code, INFERRED par l’LLM)</p> </li> <li> <p><strong>Communautés</strong> : regroupements automatiques de noeuds liés</p> </li> </ul> </div> <div class="listingblock"> <div class="title">Exemple de structure <code>graph.json</code></div> <div class="content"> <pre class="highlightjs highlight"><code class="language-json hljs" data-lang="json">{ "nodes": [ {"id": "0", "label": "LlmService", "file_type": "code", "community": 0}, {"id": "1", "label": "ApiKeyPool", "file_type": "code", "community": 0}, {"id": "2", "label": "PlantumlService", "file_type": "code", "community": 1} ], "links": [ {"source": "1", "target": "0", "relation": "uses", "confidence": "EXTRACTED", "weight": 0.9}, {"source": "0", "target": "2", "relation": "calls", "confidence": "INFERRED", "weight": 0.7} ] }</code></pre> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Le code source (<code>.kt</code>, <code>.java</code>) est analysé localement par tree-sitter, <strong>sans appel LLM</strong>. Seuls les fichiers de documentation (<code>.adoc</code>, <code>.md</code>) nécessitent un appel LLM pour l’extraction sémantique. Donc <code>--update</code> sur du code Kotlin est quasi instantané.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="étape_2_le_plugin_gradle_transforme_le_knowledge_graph_en_plantuml">4. Étape 2 : Le plugin Gradle transforme le Knowledge Graph en PlantUML</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="architecture_du_pipeline">4.1. Architecture du pipeline</h3> <div class="paragraph"> <p>Le plugin <code>com.cheroliv.plantuml</code> intègre une tâche <code>generateKnowledgeGraphDiagram</code> qui transforme <code>graph.json</code> en diagrammes PlantUML de manière <strong>totalement déterministe</strong> :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/architecture-pipeline-kg.svg" alt="architecture pipeline kg" width="1109" height="450"> </div> </div> </div> <div class="sect2"> <h3 id="les_composants_internes">4.2. Les composants internes</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Composant</th> <th class="tableblock halign-left valign-top">Rôle</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>KnowledgeGraphParser</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Parse <code>graph.json</code> — supporte 3 formats : graphify natif (<code>nodes</code>+<code>links</code>), legacy (<code>communities</code>), flat. Résout les IDs numériques en labels.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>KnowledgeGraphRenderer</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Transforme déterministement un <code>KnowledgeGraph</code> en code PlantUML. Groupes par type, communautés en packages, légende automatique.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>GenerateKnowledgeGraphDiagramTask</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tâche Gradle qui orchestre : parse → render → validate → PNG. Configurable via propriétés Gradle.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>kgmodels.kt</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Modèles de données : <code>KnowledgeGraph</code>, <code>KnowledgeGraphNode</code>, <code>KnowledgeGraphEdge</code>, <code>KnowledgeGraphCommunity</code>, <code>EdgeType</code>.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>PlantumlService</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Validation syntaxique + rendu PNG (réutilisé par toutes les tâches du plugin).</p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="règles_de_rendu">4.3. Règles de rendu</h3> <div class="paragraph"> <p>Le renderer applique des conventions visuelles déterministes :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 28.5714%;"> <col style="width: 28.5714%;"> <col style="width: 42.8572%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Type d’arête</th> <th class="tableblock halign-left valign-top">Notation PlantUML</th> <th class="tableblock halign-left valign-top">Signification</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">EXTRACTED</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>-→</code> (trait plein, noir)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Relation extraite du code source (certitude)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">INFERRED</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>..></code> (trait pointillé)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Relation inférée par l’LLM (score de confiance)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">AMBIGUOUS</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>--x</code> (trait rouge pointillé)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Relation ambiguë (à vérifier)</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Les communautés sont rendues comme des packages PlantUML avec une palette de couleurs automatique.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="étape_3_utilisation_au_quotidien">5. Étape 3 : Utilisation au quotidien</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="diagramme_complet">5.1. Diagramme complet</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Générer le diagramme du Knowledge Graph complet ./gradlew generateKnowledgeGraphDiagram</code></pre> </div> </div> <div class="paragraph"> <p>Sortie : <code>diagrams/knowledge-graph/knowledge-graph-full.puml</code> + <code>.png</code></p> </div> </div> <div class="sect2"> <h3 id="filtrer_par_communauté">5.2. Filtrer par communauté</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Une seule communauté ./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.community=community_0 # Limiter le nombre de noeuds (lisibilité) ./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.community=community_0 \ -Pplantuml.kg.maxNodes=15</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="filtrer_par_type_darête">5.3. Filtrer par type d’arête</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Uniquement les relations certaines (EXTRACTED) ./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.edgeTypes=EXTRACTED # Relations certaines + inférées ./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.edgeTypes=EXTRACTED,INFERRED</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="filtrer_par_type_de_noeud_et_confiance">5.4. Filtrer par type de noeud et confiance</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Uniquement les classes de code ./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.nodeTypes=code # Seuil de confiance minimum (pour les INFERRED) ./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.minConfidence=0.7</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="répertoire_de_sortie_personnalisé">5.5. Répertoire de sortie personnalisé</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">./gradlew generateKnowledgeGraphDiagram \ -Pplantuml.kg.outputDir=docs/architecture</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="référence_complète_des_propriétés">5.6. Référence complète des propriétés</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 20%;"> <col style="width: 60%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Propriété</th> <th class="tableblock halign-left valign-top">Défaut</th> <th class="tableblock halign-left valign-top">Description</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>plantuml.kg.community</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><em>(toutes)</em></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Filtrer les communautés par nom (correspondance sous-chaîne)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>plantuml.kg.edgeTypes</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><em>(tous)</em></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Types d’arêtes séparés par virgules : <code>EXTRACTED</code>, <code>INFERRED</code>, <code>AMBIGUOUS</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>plantuml.kg.minConfidence</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>0.0</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Seuil minimum de confiance pour les arêtes</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>plantuml.kg.maxNodes</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><em>(illimité)</em></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Nombre maximum de noeuds à afficher</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>plantuml.kg.nodeTypes</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><em>(tous)</em></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Types de noeuds séparés par virgules (ex. <code>class</code>, <code>code</code>)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>plantuml.kg.outputDir</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>diagrams/knowledge-graph</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Répertoire de sortie pour les fichiers <code>.puml</code> et <code>.png</code></p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="le_pipeline_complet_dans_un_workflow_gradle">6. Le pipeline complet dans un workflow Gradle</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="workflow_type">6.1. Workflow type</h3> <div class="imageblock"> <div class="content"> <img src="./images/workflow-complet.svg" alt="workflow complet" width="618" height="714"> </div> </div> </div> <div class="sect2"> <h3 id="intégration_dans_le_cycle_de_développement">6.2. Intégration dans le cycle de développement</h3> <div class="paragraph"> <p>Le pipeline s’intègre naturellement dans les étapes clés du développement :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/cycle-developpement.svg" alt="cycle developpement" width="733" height="454"> </div> </div> </div> <div class="sect2"> <h3 id="mise_à_jour_incrémentale">6.3. Mise à jour incrémentale</h3> <div class="paragraph"> <p>Quand le code change, on ne reconstruit pas tout le graphe depuis zéro :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Mise à jour incrémentale (fichiers modifiés uniquement) graphify . --update # Puis régénérer les diagrammes ./gradlew generateKnowledgeGraphDiagram</code></pre> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p><code>--update</code> re-extrait uniquement les fichiers modifiés (détectés par SHA256 dans <code>graphify-out/cache/</code>). Sur du code Kotlin, c’est quasi instantané car tree-sitter travaille localement sans appel LLM.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_dogfooding_le_plugin_se_documente_lui_même">7. Le dogfooding : le plugin se documente lui-même</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le plugin PlantUML existe pour transformer des prompts en diagrammes. Il peut aussi transformer le Knowledge Graph de sa <em>propre</em> codebase en diagrammes de documentation. C’est du <em>dogfooding</em> : le plugin consomme son propre service.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/dogfooding-pipeline.svg" alt="dogfooding pipeline" width="1055" height="533"> </div> </div> <div class="paragraph"> <p>Tâches Gradle associées :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 20%;"> <col style="width: 60%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Tâche</th> <th class="tableblock halign-left valign-top">LLM ?</th> <th class="tableblock halign-left valign-top">Description</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>generateKnowledgeGraphDiagram</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Transforme <code>graph.json</code> en PlantUML (déterministe)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>generateDiagramDocs</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Oui</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Génère des <code>.prompt</code> depuis le graphe, les traite via LLM (dogfooding)</p></td> </tr> </tbody> </table> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Documentation déterministe (rapide, pas de LLM) ./gradlew generateKnowledgeGraphDiagram # Documentation LLM (plus riche, consomme des tokens) ./gradlew generateDiagramDocs</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_cest_déterministe_et_pourquoi_ça_compte">8. Pourquoi c’est déterministe (et pourquoi ça compte)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le point clé du pipeline <code>generateKnowledgeGraphDiagram</code> : <strong>il n’appelle aucun LLM</strong>. La transformation <code>graph.json</code> → PlantUML est une fonction pure.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/determinisme-vs-llm.svg" alt="determinisme vs llm" width="1004" height="405"> </div> </div> <div class="paragraph"> <p>Les avantages concrets :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Avantage</th> <th class="tableblock halign-left valign-top">Impact</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Reproductibilité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Même <code>graph.json</code> → même diagramme. Exactement. Tous les fois.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Zéro coût</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pas d’appel LLM = pas de tokens = pas de facture API.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Zéro latence</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Parse + render prend ~100ms, pas 1-5 secondes.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Compatible CI</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Pas de clé API nécessaire. Pas de flaky test dû à une réponse LLM variable.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Versionnable</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le <code>.puml</code> généré est du texte. On peut le <code>diff</code>, le reviewer en PR, le versionner dans Git.</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="diagrammes_du_pipeline_lui_même">9. Diagrammes du pipeline lui-même</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour boucler la boucle, voici le diagramme du pipeline tel qu’il serait généré par le plugin :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/pipeline-sequence.svg" alt="pipeline sequence" width="1695" height="554"> </div> </div> </div> </div> <div class="sect1"> <h2 id="intégration_dans_la_gouvernance_de_projet">10. Intégration dans la gouvernance de projet</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans notre projet, ce pipeline s’intègre dans une stratégie de gestion de contexte EAGER/LAZY pour l’agent IA. Le Knowledge Graph remplace la documentation architecture manuelle par un graphe structuré, queryable, et auto-mis à jour.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/strategie-hybride.svg" alt="strategie hybride" width="2019" height="240"> </div> </div> <div class="paragraph"> <p>Le mariage des deux systèmes est complémentaire :</p> </div> <div class="ulist"> <ul> <li> <p><strong>La stratégie gère le QUAND et le COMMENT</strong> — gouvernance, workflow, archivage</p> </li> <li> <p><strong>Graphify gère le QUOI et le OÙ</strong> — structure du code, relations, requêtes ciblées</p> </li> </ul> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>La stratégie de session gère le <strong>QUAND</strong> et le <strong>COMMENT</strong> (gouvernance, workflow, seuils), Graphify gère le <strong>QUOI</strong> et le <strong>OÙ</strong> (structure du code, relations, requêtes ciblées). Le pipeline PlantUML gère le <strong>AVEC QUOI</strong> (diagrammes déterministes, versionnés, toujours à jour).</p> </div> </blockquote> </div> </div> </div> <div class="sect1"> <h2 id="mise_en_place_checklist_en_5_minutes">11. Mise en place : checklist en 5 minutes</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 60%;"> <col style="width: 20%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">#</th> <th class="tableblock halign-left valign-top">Étape</th> <th class="tableblock halign-left valign-top">Commande</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Installer Graphify</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>uv tool install graphifyy</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Configurer les exclusions</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Créer <code>.graphifyignore</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Extraire le Knowledge Graph</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>graphify . --no-viz</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Générer les diagrammes</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>./gradlew generateKnowledgeGraphDiagram</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Committer les résultats</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>git add diagrams/knowledge-graph/</code></p></td> </tr> </tbody> </table> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Script complet en 5 commandes uv tool install graphifyy cat > .graphifyignore << 'EOF' *-context.yml *.env build/ .gradle/ EOF graphify . --no-viz ./gradlew generateKnowledgeGraphDiagram git add graphify-out/GRAPH_REPORT.adoc graphify-out/graph.json diagrams/knowledge-graph/</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="pièges_et_mitigations">12. Pièges et mitigations</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 37.5%;"> <col style="width: 37.5%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Piège</th> <th class="tableblock halign-left valign-top">Description</th> <th class="tableblock halign-left valign-top">Mitigation</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Graphe trop dense</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un gros projet génère des centaines de noeuds illisibles</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Utiliser <code>-Pplantuml.kg.maxNodes=30</code> et filtrer par communauté</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Exclusions trop larges</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Trop de fichiers dans <code>.graphifyignore</code> réduit la valeur du graphe</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Commencer par exclure seulement credentials et build</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Direction des flèches</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les arêtes INFERRED peuvent avoir une direction ambiguë</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Filtrer par <code>-Pplantuml.kg.edgeTypes=EXTRACTED</code> pour les relations certaines uniquement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Graphe obsolète</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le code change mais le graphe n’est pas reconstruit</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Utiliser <code>graphify . --update</code> régulièrement ou le hook git <code>graphify hook install</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coût mis à jour</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les mises à jour incrémentales sont quasi gratuites (tree-sitter local)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Seules les docs (<code>.adoc</code>) consomment des tokens LLM</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="ce_quon_obtient_au_final">13. Ce qu’on obtient au final</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/recap-visuel.svg" alt="recap visuel" width="372" height="258"> </div> </div> <div class="paragraph"> <p>Les bénéfices concrets :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Bénéfice</th> <th class="tableblock halign-left valign-top">Détail</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Documentation toujours à jour</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les diagrammes reflètent le code actuel, pas un snapshot manuel</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Zéro effort de maintenance</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les diagrammes se régénèrent à chaque build</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Réduction de la dette technique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Plus besoin de maintenir les diagrammes à la main</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Contexte visuel pour les nouveaux</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un nouveau développeur comprend l’architecture en regardant les diagrammes</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Fine-tuning potentiel</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Les paires (sous-graphe → diagramme) sont des exemples d’entraînement IA</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Validation automatique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>PlantumlService.validateSyntax()</code> vérifie chaque diagramme généré</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Onboarding rapide</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">5 diagrammes = vue complète de l’architecture</p></td> </tr> </tbody> </table> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Celui qui a un <em>pourquoi</em> peut supporter tous les <em>comment</em>.</p> </div> </blockquote> <div class="attribution"> — Friedrich Nietzsche </div> </div> <div class="paragraph"> <p>Le <em>pourquoi</em> : des diagrammes toujours à jour. Le <em>comment</em> : deux commandes dans un pipeline Gradle.</p> </div> </div> </div> <div class="sect1"> <h2 id="liens">14. Liens</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://github.com/nicholasgasior/graphify">Graphify sur GitHub</a></p> </li> <li> <p><a href="https://github.com/cheroliv/plantuml-gradle">PlantUML Gradle Plugin</a></p> </li> <li> <p><a href="/blog/2026/0104_fg_command_super_tips_post.html">Le super tips de la commande fg</a> — article précédent sur le workflow terminal</p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0104_fg_command_super_tips_post.html Sat, 18 Apr 2026 00:00:00 +0000 blog/2026/0104_fg_command_super_tips_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#le_problème_un_terminal_occupé">1. Le problème : un terminal occupé</a></li> <li><a href="#les_trois_commandes_indispensables">2. Les trois commandes indispensables</a> <ul class="sectlevel2"> <li><a href="#ctrlz_suspendre_sigtstp">2.1. Ctrl+Z — Suspendre (SIGTSTP)</a></li> <li><a href="#fg_reprendre_en_avant_plan">2.2. fg — Reprendre en avant-plan</a></li> <li><a href="#bg_reprendre_en_arrière_plan">2.3. bg — Reprendre en arrière-plan</a></li> <li><a href="#jobs_lister_les_jobs_du_shell">2.4. jobs — Lister les jobs du shell</a></li> </ul> </li> <li><a href="#scénario_1_le_long_build">3. Scénario 1 : Le long build</a> <ul class="sectlevel2"> <li><a href="#pas_à_pas">3.1. Pas à pas</a></li> </ul> </li> <li><a href="#scénario_2_léditeur_oublié">4. Scénario 2 : L’éditeur oublié</a></li> <li><a href="#scénario_3_le_processus_opencode_suspendu">5. Scénario 3 : Le processus opencode suspendu</a></li> <li><a href="#scénario_4_gérer_plusieurs_jobs_simultanément">6. Scénario 4 : Gérer plusieurs jobs simultanément</a> <ul class="sectlevel2"> <li><a href="#récapitulatif_des_commandes_de_jobs">6.1. Récapitulatif des commandes de jobs</a></li> </ul> </li> <li><a href="#différences_entre_fg_bg_ctrlz_ctrlc_et">7. Différences entre fg, bg, Ctrl+Z, Ctrl+C et &</a></li> <li><a href="#le_cycle_de_vie_complet_dun_job">8. Le cycle de vie complet d’un job</a></li> <li><a href="#tips_avancés">9. Tips avancés</a> <ul class="sectlevel2"> <li><a href="#fg_avec_le_job_le_plus_récent_et_lalternance">9.1. fg avec le job le plus récent et l’alternance</a></li> <li><a href="#tuer_un_job_proprement">9.2. tuer un job proprement</a></li> <li><a href="#désown_détacher_du_shell">9.3. désown : détacher du shell</a></li> <li><a href="#combiner_avec_nohup_pour_les_longs_processus">9.4. Combiner avec nohup pour les longs processus</a></li> </ul> </li> <li><a href="#pièges_et_erreurs_courantes">10. Pièges et erreurs courantes</a> <ul class="sectlevel2"> <li><a href="#confondre_ctrlz_et_ctrlc">10.1. Confondre Ctrl+Z et Ctrl+C</a></li> <li><a href="#les_jobs_sont_locaux_au_shell">10.2. Les jobs sont locaux au shell</a></li> <li><a href="#les_jobs_ne_survivent_pas_à_la_fermeture_du_shell">10.3. Les jobs ne survivent pas à la fermeture du shell</a></li> <li><a href="#les_processus_interactifs_et_fg">10.4. Les processus interactifs et fg</a></li> </ul> </li> <li><a href="#diagramme_récapitulatif">11. Diagramme récapitulatif</a></li> <li><a href="#pourquoi_fg_est_sous_estimé">12. Pourquoi fg est sous-estimé</a></li> <li><a href="#mémoire_technique_les_signaux">13. Mémoire technique : les signaux</a></li> <li><a href="#conclusion">14. Conclusion</a></li> <li><a href="#références">15. Références</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 10 minutes</div> <p>Vous lancez <code>./gradlew build</code>, le terminal est bloqué pendant 3 minutes, et vous avez besoin de faire autre chose <em>en attendant</em> ? Pas besoin d’ouvrir un nouvel onglet. <code>Ctrl+Z</code> suspend le processus, <code>fg</code> le ramène exactement là où vous l’avez laissé. C’est le tips Unix le plus sous-estimé du quotidien d’un développeur.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="le_problème_un_terminal_occupé">1. Le problème : un terminal occupé</h2> <div class="sectionbody"> <div class="paragraph"> <p>Tout développeur a connu cette situation :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew build > Building...</code></pre> </div> </div> <div class="paragraph"> <p>Le terminal est bloqué. Vous ne pouvez plus taper aucune commande. Et vous avez besoin de consulter un fichier, lancer un <code>git status</code>, ou vérifier un port occupé.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/terminal-bloque.svg" alt="terminal bloque" width="455" height="408"> </div> </div> <div class="paragraph"> <p>La plupart des développeurs ouvrent un nouveau terminal. Mais il existe une solution plus élégante, plus rapide, et native : la gestion des jobs.</p> </div> </div> </div> <div class="sect1"> <h2 id="les_trois_commandes_indispensables">2. Les trois commandes indispensables</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="ctrlz_suspendre_sigtstp">2.1. Ctrl+Z — Suspendre (SIGTSTP)</h3> <div class="paragraph"> <p><code>Ctrl+Z</code> envoie le signal <code>SIGTSTP</code> au processus en avant-plan. Le processus est <strong>suspendu</strong> — pas tué — et le terminal retrouve son prompt.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew build > Building... ^Z [1]+ Stoppé ./gradlew build $</code></pre> </div> </div> <div class="paragraph"> <p>Le nombre entre crochets <code>[1]</code> est le <strong>numéro de job</strong>. Le <code>+</code> indique le job par défaut.</p> </div> </div> <div class="sect2"> <h3 id="fg_reprendre_en_avant_plan">2.2. fg — Reprendre en avant-plan</h3> <div class="paragraph"> <p><code>fg</code> ramène le job suspendu au premier plan. Le processus reprend exactement là où il s’était arrêté.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ fg ./gradlew build > Building... (reprend où il en était)</code></pre> </div> </div> <div class="paragraph"> <p>Avec un numéro de job spécifique :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ fg %2</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="bg_reprendre_en_arrière_plan">2.3. bg — Reprendre en arrière-plan</h3> <div class="paragraph"> <p><code>bg</code> reprend le processus <em>sans</em> bloquer le terminal. Idéal pour les longs builds.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ bg [1]+ ./gradlew build & $</code></pre> </div> </div> <div class="paragraph"> <p>Le <code>&</code> à la fin signifie que le processus tourne en arrière-plan.</p> </div> </div> <div class="sect2"> <h3 id="jobs_lister_les_jobs_du_shell">2.4. jobs — Lister les jobs du shell</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ jobs [1]- Stoppé vim README.md [2]+ En cours ./gradlew build</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/jobs-lifecycle.svg" alt="jobs lifecycle" width="606" height="395"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="scénario_1_le_long_build">3. Scénario 1 : Le long build</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’est le cas d’usage le plus courant. Vous lancez un build Gradle, le terminal est bloqué, et vous avez besoin de faire autre chose.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/scenario-build.svg" alt="scenario build" width="641" height="599"> </div> </div> <div class="sect2"> <h3 id="pas_à_pas">3.1. Pas à pas</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew build > Building... ^Z [1]+ Stoppé ./gradlew build $ git status On branch main nothing to commit, working tree clean $ fg ./gradlew build > Building... BUILD SUCCESSFUL in 2m 34s</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="scénario_2_léditeur_oublié">4. Scénario 2 : L’éditeur oublié</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vous êtes dans <code>vim</code>, vous avez besoin de consulter un autre fichier <em>sans</em> quitter <code>vim</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Dans vim, en mode commande : :shell $ cat /path/to/other/file.txt $ exit # Retour dans vim</code></pre> </div> </div> <div class="paragraph"> <p>Mais c’est lourd. Avec <code>Ctrl+Z</code>, c’est immédiat :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Dans vim, n'importe quel moment : Ctrl+Z [1]+ Stoppé vim README.md $ cat /path/to/other/file.txt # ... lire le fichier ... $ fg vim README.md # Retour exact là où on en était, curseur en place</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/vim-suspend.svg" alt="vim suspend" width="410" height="510"> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <code>vim</code> restaure parfaitement son état après un <code>fg</code> : position du curseur, contenu du buffer, historique d’annulation — tout est préservé. </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="scénario_3_le_processus_opencode_suspendu">5. Scénario 3 : Le processus opencode suspendu</h2> <div class="sectionbody"> <div class="paragraph"> <p>C’est le scénario qui a motivé cet article. Vous utilisez <code>opencode</code> (outil CLI pour piloter un LLM sur votre code), et le processus est suspendu.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/opencode-fg.svg" alt="opencode fg" width="431" height="618"> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ opencode # ... session en cours, LLM analyse le code ... ^Z [1]+ Stoppé opencode $ git diff HEAD~1 # vérifier les changements récents $ fg opencode # Le LLM reprend là où il s'était arrêté</code></pre> </div> </div> <div class="paragraph"> <p>L’avantage est double :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Pas de perte de contexte</strong> : la session LLM, l’historique de conversation, les fichiers ouverts — tout est préservé</p> </li> <li> <p><strong>Pas de redémarrage</strong> : pas besoin de relancer opencode, de recharger le contexte, de réexpliquer le problème au LLM</p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="scénario_4_gérer_plusieurs_jobs_simultanément">6. Scénario 4 : Gérer plusieurs jobs simultanément</h2> <div class="sectionbody"> <div class="paragraph"> <p><code>fg</code> et <code>bg</code> acceptent un numéro de job pour cibler un processus spécifique quand plusieurs sont suspendus.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ vim config.yml ^Z [1]+ Stoppé vim config.yml $ ./gradlew test ^Z [2]+ Stoppé ./gradlew test $ htop ^Z [3]+ Stoppé htop $ jobs [1] Stoppé vim config.yml [2]- Stoppé ./gradlew test [3]+ Stoppé htop $ fg %2 ./gradlew test # Le build reprend en avant-plan $ bg %3 [3] htop & # htop reprend en arrière-plan</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/multiple-jobs.svg" alt="multiple jobs" width="778" height="280"> </div> </div> <div class="sect2"> <h3 id="récapitulatif_des_commandes_de_jobs">6.1. Récapitulatif des commandes de jobs</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 40%;"> <col style="width: 40%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Commande</th> <th class="tableblock halign-left valign-top">Effet</th> <th class="tableblock halign-left valign-top">Exemple</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+Z</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Suspend le processus en avant-plan</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Envoi de <code>SIGTSTP</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>fg</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Reprend le job par défaut en avant-plan</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>fg</code> ou <code>fg %1</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>fg %n</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Reprend le job n en avant-plan</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>fg %2</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bg</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Reprend le job par défaut en arrière-plan</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bg</code> ou <code>bg %1</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bg %n</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Reprend le job n en arrière-plan</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>bg %2</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>jobs</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Liste les jobs du shell courant</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>jobs -l</code> (avec PID)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>kill %n</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Termine le job n</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>kill %2</code></p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="différences_entre_fg_bg_ctrlz_ctrlc_et">7. Différences entre fg, bg, Ctrl+Z, Ctrl+C et &</h2> <div class="sectionbody"> <div class="paragraph"> <p>Beaucoup de développeurs confondent ces mécanismes. Voici une clarification décisive.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/signals-comparison.svg" alt="signals comparison" width="1476" height="244"> </div> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 16.6666%;"> <col style="width: 33.3333%;"> <col style="width: 16.6666%;"> <col style="width: 33.3335%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Raccourci/Commande</th> <th class="tableblock halign-left valign-top">Signal</th> <th class="tableblock halign-left valign-top">Effet</th> <th class="tableblock halign-left valign-top">Revenir en arrière ?</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+Z</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGTSTP</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Suspend le processus (figé, en mémoire)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Oui : <code>fg</code> ou <code>bg</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+C</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGINT</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tue le processus (terminé)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non : processus détruit</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+\</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGQUIT</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tue le processus + core dump</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non : processus détruit</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>commande &</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">—</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Lance en arrière-plan directement</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>fg</code> pour le ramener en avant-plan</p></td> </tr> </tbody> </table> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="Tip"></i> </td> <td class="content"> <code>Ctrl+Z</code> est <strong>non-destructif</strong>. Le processus est figé tel quel, en mémoire. Vous pouvez reprendre immédiatement avec <code>fg</code>. C’est un <em>pause</em>, pas un <em>stop</em>. </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="le_cycle_de_vie_complet_dun_job">8. Le cycle de vie complet d’un job</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/job-lifecycle-complete.svg" alt="job lifecycle complete" width="466" height="689"> </div> </div> </div> </div> <div class="sect1"> <h2 id="tips_avancés">9. Tips avancés</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="fg_avec_le_job_le_plus_récent_et_lalternance">9.1. fg avec le job le plus récent et l’alternance</h3> <div class="paragraph"> <p><code>fg</code> sans argument ramène le job marqué <code>+</code> (le plus récent). Mais vous pouvez aussi utiliser <code>%-</code> pour cibler le job précédent :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ vim file1.txt ^Z [1]+ Stoppé vim file1.txt $ vim file2.txt ^Z [2]+ Stoppé vim file2.txt $ fg # ramène job [2] (le plus récent) $ fg %- # ramène job [1] (le précédent)</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="tuer_un_job_proprement">9.2. tuer un job proprement</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ jobs [1]- Stoppé vim config.yml [2]+ Stoppé ./gradlew test $ kill %2 # envoie SIGTERM au job 2 $ kill -9 %1 # envoie SIGKILL au job 1 (force)</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="désown_détacher_du_shell">9.3. désown : détacher du shell</h3> <div class="paragraph"> <p><code>disown</code> retire un job de la table des jobs du shell. Le processus continue de tourner mais ne peut plus être ramené avec <code>fg</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ ./gradlew build & [1] 12345 $ disown %1 # Le processus continue mais n'est plus lié au shell # Ça survives à la fermeture du terminal</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="combiner_avec_nohup_pour_les_longs_processus">9.4. Combiner avec nohup pour les longs processus</h3> <div class="paragraph"> <p>Pour qu’un processus survive à la fermeture du terminal :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ nohup ./gradlew build & [1] 12345 $ disown %1 # Le build continue même si vous fermez le terminal</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/advanced-tips.svg" alt="advanced tips" width="1371" height="205"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="pièges_et_erreurs_courantes">10. Pièges et erreurs courantes</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="confondre_ctrlz_et_ctrlc">10.1. Confondre Ctrl+Z et Ctrl+C</h3> <div class="paragraph"> <p>C’est l’erreur la plus fréquente. <code>Ctrl+C</code> tue le processus. <code>Ctrl+Z</code> le suspend. Si vous appuyez sur <code>Ctrl+C</code> par réflexe, tout l’état est perdu — fichiers ouverts, sessions LLM, builds en cours.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/ctrlz-vs-ctrlc.svg" alt="ctrlz vs ctrlc" width="1142" height="129"> </div> </div> </div> <div class="sect2"> <h3 id="les_jobs_sont_locaux_au_shell">10.2. Les jobs sont locaux au shell</h3> <div class="paragraph"> <p><code>jobs</code>, <code>fg</code> et <code>bg</code> ne fonctionnent que dans le shell qui a lancé les processus. Si vous ouvrez un nouveau terminal, vous ne verrez pas les jobs de l’autre.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Terminal 1 $ vim file.txt ^Z [1]+ Stoppé vim file.txt # Terminal 2 (nouveau) $ jobs # (rien — les jobs sont locaux au shell)</code></pre> </div> </div> <div class="paragraph"> <p>Pour voir les processus system-wide, utilisez <code>ps</code> ou <code>htop</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">ps aux | grep vim</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="les_jobs_ne_survivent_pas_à_la_fermeture_du_shell">10.3. Les jobs ne survivent pas à la fermeture du shell</h3> <div class="paragraph"> <p>Si vous fermez le terminal, tous les jobs suspendus ou en arrière-plan sont détruits. Pour qu’un processus survive, utilisez <code>nohup</code> + <code>disown</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">$ nohup ./gradlew build & [1] 12345 $ disown %1 # Fermer le terminal → le build continue</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="les_processus_interactifs_et_fg">10.4. Les processus interactifs et fg</h3> <div class="paragraph"> <p>Certains programmes interactifs ne se portent pas bien après un <code>Ctrl+Z</code> + <code>fg</code>. C’est rare mais ça arrive :</p> </div> <div class="ulist"> <ul> <li> <p>Certains programmes qui utilisent des signaux (vim, htop, less gèrent bien <code>Ctrl+Z</code>)</p> </li> <li> <p>Les programmes réseau longs (ssh, opencode) récupèrent généralement correctement</p> </li> <li> <p>Les programmes qui modifient le terminal (ncurses) peuvent parfois laisser le terminal dans un état inattendu</p> </li> </ul> </div> <div class="paragraph"> <p>En cas de terminal corrompu après un <code>fg</code>, tapez :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">reset</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="diagramme_récapitulatif">11. Diagramme récapitulatif</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/fg-recap.svg" alt="fg recap" width="1271" height="233"> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_fg_est_sous_estimé">12. Pourquoi fg est sous-estimé</h2> <div class="sectionbody"> <div class="paragraph"> <p>La plupart des développeurs modernes découvrent <code>fg</code> tard, voire jamais. Quelques raisons :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Les IDE cachent le terminal</strong> : VS Code propose un terminal intégré, mais les onglets multiples rendent <code>fg</code> moins nécessaire en apparence</p> </li> <li> <p><strong>Les outils graphiques remplacent les CLI</strong> : les gestionnaires de fichiers, les moniteurs système, les clients Git graphiques</p> </li> <li> <p><strong>tmux et screen</strong> : ces multiplexeurs résolvent le même problème différemment, mais <code>fg</code> est plus simple et toujours disponible</p> </li> </ol> </div> <div class="paragraph"> <p>Pourtant, <code>fg</code> est :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Universel</strong> : présent dans tous les shells POSIX (bash, zsh, fish…​)</p> </li> <li> <p><strong>Sans dépendance</strong> : pas besoin d’installer tmux ou screen</p> </li> <li> <p><strong>Instantané</strong> : deux frappes (<code>Ctrl+Z</code> puis <code>fg</code>) pour suspendre et reprendre</p> </li> <li> <p><strong>Préservateur de contexte</strong> : l’état du processus est intact</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="./images/why-fg-underrated.svg" alt="why fg underrated" width="771" height="227"> </div> </div> </div> </div> <div class="sect1"> <h2 id="mémoire_technique_les_signaux">13. Mémoire technique : les signaux</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour les curieux, voici les signaux impliqués :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 14.2857%;"> <col style="width: 28.5714%;"> <col style="width: 28.5714%;"> <col style="width: 28.5715%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Signal</th> <th class="tableblock halign-left valign-top">Nom</th> <th class="tableblock halign-left valign-top">Envoyé par</th> <th class="tableblock halign-left valign-top">Effet</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGINT</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+C</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Interruption — termine le processus</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGQUIT</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+\</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Quitte avec core dump</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">18</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGTSTP</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>Ctrl+Z</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Stop interactif — suspend le processus</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">19</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGCONT</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>fg</code> / <code>bg</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Continue — reprend un processus suspendu</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">15</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGTERM</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>kill %n</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Terminaison propre</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">9</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>SIGKILL</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>kill -9 %n</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Terminaison forcée (impossible à intercepter)</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Le flux complet :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/signal-flow.svg" alt="signal flow" width="434" height="525"> </div> </div> </div> </div> <div class="sect1"> <h2 id="conclusion">14. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p><code>fg</code> n’est pas un tips obscur — c’est un mécanisme fondamental du shell Unix, disponible depuis les années 70. Le fait que la plupart des développeurs l’ignorent est un symptôme de notre époque : les IDE et les multiplexeurs nous ont éloignés des bases.</p> </div> <div class="paragraph"> <p>Mais quand vous êtes sur un serveur SSH, dans un terminal minimal, ou simplement en train d’utiliser <code>opencode</code> et que le LLM est en plein travail — <code>Ctrl+Z</code>, <code>fg</code>, <code>bg</code>, <code>jobs</code> sont vos meilleurs amis.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Ctrl+Z suspend, fg reprend. C’est la pause-play du terminal.</p> </div> </blockquote> <div class="attribution"> — cheroliv </div> </div> </div> </div> <div class="sect1"> <h2 id="références">15. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><code>man bash</code> — section JOB CONTROL</p> </li> <li> <p><code>man signal</code> — liste des signaux POSIX</p> </li> <li> <p><a href="https://www.gnu.org/software/bash/manual/bash.html#Job-Control">Bash Reference Manual — Job Control</a></p> </li> <li> <p><a href="https://man7.org/linux/man-pages/man7/signal.7.html">man 7 signal — signaux Linux</a></p> </li> <li> <p><a href="https://tldp.org/LDP/abs/html/x312743.htm">Advanced Bash-Scripting Guide — Job Control</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0103_vscode_local_install_custom_fonts_post.html Fri, 17 Apr 2026 00:00:00 +0000 blog/2026/0103_vscode_local_install_custom_fonts_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#vue_densemble_du_parcours">1. Vue d’ensemble du parcours</a></li> <li><a href="#le_pourquoi_vs_code_dans_le_home">2. Le Pourquoi : VS Code dans le Home</a> <ul class="sectlevel2"> <li><a href="#le_problème_avec_linstallation_système">2.1. Le problème avec l’installation système</a></li> <li><a href="#la_solution_une_installation_locale">2.2. La solution : une installation locale</a></li> <li><a href="#avantages_concrets">2.3. Avantages concrets</a></li> </ul> </li> <li><a href="#customiser_la_police_du_menu_principal">3. Customiser la police du menu principal</a> <ul class="sectlevel2"> <li><a href="#le_constat">3.1. Le constat</a></li> <li><a href="#la_technique_patch_css_direct">3.2. La technique : patch CSS direct</a></li> <li><a href="#supprimer_lavertissement_dintégrité">3.3. Supprimer l’avertissement d’intégrité</a></li> </ul> </li> <li><a href="#customiser_la_police_du_volet_explorer_le_combat">4. Customiser la police du volet Explorer — le combat</a> <ul class="sectlevel2"> <li><a href="#tentative_1_un_paramètre_qui_nexiste_pas">4.1. Tentative 1 : un paramètre qui n’existe pas</a></li> <li><a href="#tentative_2_lextension_custom_css_and_js_loader">4.2. Tentative 2 : l’extension Custom CSS and JS Loader</a></li> <li><a href="#le_piège_il_faut_activer_lextension_à_chaque_fois">4.3. Le piège : il faut activer l’extension à chaque fois</a></li> <li><a href="#tentative_3_les_lignes_se_superposent">4.4. Tentative 3 : les lignes se superposent</a></li> <li><a href="#la_solution_zoom_sur_le_conteneur_parent">4.5. La solution : <code>zoom</code> sur le conteneur parent</a></li> <li><a href="#récapitulatif_des_selectors_et_de_ce_qui_fonctionne">4.6. Récapitulatif des selectors et de ce qui fonctionne</a></li> </ul> </li> <li><a href="#le_script_de_mise_à_jour_automatique">5. Le script de mise à jour automatique</a> <ul class="sectlevel2"> <li><a href="#le_problème">5.1. Le problème</a></li> <li><a href="#le_script_vscode_update_sh">5.2. Le script <code>vscode-update.sh</code></a></li> </ul> </li> <li><a href="#fichiers_impliqués_vue_densemble">6. Fichiers impliqués — vue d’ensemble</a></li> <li><a href="#leçons_apprises">7. Leçons apprises</a> <ul class="sectlevel2"> <li><a href="#installer_dans_le_home_libère_tout">7.1. Installer dans le home libère tout</a></li> <li><a href="#zoom_font_size_pour_les_composants_list">7.2. <code>zoom</code> > <code>font-size</code> pour les composants list</a></li> <li><a href="#lextension_custom_css_nécessite_une_activation_explicite">7.3. L’extension Custom CSS nécessite une activation explicite</a></li> <li><a href="#un_script_de_mise_à_jour_est_indispensable">7.4. Un script de mise à jour est indispensable</a></li> </ul> </li> <li><a href="#références_rapides">8. Références rapides</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 8 minutes</div> <p>Pourquoi installer VS Code dans <code>/opt</code> ou via <code>apt</code> quand on peut le poser dans son home et transformer son IDE en terrain de jeu sans jamais taper <code>sudo</code> ? Voici le récit d’une installation locale suivie d’un combat acharné pour agrandir les polices du menu et de l’explorateur de fichiers.</p> </div> <!-- toc disabled --> </div> </div> <div class="sect1"> <h2 id="vue_densemble_du_parcours">1. Vue d’ensemble du parcours</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/vscode-local-overview.svg" alt="vscode local overview" width="1057" height="380"> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_pourquoi_vs_code_dans_le_home">2. Le Pourquoi : VS Code dans le Home</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_problème_avec_linstallation_système">2.1. Le problème avec l’installation système</h3> <div class="paragraph"> <p>VS Code installé via <code>apt</code>, <code>dnf</code> ou dans <code>/opt</code> verrouille les fichiers de l’application derrière les droits root. Toute modification du CSS natif, de <code>product.json</code> ou du dossier d’installation nécessite <code>sudo</code>.</p> </div> <div class="paragraph"> <p>Or, quand on utilise <strong>opencode</strong> (tool CLI pour piloter un LLM sur son code), l’agent a besoin de pouvoir :</p> </div> <div class="ulist"> <ul> <li> <p>Écrire dans les fichiers de configuration (<code>~/.config/Code/User/settings.json</code>) — ça, c’est déjà dans le home</p> </li> <li> <p>Modifier les assets de l’IDE (CSS du workbench, <code>product.json</code>) pour les customisations avancées — ça, c’est bloqué sans sudo</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="la_solution_une_installation_locale">2.2. La solution : une installation locale</h3> <div class="paragraph"> <p>On télécharge l’archive tarball officielle et on la décompresse directement dans <code>~/apps/</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">mkdir -p ~/apps cd ~/apps wget "https://code.visualstudio.com/sha/download?build=stable&os=linux-x64" -O vscode.tar.gz tar -xzf vscode.tar.gz rm vscode.tar.gz</code></pre> </div> </div> <div class="paragraph"> <p>Le binaire se trouve alors en <code>~/apps/VSCode-linux-x64/bin/code</code>. Aucun <code>sudo</code> n’est nécessaire pour lire, modifier ou remplacer n’importe quel fichier sous <code>~/apps/VSCode-linux-x64/</code>.</p> </div> </div> <div class="sect2"> <h3 id="avantages_concrets">2.3. Avantages concrets</h3> <div class="imageblock"> <div class="content"> <img src="./images/vscode-local-vs-system.svg" alt="vscode local vs system" width="1320" height="229"> </div> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 33.3333%;"> <col style="width: 66.6667%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Avantage</th> <th class="tableblock halign-left valign-top">Détail</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Pas de sudo</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tous les fichiers de l’IDE appartiennent à l’utilisateur</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Modification directe du CSS</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">On peut patcher <code>workbench.desktop.main.css</code> sans élévation de privilèges</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Script de mise à jour maison</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un simple script shell télécharge, remplace et repatch automatiquement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Isolation</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">L’installation système n’est pas polluée ; rollback = supprimer le dossier</p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="customiser_la_police_du_menu_principal">3. Customiser la police du menu principal</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_constat">3.1. Le constat</h3> <div class="paragraph"> <p>La police par défaut du menu principal (File, Edit, View…​) et des dropdowns est trop petite. VS Code n’offre aucun paramètre pour la modifier.</p> </div> </div> <div class="sect2"> <h3 id="la_technique_patch_css_direct">3.2. La technique : patch CSS direct</h3> <div class="paragraph"> <p>On ajoute du CSS à la fin du fichier <code>workbench.desktop.main.css</code> :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/menubar-patch-sequence.svg" alt="menubar patch sequence" width="675" height="599"> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">CSS_FILE="$HOME/apps/VSCode-linux-x64/resources/app/out/vs/workbench/workbench.desktop.main.css" cat >> "$CSS_FILE" << 'EOF' .menubar-menu-title{font-size:23px!important} .menubar>.menubar-menu-button{font-size:23px!important} .monaco-menu-option{font-size:22px!important;line-height:34px!important} .monaco-menu .action-label:not(.codicon){font-size:22px!important} .menubar-menu-items-holder .monaco-menu .action-item .action-label{font-size:22px!important} EOF</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="supprimer_lavertissement_dintégrité">3.3. Supprimer l’avertissement d’intégrité</h3> <div class="paragraph"> <p>VS Code détecte les modifications de ses fichiers et affiche un bandeau "Your installation is corrupt". Pour l’éviter, on supprime les checksums de <code>product.json</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-python hljs" data-lang="python">import json product_json = "$HOME/apps/VSCode-linux-x64/resources/app/product.json" with open(product_json, 'r') as f: data = json.load(f) data.pop('checksums', None) with open(product_json, 'w') as f: json.dump(data, f, indent=2)</code></pre> </div> </div> <div class="paragraph"> <p>Après redémarrage, plus de warning et les menus sont enfin lisibles.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="customiser_la_police_du_volet_explorer_le_combat">4. Customiser la police du volet Explorer — le combat</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="tentative_1_un_paramètre_qui_nexiste_pas">4.1. Tentative 1 : un paramètre qui n’existe pas</h3> <div class="paragraph"> <p>On tente d’abord le paramètre natif <code>workbench.tree.fontSize</code> dans <code>settings.json</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-json hljs" data-lang="json">{ "workbench.tree.fontSize": 20 }</code></pre> </div> </div> <div class="paragraph"> <p>Résultat : <strong>aucun effet</strong>. Ce paramètre n’existe pas dans VS Code. La preuve que les paramètres non reconnus sont silencieusement ignorés.</p> </div> </div> <div class="sect2"> <h3 id="tentative_2_lextension_custom_css_and_js_loader">4.2. Tentative 2 : l’extension Custom CSS and JS Loader</h3> <div class="paragraph"> <p>On installe l’extension <code>be5invis.vscode-custom-css</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">~/apps/VSCode-linux-x64/bin/code --install-extension be5invis.vscode-custom-css</code></pre> </div> </div> <div class="paragraph"> <p>On crée un fichier CSS dans <code>~/.vscode-custom-css/custom.css</code> avec des sélecteurs ciblant les éléments de l’explorateur :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">.monaco-tree-rows .monaco-tree-row, .sidebar .monaco-list-row, .explorer-viewlet .monaco-list-row, .monaco-list-row .monaco-icon-label { font-size: 22px !important; line-height: 36px !important; }</code></pre> </div> </div> <div class="paragraph"> <p>Et on référence ce fichier dans les settings :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-json hljs" data-lang="json">{ "vscode_custom_css.imports": [ "file:///home/user/.vscode-custom-css/custom.css" ] }</code></pre> </div> </div> <div class="paragraph"> <p>Résultat : <strong>les changements ne s’appliquent pas</strong>.</p> </div> </div> <div class="sect2"> <h3 id="le_piège_il_faut_activer_lextension_à_chaque_fois">4.3. Le piège : il faut activer l’extension à chaque fois</h3> <div class="paragraph"> <p>La documentation de l’extension est discrète sur ce point crucial : après chaque modification du CSS custom, il faut <strong>impérativement</strong> exécuter la commande depuis la palette :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><code>Ctrl+Shift+P</code> → taper <strong>"Enable Custom CSS and JS"</strong></p> </li> <li> <p>VS Code demande un redémarrage → accepter</p> </li> </ol> </div> <div class="paragraph"> <p>Sans cette étape, le CSS n’est jamais injecté dans l’IDE.</p> </div> </div> <div class="sect2"> <h3 id="tentative_3_les_lignes_se_superposent">4.4. Tentative 3 : les lignes se superposent</h3> <div class="paragraph"> <p>Même avec <code>font-size: 22px</code> et <code>line-height: 36px</code>, les lettres à jambage (g, p, f, b) débordent sur les lignes voisines. On tente d’ajouter <code>height</code> et <code>min-height</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">.monaco-list-row { height: 36px !important; min-height: 36px !important; }</code></pre> </div> </div> <div class="paragraph"> <p>Résultat : <strong>aucun changement</strong>. VS Code calcule les hauteurs de lignes en JavaScript et override les valeurs CSS.</p> </div> </div> <div class="sect2"> <h3 id="la_solution_zoom_sur_le_conteneur_parent">4.5. La solution : <code>zoom</code> sur le conteneur parent</h3> <div class="imageblock"> <div class="content"> <img src="./images/explorer-css-approaches.svg" alt="explorer css approaches" width="465" height="822"> </div> </div> <div class="paragraph"> <p>Plutôt que de lutter contre le layout JavaScript, on utilise la propriété <code>zoom</code> sur le conteneur des lignes :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">.explorer-viewlet .monaco-list-rows, .sidebar .monaco-list-rows { zoom: 1.25; }</code></pre> </div> </div> <div class="paragraph"> <p><code>zoom</code> agrandit uniformément le rendu du conteneur — texte ET espacement — sans casser le layout calculé par le moteur JavaScript de VS Code. Le facteur 1.25 correspond à peu près à un passage de 13px à 16px.</p> </div> <div class="paragraph"> <p>Résultat : <strong>les noms de fichiers sont enfin lisibles, les lignes correctement espacées</strong>.</p> </div> </div> <div class="sect2"> <h3 id="récapitulatif_des_selectors_et_de_ce_qui_fonctionne">4.6. Récapitulatif des selectors et de ce qui fonctionne</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 50%;"> <col style="width: 25%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Approche</th> <th class="tableblock halign-left valign-top">CSS</th> <th class="tableblock halign-left valign-top">Résultat</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>font-size</code> sur <code>.monaco-list-row</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>font-size: 22px !important</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Texte plus grand mais lignes superposées</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>line-height</code> + <code>height</code> sur <code>.monaco-list-row</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>line-height: 36px; height: 36px</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aucun effet (override JS)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>zoom</code> sur <code>.monaco-list-rows</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>zoom: 1.25</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Réussi — texte + espacement proportionnels</p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="le_script_de_mise_à_jour_automatique">5. Le script de mise à jour automatique</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/vscode-update-sequence.svg" alt="vscode update sequence" width="1079" height="654"> </div> </div> <div class="sect2"> <h3 id="le_problème">5.1. Le problème</h3> <div class="paragraph"> <p>Quand VS Code se met à jour, il remplace le dossier d’installation et <strong>efface tous les patches CSS</strong>. Il faut ré-appliquer les modifications manuellement à chaque fois.</p> </div> </div> <div class="sect2"> <h3 id="le_script_vscode_update_sh">5.2. Le script <code>vscode-update.sh</code></h3> <div class="paragraph"> <p>On crée <code>~/apps/vscode-update.sh</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">#!/bin/bash set -e VSCODE_DIR="$HOME/apps/VSCode-linux-x64" BACKUP_DIR="$HOME/apps/vscode-backup" TEMP_DIR="/tmp/vscode-update" MENUBAR_FONT_SIZE="23px" DROPDOWN_FONT_SIZE="22px" echo "=== VS Code Local Updater ===" CURRENT_VERSION=$("$VSCODE_DIR/bin/code" --version 2>/dev/null | head -1) echo "Current version: $CURRENT_VERSION" echo "Downloading latest VS Code..." mkdir -p "$TEMP_DIR" wget -q "https://code.visualstudio.com/sha/download?build=stable&os=linux-x64" \ -O "$TEMP_DIR/vscode.tar.gz" echo "Extracting..." mkdir -p "$TEMP_DIR/extracted" tar -xzf "$TEMP_DIR/vscode.tar.gz" -C "$TEMP_DIR/extracted" NEW_VERSION=$("$TEMP_DIR/extracted/VSCode-linux-x64/bin/code" \ --version 2>/dev/null | head -1) echo "New version: $NEW_VERSION" if [ "$CURRENT_VERSION" = "$NEW_VERSION" ]; then echo "Already up to date!" rm -rf "$TEMP_DIR" exit 0 fi echo "Backing up current installation..." mkdir -p "$BACKUP_DIR" cp -r "$VSCODE_DIR" "$BACKUP_DIR/VSCode-linux-x64-$(date +%Y%m%d-%H%M%S)" echo "Updating..." rm -rf "$VSCODE_DIR" mv "$TEMP_DIR/extracted/VSCode-linux-x64" "$VSCODE_DIR" rm -rf "$TEMP_DIR" CSS_FILE="$VSCODE_DIR/resources/app/out/vs/workbench/workbench.desktop.main.css" echo "Re-applying custom CSS patch \ (menubar=${MENUBAR_FONT_SIZE}, dropdown=${DROPDOWN_FONT_SIZE})..." cat >> "$CSS_FILE" << CSSEOF .menubar-menu-title{font-size:${MENUBAR_FONT_SIZE}!important}\ .menubar>.menubar-menu-button{font-size:${MENUBAR_FONT_SIZE}!important}\ .monaco-menu-option{font-size:${DROPDOWN_FONT_SIZE}!important;\ line-height:34px!important}\ .monaco-menu .action-label:not(.codicon)\ {font-size:${DROPDOWN_FONT_SIZE}!important}\ .menubar-menu-items-holder .monaco-menu .action-item .action-label\ {font-size:${DROPDOWN_FONT_SIZE}!important} CSSEOF PRODUCT_JSON="$VSCODE_DIR/resources/app/product.json" if [ -f "$PRODUCT_JSON" ]; then echo "Removing checksums to prevent integrity warning..." python3 -c " import json with open('$PRODUCT_JSON','r') as f: data=json.load(f) data.pop('checksums', None) with open('$PRODUCT_JSON','w') as f: json.dump(data,f,indent=2) print('Done.') " fi echo "=== Update complete: $CURRENT_VERSION -> $NEW_VERSION ==="</code></pre> </div> </div> <div class="paragraph"> <p>Le script :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Télécharge la dernière version stable</p> </li> <li> <p>Vérifie si la version diffère de l’actuelle</p> </li> <li> <p>Sauvegarde l’installation courante (timestampée) dans <code>~/apps/vscode-backup/</code></p> </li> <li> <p>Remplace le dossier d’installation</p> </li> <li> <p><strong>Re-applique</strong> le patch CSS du menu principal</p> </li> <li> <p><strong>Supprime les checksums</strong> de <code>product.json</code> pour éviter le warning d’intégrité</p> </li> </ol> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> Les customisations du volet Explorer via l’extension Custom CSS et le fichier <code>~/.vscode-custom-css/custom.css</code> survivent aux mises à jour car elles vivent hors du dossier d’installation. </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="fichiers_impliqués_vue_densemble">6. Fichiers impliqués — vue d’ensemble</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/vscode-files-deployment.svg" alt="vscode files deployment" width="907" height="331"> </div> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 28.5714%;"> <col style="width: 42.8571%;"> <col style="width: 28.5715%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Chemin</th> <th class="tableblock halign-left valign-top">Rôle</th> <th class="tableblock halign-left valign-top">Survit aux mises à jour ?</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/apps/VSCode-linux-x64/</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Installation de l’IDE</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non (remplacée)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/apps/VSCode-linux-x64/resources/app/out/vs/workbench/workbench.desktop.main.css</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">CSS du workbench (menu, dropdowns)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non (re-patché par le script)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/apps/VSCode-linux-x64/resources/app/product.json</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Checksums d’intégrité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Non (re-nettoyé par le script)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/apps/vscode-update.sh</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Script de mise à jour automatique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Oui</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/.config/Code/User/settings.json</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Paramètres utilisateur (fontSize, custom CSS)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Oui</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>~/.vscode-custom-css/custom.css</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">CSS custom pour l’Explorer (zoom)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Oui</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="leçons_apprises">7. Leçons apprises</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/vscode-lessons-learned.svg" alt="vscode lessons learned" width="1116" height="532"> </div> </div> <div class="sect2"> <h3 id="installer_dans_le_home_libère_tout">7.1. Installer dans le home libère tout</h3> <div class="paragraph"> <p>Une installation locale dans <code>~/apps</code> donne un contrôle total sur VS Code :</p> </div> <div class="ulist"> <ul> <li> <p>Pas de <code>sudo</code> pour modifier le CSS ou la configuration</p> </li> <li> <p>L’agent opencode+LLM peut écrire dans les fichiers de config et les assets de l’IDE</p> </li> <li> <p>Rollback trivial : restaurer le backup horodaté</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="zoom_font_size_pour_les_composants_list">7.2. <code>zoom</code> > <code>font-size</code> pour les composants list</h3> <div class="paragraph"> <p>VS Code contrôle la hauteur des lignes via JavaScript. Modifier <code>font-size</code> sans pouvoir toucher à la hauteur allouée par le moteur de layout donne des textes qui débordent. La propriété <code>zoom</code> sur le conteneur parent agrandit tout proportionnellement et contourne ce problème.</p> </div> </div> <div class="sect2"> <h3 id="lextension_custom_css_nécessite_une_activation_explicite">7.3. L’extension Custom CSS nécessite une activation explicite</h3> <div class="paragraph"> <p>Ce n’est pas un paramètre "set and forget". Chaque modification du fichier CSS custom nécessite de re-exécuter "Enable Custom CSS and JS" depuis la palette de commandes (<code>Ctrl+Shift+P</code>).</p> </div> </div> <div class="sect2"> <h3 id="un_script_de_mise_à_jour_est_indispensable">7.4. Un script de mise à jour est indispensable</h3> <div class="paragraph"> <p>Sans script, chaque mise à jour de VS Code efface les patches CSS du workbench. Le script <code>vscode-update.sh</code> automatise le téléchargement, le remplacement, le re-patch et le nettoyage des checksums.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="références_rapides">8. Références rapides</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Téléchargement VS Code : <a href="https://code.visualstudio.com/Download" class="bare">https://code.visualstudio.com/Download</a></p> </li> <li> <p>Extension Custom CSS and JS Loader : <code>be5invis.vscode-custom-css</code></p> </li> <li> <p>Issue VS Code demandant un paramètre natif pour la police de l’Explorer : <a href="https://github.com/microsoft/vscode/issues/149">github.com/microsoft/vscode#149</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2026/0102_migration_gradle_script_to_plugin_post.html Thu, 16 Apr 2026 00:00:00 +0000 blog/2026/0102_migration_gradle_script_to_plugin_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#contexte_et_objectif">1. Contexte et objectif</a> <ul class="sectlevel2"> <li><a href="#le_point_de_départ">1.1. Le point de départ</a></li> <li><a href="#lobjectif">1.2. L’objectif</a></li> </ul> </li> <li><a href="#le_premier_obstacle_ruby_gems">2. Le premier obstacle : <code>ruby { gems() }</code></a> <ul class="sectlevel2"> <li><a href="#ce_que_cache_le_sucre_syntaxique_groovy">2.1. Ce que cache le sucre syntaxique Groovy</a></li> <li><a href="#décomposition_du_mécanisme">2.2. Décomposition du mécanisme</a></li> </ul> </li> <li><a href="#la_solution_en_trois_parties">3. La solution en trois parties</a> <ul class="sectlevel2"> <li><a href="#partie_1_le_repo_ivy_pour_rubygems">3.1. Partie 1 : le repo Ivy pour rubygems</a></li> <li><a href="#partie_2_la_dépendance_asciidoctorgems">3.2. Partie 2 : la dépendance asciidoctorGems</a></li> <li><a href="#partie_3_settings_gradle_kts">3.3. Partie 3 : settings.gradle.kts</a></li> </ul> </li> <li><a href="#introspection_de_lapi_par_bytecodes">4. Introspection de l’API par bytecodes</a> <ul class="sectlevel2"> <li><a href="#pourquoi_javap">4.1. Pourquoi <code>javap</code> ?</a></li> <li><a href="#hiérarchie_de_la_tâche">4.2. Hiérarchie de la tâche</a></li> <li><a href="#découverte_de_forkoptions">4.3. Découverte de <code>forkOptions</code></a></li> <li><a href="#lapi_de_javaforkoptions_grolifant">4.4. L’API de JavaForkOptions (grolifant)</a></li> <li><a href="#revealjsextension">4.5. RevealJSExtension</a></li> </ul> </li> <li><a href="#configuration_du_toolchain_java">5. Configuration du toolchain Java</a> <ul class="sectlevel2"> <li><a href="#le_problème_de_javatoolchainservice">5.1. Le problème de JavaToolchainService</a></li> </ul> </li> <li><a href="#détection_automatique_docker">6. Détection automatique Docker</a> <ul class="sectlevel2"> <li><a href="#contexte">6.1. Contexte</a></li> <li><a href="#stratégie">6.2. Stratégie</a></li> </ul> </li> <li><a href="#résultat_final">7. Résultat final</a> <ul class="sectlevel2"> <li><a href="#le_buildscript_consommateur">7.1. Le buildscript consommateur</a></li> <li><a href="#settings_gradle_kts">7.2. settings.gradle.kts</a></li> </ul> </li> <li><a href="#récapitulatif_des_pièges_et_solutions">8. Récapitulatif des pièges et solutions</a></li> <li><a href="#méthode_dinvestigation_lire_une_api_inconnue_avec_javap">9. Méthode d’investigation : lire une API inconnue avec javap</a> <ul class="sectlevel2"> <li><a href="#principe">9.1. Principe</a></li> <li><a href="#étape_1_localiser_le_jar_dans_le_cache_gradle">9.2. Étape 1 : localiser le jar dans le cache Gradle</a></li> <li><a href="#étape_2_lister_les_classes_du_jar">9.3. Étape 2 : lister les classes du jar</a></li> <li><a href="#étape_3_inspecter_une_classe">9.4. Étape 3 : inspecter une classe</a></li> <li><a href="#étape_4_remonter_la_hiérarchie">9.5. Étape 4 : remonter la hiérarchie</a></li> <li><a href="#étape_5_suivre_les_types_inconnus">9.6. Étape 5 : suivre les types inconnus</a></li> <li><a href="#étape_6_vérifier_les_extensions_de_projet">9.7. Étape 6 : vérifier les extensions de projet</a></li> <li><a href="#récapitulatif_de_la_méthode">9.8. Récapitulatif de la méthode</a></li> </ul> </li> <li><a href="#prochaine_étape">10. Prochaine étape</a></li> </ul> </div> <div class="sect1"> <h2 id="contexte_et_objectif">1. Contexte et objectif</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_point_de_départ">1.1. Le point de départ</h3> <div class="paragraph"> <p>Le projet <code>slider-gradle</code> génère des présentations Reveal.js à partir de fichiers AsciiDoc via le plugin Gradle <code>org.asciidoctor.jvm.revealjs</code>. La configuration de la tâche principale <code>asciidoctorRevealJs</code> vivait directement dans le buildscript racine <code>build.gradle.kts</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">plugins { id("org.asciidoctor.jvm.revealjs") } apply<slides.SlidesPlugin>() project.tasks.getByName<AsciidoctorJRevealJSTask>(TASK_ASCIIDOCTOR_REVEALJS) { repositories { ruby { gems() } } revealjs { version = "3.1.0" templateGitHub { setOrganisation("hakimel") setRepository("reveal.js") setTag("3.9.1") } } revealjsOptions { // ... configuration complète } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="lobjectif">1.2. L’objectif</h3> <div class="paragraph"> <p>Déplacer toute cette configuration dans <code>buildSrc/src/main/kotlin/slides/SlidesPlugin.kt</code> pour que le buildscript consommateur se réduise à :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">apply<slides.SlidesPlugin>()</code></pre> </div> </div> <div class="paragraph"> <p>Le plugin doit être totalement autonome : il applique lui-même ses dépendances de plugins, configure ses repos, et gère ses gems Ruby.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="le_premier_obstacle_ruby_gems">2. Le premier obstacle : <code>ruby { gems() }</code></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="ce_que_cache_le_sucre_syntaxique_groovy">2.1. Ce que cache le sucre syntaxique Groovy</h3> <div class="paragraph"> <p>La ligne <code>repositories { ruby { gems() } }</code> est une extension DSL Groovy disponible uniquement dans le contexte d’exécution du buildscript. Elle n’existe pas en tant qu’API Kotlin statique accessible depuis buildSrc.</p> </div> <div class="paragraph"> <p>En tentant de l’appeler depuis <code>SlidesPlugin.kt</code>, la compilation échoue immédiatement.</p> </div> </div> <div class="sect2"> <h3 id="décomposition_du_mécanisme">2.2. Décomposition du mécanisme</h3> <div class="paragraph"> <p>Après analyse du cache Gradle (<code>~/.gradle/caches/modules-2/files-2.1/rubygems/</code>), on découvre dans le fichier <code>ivy-3.1.0.xml</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-xml hljs" data-lang="xml"><artifact type='gem' url='https://rubygems.org/gems/asciidoctor-revealjs-3.1.0.gem' /></code></pre> </div> </div> <div class="paragraph"> <p><code>ruby { gems() }</code> effectuait en réalité <strong>trois opérations distinctes</strong> :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Enregistrer un repo Ivy pointant vers <code><a href="https://rubygems.org/gems/" class="bare">https://rubygems.org/gems/</a></code></p> </li> <li> <p>Exclure le groupe <code>rubygems</code> des repos Maven pour éviter les conflits</p> </li> <li> <p>Enregistrer la gem dans la configuration <code>asciidoctorGems</code> pour que JRuby la charge au runtime</p> </li> </ol> </div> <div class="paragraph"> <p>Ces trois responsabilités doivent être reproduites séparément en Kotlin.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_en_trois_parties">3. La solution en trois parties</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="partie_1_le_repo_ivy_pour_rubygems">3.1. Partie 1 : le repo Ivy pour rubygems</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">project.repositories.mavenCentral() { content { excludeGroup("rubygems") } } project.repositories.ivy { url = project.uri("https://rubygems.org/gems/") patternLayout { artifact("[module]-[revision].gem") } <i class="conum" data-value="1"></i><b>(1)</b> metadataSources { artifact() } content { includeGroup("rubygems") } }</code></pre> </div> </div> <div class="colist arabic"> <table> <tr> <td><i class="conum" data-value="1"></i><b>1</b></td> <td>L’extension <code>.gem</code> doit être hardcodée. <code>[ext]</code> résout par défaut en <code>.jar</code>, ce qui provoque une erreur <code>Resource missing</code>.</td> </tr> </table> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> Le repo Ivy est déclaré directement sur <code>project.repositories</code> et non dans un bloc <code>repositories { }</code> car le receiver de ce bloc n’est pas le <code>RepositoryHandler</code> standard de Gradle mais une API grolifant incompatible avec l’extension <code>ivy</code> Kotlin DSL. </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="partie_2_la_dépendance_asciidoctorgems">3.2. Partie 2 : la dépendance asciidoctorGems</h3> <div class="paragraph"> <p>Le plugin <code>org.asciidoctor.jvm.gems</code> doit être appliqué en premier — il crée la configuration <code>asciidoctorGems</code> et la tâche <code>asciidoctorGemsPrepare</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">project.plugins.apply("org.asciidoctor.jvm.gems") project.plugins.apply("org.asciidoctor.jvm.revealjs") <i class="conum" data-value="1"></i><b>(1)</b> project.dependencies { add("asciidoctorGems", "rubygems:asciidoctor-revealjs:3.1.0@gem") <i class="conum" data-value="2"></i><b>(2)</b> }</code></pre> </div> </div> <div class="colist arabic"> <table> <tr> <td><i class="conum" data-value="1"></i><b>1</b></td> <td>L’ordre d’application est important : <code>gems</code> avant <code>revealjs</code>.</td> </tr> <tr> <td><i class="conum" data-value="2"></i><b>2</b></td> <td>Le qualificateur <code>@gem</code> force l’extension correcte sur la dépendance.</td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="partie_3_settings_gradle_kts">3.3. Partie 3 : settings.gradle.kts</h3> <div class="paragraph"> <p><code>dependencyResolutionManagement</code> dans <code>settings.gradle.kts</code> doit autoriser les projets à déclarer leurs propres repos :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Suppress("UnstableApiUsage") dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.PREFER_PROJECT) }</code></pre> </div> </div> <div class="paragraph"> <p>Sans cette ligne, Gradle ignore les repos déclarés dans le plugin et la résolution des gems échoue.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="introspection_de_lapi_par_bytecodes">4. Introspection de l’API par bytecodes</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="pourquoi_javap">4.1. Pourquoi <code>javap</code> ?</h3> <div class="paragraph"> <p>Le plugin <code>asciidoctor-gradle-jvm-slides</code> est en version <code>4.0.0-alpha.1</code>. Sa documentation est inexistante ou incomplète. La seule source fiable est l’inspection directe des classes compilées.</p> </div> </div> <div class="sect2"> <h3 id="hiérarchie_de_la_tâche">4.2. Hiérarchie de la tâche</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">javap -p -classpath asciidoctor-gradle-jvm-slides-4.0.0-alpha.1.jar \ org.asciidoctor.gradle.jvm.slides.AsciidoctorJRevealJSTask</code></pre> </div> </div> <div class="paragraph"> <p>Résultat :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">public class AsciidoctorJRevealJSTask extends org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask implements org.asciidoctor.gradle.base.slides.SlidesToExportAware</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="découverte_de_forkoptions">4.3. Découverte de <code>forkOptions</code></h3> <div class="paragraph"> <p>En inspectant <code>AbstractAsciidoctorTask</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">javap -p -classpath asciidoctor-gradle-jvm-4.0.0-alpha.1.jar \ org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask | grep -i "fork\|exec\|jvm"</code></pre> </div> </div> <div class="paragraph"> <p>On trouve :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">final org.ysb33r.grolifant.api.v4.JavaForkOptions javaForkOptions; public void forkOptions(org.gradle.api.Action<org.ysb33r.grolifant.api.v4.JavaForkOptions>); public static final org.asciidoctor.gradle.base.process.ProcessMode JAVA_EXEC;</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="lapi_de_javaforkoptions_grolifant">4.4. L’API de JavaForkOptions (grolifant)</h3> <div class="paragraph"> <p><code>javaLauncher</code> n’existe pas sur cette tâche. L’API réelle de <code>org.ysb33r.grolifant.api.v4.JavaForkOptions</code> expose :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">public void executable(java.lang.Object); <i class="conum" data-value="1"></i><b>(1)</b> public void setExecutable(java.lang.Object);</code></pre> </div> </div> <div class="colist arabic"> <table> <tr> <td><i class="conum" data-value="1"></i><b>1</b></td> <td>La méthode <code>executable(Object)</code> remplace l’assignation <code>executable = …​</code> qui ne compile pas (<code>val</code> cannot be reassigned).</td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="revealjsextension">4.5. RevealJSExtension</h3> <div class="paragraph"> <p><code>revealjs { }</code> n’est pas une méthode de la tâche mais une <strong>extension de projet</strong> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">javap -p -classpath asciidoctor-gradle-jvm-slides-4.0.0-alpha.1.jar \ org.asciidoctor.gradle.jvm.slides.RevealJSExtension</code></pre> </div> </div> <div class="paragraph"> <p>Elle s’accède via :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">project.extensions.getByType<RevealJSExtension>().apply { version = "3.1.0" templateGitHub { setOrganisation("hakimel") setRepository("reveal.js") setTag("3.9.1") } }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="configuration_du_toolchain_java">5. Configuration du toolchain Java</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_problème_de_javatoolchainservice">5.1. Le problème de JavaToolchainService</h3> <div class="paragraph"> <p><code>JavaToolchainService</code> n’est pas une extension de projet. L’appel suivant échoue :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// ERREUR : Extension of type 'JavaToolchainService' does not exist project.extensions.getByType<JavaToolchainService>()</code></pre> </div> </div> <div class="paragraph"> <p>La bonne API est <code>serviceOf</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">import org.gradle.kotlin.dsl.support.serviceOf project.tasks.getByName<AsciidoctorJRevealJSTask>(TASK_ASCIIDOCTOR_REVEALJS) { setInProcess("JAVA_EXEC") forkOptions { executable( project.serviceOf<JavaToolchainService>() .launcherFor { languageVersion.set(JavaLanguageVersion.of(17)) vendor.set(JvmVendorSpec.ADOPTIUM) } .get() .executablePath .asFile .absolutePath ) } }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="détection_automatique_docker">6. Détection automatique Docker</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="contexte">6.1. Contexte</h3> <div class="paragraph"> <p>Le plugin Asciidoctor/JRuby requiert Java 17. Kotlin 2.0.x dans buildSrc ne supporte pas Java 25 (le parser de version crashe sur <code>"25.0.2"</code>). Le daemon Gradle doit donc tourner sur Java 17 ou Docker doit être utilisé.</p> </div> </div> <div class="sect2"> <h3 id="stratégie">6.2. Stratégie</h3> <div class="olist arabic"> <ol class="arabic"> <li> <p>Docker disponible → exécution via container <code>eclipse-temurin:17</code> (comportement par défaut)</p> </li> <li> <p>Docker absent + Java 17 → exécution locale</p> </li> <li> <p>Docker absent + Java > 17 → erreur explicite</p> </li> </ol> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">val isDockerAvailable = try { Runtime.getRuntime().exec(arrayOf("docker", "info")).waitFor() == 0 } catch (e: Exception) { false } val javaVersion = JavaVersion.current().majorVersion.toInt() when { isDockerAvailable -> project.tasks.register<Exec>(TASK_ASCIIDOCTOR_REVEALJS) { group = GROUP_TASK_SLIDER description = "Slider settings and generation (via Docker)" dependsOn(TASK_CLEAN_SLIDES_BUILD) finalizedBy(TASK_DASHBOARD_SLIDES_BUILD) commandLine( "docker", "run", "--rm", "-v", "${project.rootDir.absolutePath}:/workspace", "-v", "${System.getProperty("user.home")}/.gradle:/root/.gradle", "-w", "/workspace", "eclipse-temurin:17", "./gradlew", TASK_ASCIIDOCTOR_REVEALJS ) workingDir = project.rootDir } javaVersion == 17 -> { project.repositories.mavenCentral() { content { excludeGroup("rubygems") } } project.repositories.ivy { url = project.uri("https://rubygems.org/gems/") patternLayout { artifact("[module]-[revision].gem") } metadataSources { artifact() } content { includeGroup("rubygems") } } project.extensions.getByType<RevealJSExtension>().apply { version = "3.1.0" templateGitHub { setOrganisation("hakimel") setRepository("reveal.js") setTag("3.9.1") } } project.tasks.getByName<AsciidoctorJRevealJSTask>(TASK_ASCIIDOCTOR_REVEALJS) { setInProcess("JAVA_EXEC") forkOptions { executable( project.serviceOf<JavaToolchainService>() .launcherFor { languageVersion.set(JavaLanguageVersion.of(17)) vendor.set(JvmVendorSpec.ADOPTIUM) } .get() .executablePath .asFile .absolutePath ) } // ... reste de la configuration } } else -> error( "Docker est requis pour exécuter $TASK_ASCIIDOCTOR_REVEALJS " + "avec Java $javaVersion. Installez Docker ou utilisez Java 17." ) }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="résultat_final">7. Résultat final</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_buildscript_consommateur">7.1. Le buildscript consommateur</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">apply<slides.SlidesPlugin>()</code></pre> </div> </div> <div class="paragraph"> <p>C’est tout. Le plugin porte l’intégralité de la responsabilité.</p> </div> </div> <div class="sect2"> <h3 id="settings_gradle_kts">7.2. settings.gradle.kts</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">pluginManagement { repositories { mavenLocal() gradlePluginPortal() } } plugins { id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0" } @Suppress("UnstableApiUsage") dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.PREFER_PROJECT) } rootProject.name = "slider-gradle"</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="récapitulatif_des_pièges_et_solutions">8. Récapitulatif des pièges et solutions</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 37.5%;"> <col style="width: 37.5%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Problème</th> <th class="tableblock halign-left valign-top">Cause</th> <th class="tableblock halign-left valign-top">Solution</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ruby { gems() }</code> non disponible en Kotlin</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Extension DSL Groovy uniquement</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Trois mécanismes séparés : repo Ivy + exclusion Maven + <code>asciidoctorGems</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Gradle cherche un <code>.jar</code> au lieu d’un <code>.gem</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>[ext]</code> résout en <code>jar</code> par défaut</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Hardcoder <code>.gem</code> dans le pattern Ivy + qualificateur <code>@gem</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>ivy { }</code> ne compile pas dans <code>repositories { }</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Receiver grolifant incompatible avec le DSL Kotlin</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Appel direct <code>project.repositories.ivy { }</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>javaLauncher</code> non résolu</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Propriété inexistante sur <code>AsciidoctorJRevealJSTask</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>setInProcess("JAVA_EXEC")</code> + <code>forkOptions { executable(…​) }</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>executable = …​</code> ne compile pas</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Propriété <code>val</code> dans <code>JavaForkOptions</code> grolifant</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Méthode <code>executable(Object)</code> à la place</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>JavaToolchainService</code> introuvable via <code>extensions</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">C’est un service Gradle, pas une extension</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>project.serviceOf<JavaToolchainService>()</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>revealjs { }</code> non résolu dans la tâche</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Extension de projet, pas méthode de tâche</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>project.extensions.getByType<RevealJSExtension>()</code></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Build crashe avec Java 25</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Kotlin 2.0.x ne parse pas les versions Java à deux chiffres</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Détection Docker automatique + fallback Java 17</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="méthode_dinvestigation_lire_une_api_inconnue_avec_javap">9. Méthode d’investigation : lire une API inconnue avec javap</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="principe">9.1. Principe</h3> <div class="paragraph"> <p>Quand la documentation est absente ou incomplète, les bytecodes sont la source de vérité. <code>javap</code> est l’outil standard du JDK qui décompile les fichiers <code>.class</code> en signatures Java lisibles, sans nécessiter le code source.</p> </div> </div> <div class="sect2"> <h3 id="étape_1_localiser_le_jar_dans_le_cache_gradle">9.2. Étape 1 : localiser le jar dans le cache Gradle</h3> <div class="paragraph"> <p>Gradle télécharge toutes ses dépendances dans <code>~/.gradle/caches/modules-2/files-2.1/</code>. La première étape est de trouver le jar qui contient la classe à inspecter :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">find ~/.gradle/caches -name "asciidoctor-gradle-jvm-slides*.jar" 2>/dev/null</code></pre> </div> </div> <div class="listingblock"> <div class="title">Résultat :</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">/home/user/.gradle/caches/modules-2/files-2.1/org.asciidoctor/ asciidoctor-gradle-jvm-slides/4.0.0-alpha.1/.../ asciidoctor-gradle-jvm-slides-4.0.0-alpha.1.jar</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="étape_2_lister_les_classes_du_jar">9.3. Étape 2 : lister les classes du jar</h3> <div class="paragraph"> <p>Avant d’inspecter une classe, on vérifie qu’elle existe bien dans le jar :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">jar tf asciidoctor-gradle-jvm-slides-4.0.0-alpha.1.jar | grep -i "RevealJS\|revealjs"</code></pre> </div> </div> <div class="paragraph"> <div class="title">Cela révèle toutes les classes disponibles :</div> <p><code>AsciidoctorJRevealJSTask</code>, <code>RevealJSExtension</code>, <code>RevealJSOptions</code>, etc.</p> </div> </div> <div class="sect2"> <h3 id="étape_3_inspecter_une_classe">9.4. Étape 3 : inspecter une classe</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">javap -p -classpath asciidoctor-gradle-jvm-slides-4.0.0-alpha.1.jar \ org.asciidoctor.gradle.jvm.slides.AsciidoctorJRevealJSTask</code></pre> </div> </div> <div class="paragraph"> <p>L’option <code>-p</code> affiche tous les membres y compris les privés. Le résultat montre immédiatement la ligne clé :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">public class AsciidoctorJRevealJSTask extends org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="étape_4_remonter_la_hiérarchie">9.5. Étape 4 : remonter la hiérarchie</h3> <div class="paragraph"> <p>La tâche étend <code>AbstractAsciidoctorTask</code>. On l’inspecte à son tour en localisant d’abord son jar :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">find ~/.gradle/caches -name "asciidoctor-gradle-jvm-[0-9]*.jar" 2>/dev/null javap -p -classpath asciidoctor-gradle-jvm-4.0.0-alpha.1.jar \ org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask | grep -i "fork\|exec\|jvm\|java"</code></pre> </div> </div> <div class="paragraph"> <p>C’est là qu’on découvre <code>forkOptions</code>, <code>JAVA_EXEC</code>, et <code>javaForkOptions</code> de type <code>org.ysb33r.grolifant.api.v4.JavaForkOptions</code>.</p> </div> </div> <div class="sect2"> <h3 id="étape_5_suivre_les_types_inconnus">9.6. Étape 5 : suivre les types inconnus</h3> <div class="paragraph"> <p><code>JavaForkOptions</code> est une classe grolifant inconnue. On localise son jar :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">find ~/.gradle/caches -name "grolifant*.jar" 2>/dev/null</code></pre> </div> </div> <div class="paragraph"> <p>Puis on l’inspecte :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">javap -p -classpath grolifant40-legacy-api-2.0.0-alpha.6.jar \ org.ysb33r.grolifant.api.v4.JavaForkOptions</code></pre> </div> </div> <div class="paragraph"> <p>On y trouve <code>executable(java.lang.Object)</code> — la méthode correcte à appeler, par opposition à <code>executable = …​</code> qui ne compile pas car c’est une propriété <code>val</code>.</p> </div> </div> <div class="sect2"> <h3 id="étape_6_vérifier_les_extensions_de_projet">9.7. Étape 6 : vérifier les extensions de projet</h3> <div class="paragraph"> <p>Pour <code>revealjs { }</code>, la question était : est-ce une méthode de la tâche ou une extension de projet ? L’inspection de <code>AsciidoctorJRevealJSTask</code> ne montre aucune méthode <code>revealjs</code>. On inspecte alors <code>RevealJSExtension</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">javap -p -classpath asciidoctor-gradle-jvm-slides-4.0.0-alpha.1.jar \ org.asciidoctor.gradle.jvm.slides.RevealJSExtension | head -5</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">public class RevealJSExtension implements groovy.lang.GroovyObject { public static final java.lang.String NAME;</code></pre> </div> </div> <div class="paragraph"> <p>La présence de <code>NAME</code> confirme que c’est une extension enregistrée sur le projet, accessible via <code>project.extensions.getByType<RevealJSExtension>()</code>.</p> </div> </div> <div class="sect2"> <h3 id="récapitulatif_de_la_méthode">9.8. Récapitulatif de la méthode</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Étape</th> <th class="tableblock halign-left valign-top">Action</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">1</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>find ~/.gradle/caches -name "*.jar"</code> — localiser le jar</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">2</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>jar tf jar.jar | grep NomClasse</code> — vérifier que la classe existe</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">3</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>javap -p -classpath jar.jar NomCompletClasse</code> — inspecter la classe</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">4</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Identifier <code>extends</code> et remonter la hiérarchie</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">5</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Suivre les types inconnus dans leurs propres jars</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">6</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Chercher <code>NAME</code> pour identifier une extension de projet</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Cette méthode s’applique à n’importe quel plugin Gradle dont l’API n’est pas documentée ou dont la version alpha ne correspond plus à la documentation existante.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="prochaine_étape">10. Prochaine étape</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce plugin buildSrc sera extrait dans un projet indépendant publié sur Gradle Plugin Portal ou Maven Local. Le buildscript consommateur deviendra alors :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">plugins { id("slides") version "1.0.0" }</code></pre> </div> </div> <div class="paragraph"> <p>Et <code>settings.gradle.kts</code> sera réduit à son strict minimum sans référence à <code>foojay-resolver-convention</code>, le provisioning JDK étant géré par le plugin lui-même ou documenté comme prérequis.</p> </div> </div> </div> https://pages-content.github.io//blog/2026/0101_jbake_portfolio_post.html Thu, 15 Jan 2026 00:00:00 +0000 blog/2026/0101_jbake_portfolio_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#vision_architecturale">1. Vision Architecturale</a> <ul class="sectlevel2"> <li><a href="#principe_directeur">1.1. Principe directeur</a></li> <li><a href="#choix_stratégique_asciidoc_pour_le_portfolio">1.2. Choix stratégique : AsciiDoc pour le portfolio</a></li> <li><a href="#modèle_de_données">1.3. Modèle de données</a></li> </ul> </li> <li><a href="#use_cases_détaillés">2. Use Cases Détaillés</a> <ul class="sectlevel2"> <li><a href="#uc1_ajouter_un_élément_au_portfolio">2.1. UC1 : Ajouter un élément au portfolio</a> <ul class="sectlevel3"> <li><a href="#flux_nominal">2.1.1. Flux nominal</a></li> <li><a href="#template_du_fichier_à_créer">2.1.2. Template du fichier à créer</a></li> <li><a href="#points_de_validation">2.1.3. Points de validation</a></li> </ul> </li> <li><a href="#uc2_supprimer_un_élément_du_portfolio">2.2. UC2 : Supprimer un élément du portfolio</a> <ul class="sectlevel3"> <li><a href="#flux_nominal_2">2.2.1. Flux nominal</a></li> <li><a href="#stratégie_alternative_archivage">2.2.2. Stratégie alternative : archivage</a></li> <li><a href="#nettoyage_des_ressources">2.2.3. Nettoyage des ressources</a></li> </ul> </li> <li><a href="#uc3_mettre_en_non_publié_draft">2.3. UC3 : Mettre en non publié (draft)</a> <ul class="sectlevel3"> <li><a href="#flux_nominal_3">2.3.1. Flux nominal</a></li> <li><a href="#états_possibles">2.3.2. États possibles</a></li> <li><a href="#cas_dusage_typiques">2.3.3. Cas d’usage typiques</a></li> </ul> </li> </ul> </li> <li><a href="#architecture_de_templating">3. Architecture de Templating</a> <ul class="sectlevel2"> <li><a href="#stratégie_de_templates_réutilisables">3.1. Stratégie de templates réutilisables</a></li> <li><a href="#pattern_dextraction_des_données">3.2. Pattern d’extraction des données</a></li> <li><a href="#conventions_de_nommage">3.3. Conventions de nommage</a></li> </ul> </li> <li><a href="#workflow_de_publication">4. Workflow de Publication</a> <ul class="sectlevel2"> <li><a href="#pipeline_de_développement">4.1. Pipeline de développement</a></li> <li><a href="#environnements">4.2. Environnements</a></li> </ul> </li> <li><a href="#extensibilité">5. Extensibilité</a> <ul class="sectlevel2"> <li><a href="#ajout_de_nouveaux_attributs">5.1. Ajout de nouveaux attributs</a></li> <li><a href="#catégorisation_avancée">5.2. Catégorisation avancée</a></li> </ul> </li> <li><a href="#bonnes_pratiques">6. Bonnes Pratiques</a> <ul class="sectlevel2"> <li><a href="#organisation_des_fichiers">6.1. Organisation des fichiers</a></li> <li><a href="#gestion_du_contenu">6.2. Gestion du contenu</a></li> <li><a href="#performance">6.3. Performance</a></li> </ul> </li> <li><a href="#conclusion">7. Conclusion</a></li> </ul> </div> <div class="sect1"> <h2 id="vision_architecturale">1. Vision Architecturale</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="principe_directeur">1.1. Principe directeur</h3> <div class="paragraph"> <p>L’architecture repose sur le principe de <strong>séparation des préoccupations</strong> :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Contenu</strong> : fichiers AsciiDoc structurés avec métadonnées riches</p> </li> <li> <p><strong>Présentation</strong> : templates Thymeleaf réutilisables</p> </li> <li> <p><strong>Données</strong> : modèle extrait automatiquement par JBake depuis les attributs AsciiDoc</p> </li> <li> <p><strong>Style</strong> : Bootstrap 5 pour la cohérence visuelle</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="choix_stratégique_asciidoc_pour_le_portfolio">1.2. Choix stratégique : AsciiDoc pour le portfolio</h3> <table class="tableblock frame-all grid-all stretch"> <caption class="title">Table 1. Pourquoi AsciiDoc ?</caption> <colgroup> <col style="width: 33.3333%;"> <col style="width: 66.6667%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Critère</th> <th class="tableblock halign-left valign-top">Avantage</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Cohérence</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Même format que les articles de blog</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Métadonnées</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Attributs structurés et extensibles (<code>project-*</code>)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Maintenabilité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Édition simple en texte, versionnable Git</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Flexibilité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Peut contenir du contenu riche (tableaux, code, images)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Templating</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">JBake extrait automatiquement les attributs pour Thymeleaf</p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="modèle_de_données">1.3. Modèle de données</h3> <div class="paragraph"> <p>Chaque projet portfolio est un document AsciiDoc avec :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Métadonnées d’en-tête</strong> : informations structurées (client, durée, technologies, etc.)</p> </li> <li> <p><strong>Corps du document</strong> : description narrative, défis, solutions, résultats</p> </li> <li> <p><strong>Attributs personnalisés</strong> : préfixés <code>project-*</code> pour l’extraction automatique</p> </li> </ul> </div> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-39f614a45c003c8e4b1a076206012364.png" alt="Diagram" width="386" height="811"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="use_cases_détaillés">2. Use Cases Détaillés</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="uc1_ajouter_un_élément_au_portfolio">2.1. UC1 : Ajouter un élément au portfolio</h3> <div class="sect3"> <h4 id="flux_nominal">2.1.1. Flux nominal</h4> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-10f84eeb379f90577b624b1ddd2283fd.png" alt="Diagram" width="980" height="715"> </div> </div> </div> <div class="sect3"> <h4 id="template_du_fichier_à_créer">2.1.2. Template du fichier à créer</h4> <div class="paragraph"> <p>Le développeur crée <code>content/portfolio/nom-projet.adoc</code> avec une structure standardisée :</p> </div> <div class="ulist"> <ul> <li> <p>En-tête avec tous les attributs requis</p> </li> <li> <p>Sections normalisées (Contexte, Défis, Solutions, Résultats)</p> </li> <li> <p>Nomenclature cohérente des images</p> </li> </ul> </div> </div> <div class="sect3"> <h4 id="points_de_validation">2.1.3. Points de validation</h4> <div class="ulist"> <ul> <li> <p>Les attributs obligatoires sont présents (<code>jbake-type</code>, <code>jbake-status</code>, <code>project-thumbnail</code>)</p> </li> <li> <p>Les images référencées existent dans <code>assets/img/portfolio/</code></p> </li> <li> <p>Le build JBake réussit sans erreur</p> </li> <li> <p>Le projet apparaît sur la page portfolio</p> </li> <li> <p>La page individuelle du projet s’affiche correctement</p> </li> </ul> </div> </div> </div> <div class="sect2"> <h3 id="uc2_supprimer_un_élément_du_portfolio">2.2. UC2 : Supprimer un élément du portfolio</h3> <div class="sect3"> <h4 id="flux_nominal_2">2.2.1. Flux nominal</h4> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-d0113242083726276d0bc353b8b5f695.png" alt="Diagram" width="738" height="645"> </div> </div> </div> <div class="sect3"> <h4 id="stratégie_alternative_archivage">2.2.2. Stratégie alternative : archivage</h4> <div class="paragraph"> <p>Au lieu de supprimer définitivement, possibilité de créer un dossier <code>content/portfolio/archive/</code> :</p> </div> <div class="ulist"> <ul> <li> <p>Déplacer le fichier au lieu de le supprimer</p> </li> <li> <p>Permet de restaurer facilement</p> </li> <li> <p>Garde l’historique Git plus clair</p> </li> </ul> </div> </div> <div class="sect3"> <h4 id="nettoyage_des_ressources">2.2.3. Nettoyage des ressources</h4> <div class="ulist"> <ul> <li> <p>Vérifier les images orphelines dans <code>assets/img/portfolio/</code></p> </li> <li> <p>Supprimer les images non référencées par d’autres projets</p> </li> <li> <p>Nettoyer le cache JBake pour éviter les références fantômes</p> </li> </ul> </div> </div> </div> <div class="sect2"> <h3 id="uc3_mettre_en_non_publié_draft">2.3. UC3 : Mettre en non publié (draft)</h3> <div class="sect3"> <h4 id="flux_nominal_3">2.3.1. Flux nominal</h4> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-f7dfefdd65ada55b764b6d82def2581d.png" alt="Diagram" width="783" height="594"> </div> </div> </div> <div class="sect3"> <h4 id="états_possibles">2.3.2. États possibles</h4> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-a4b71e9dbf30083d131223257db47469.png" alt="Diagram" width="556" height="448"> </div> </div> </div> <div class="sect3"> <h4 id="cas_dusage_typiques">2.3.3. Cas d’usage typiques</h4> <div class="ulist"> <ul> <li> <p><strong>Projet en cours de rédaction</strong> : créer en draft, publier quand prêt</p> </li> <li> <p><strong>Projet confidentiel temporairement</strong> : passer en draft le temps de l’accord client</p> </li> <li> <p><strong>Mise à jour majeure</strong> : passer en draft, modifier, republier</p> </li> <li> <p><strong>A/B testing</strong> : dupliquer en draft, tester, publier la meilleure version</p> </li> </ul> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="architecture_de_templating">3. Architecture de Templating</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="stratégie_de_templates_réutilisables">3.1. Stratégie de templates réutilisables</h3> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-947a1865680ea1351c022f08cee9d68c.png" alt="Diagram" width="881" height="350"> </div> </div> </div> <div class="sect2"> <h3 id="pattern_dextraction_des_données">3.2. Pattern d’extraction des données</h3> <div class="paragraph"> <p>JBake transforme automatiquement les attributs AsciiDoc en propriétés accessibles dans Thymeleaf :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-24dd3ccd504cafd397fe34bb5e84e414.png" alt="Diagram" width="891" height="346"> </div> </div> </div> <div class="sect2"> <h3 id="conventions_de_nommage">3.3. Conventions de nommage</h3> <div class="ulist"> <ul> <li> <p><strong>Attributs projet</strong> : préfixe <code>project-*</code> (ex: <code>project-client</code>, <code>project-tech-stack</code>)</p> </li> <li> <p><strong>Fichiers</strong> : kebab-case (ex: <code>ecommerce-platform.adoc</code>)</p> </li> <li> <p><strong>Images</strong> : préfixe nom-projet (ex: <code>ecommerce-platform-thumb.jpg</code>)</p> </li> <li> <p><strong>Templates</strong> : nom fonctionnel (ex: <code>project-card.html</code>, <code>tech-badge.html</code>)</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="workflow_de_publication">4. Workflow de Publication</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="pipeline_de_développement">4.1. Pipeline de développement</h3> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-2694c3ad773a745365e7ae3fa7dc2d53.png" alt="Diagram" width="386" height="811"> </div> </div> </div> <div class="sect2"> <h3 id="environnements">4.2. Environnements</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 20%;"> <col style="width: 40%;"> <col style="width: 40%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Environnement</th> <th class="tableblock halign-left valign-top">Usage</th> <th class="tableblock halign-left valign-top">Statut accepté</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Local</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Développement et preview</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">draft, published</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Staging</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Validation pré-production</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">published uniquement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Production</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Site public</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">published uniquement</p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="extensibilité">5. Extensibilité</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="ajout_de_nouveaux_attributs">5.1. Ajout de nouveaux attributs</h3> <div class="paragraph"> <p>Pour enrichir le modèle de données, simplement ajouter de nouveaux attributs préfixés <code>project-*</code> :</p> </div> <div class="ulist"> <ul> <li> <p><code>project-awards</code>: Prix et reconnaissances</p> </li> <li> <p><code>project-testimonial</code>: Citation client</p> </li> <li> <p><code>project-team-size</code>: Taille équipe</p> </li> <li> <p><code>project-budget-range</code>: Fourchette budgétaire</p> </li> </ul> </div> <div class="paragraph"> <p>Ces attributs deviennent automatiquement disponibles dans les templates sans modification du moteur JBake.</p> </div> </div> <div class="sect2"> <h3 id="catégorisation_avancée">5.2. Catégorisation avancée</h3> <div class="imageblock"> <div class="content"> <img src="./images/diag-plantuml-md5-5778cdd97fbd507aeb0b4ae9b4bb4724.png" alt="Diagram" width="561" height="259"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="bonnes_pratiques">6. Bonnes Pratiques</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="organisation_des_fichiers">6.1. Organisation des fichiers</h3> <div class="ulist"> <ul> <li> <p><strong>Un fichier = un projet</strong> : éviter de mélanger plusieurs projets</p> </li> <li> <p><strong>Images dans dossier dédié</strong> : <code>assets/img/portfolio/nom-projet/</code></p> </li> <li> <p><strong>Nomenclature cohérente</strong> : facilite recherche et maintenance</p> </li> <li> <p><strong>Versioning Git</strong> : tracking complet des modifications</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="gestion_du_contenu">6.2. Gestion du contenu</h3> <div class="ulist"> <ul> <li> <p><strong>Statut draft par défaut</strong> : publier seulement quand prêt</p> </li> <li> <p><strong>Review avant publication</strong> : validation qualité et confidentialité</p> </li> <li> <p><strong>Métadonnées complètes</strong> : remplir tous les champs pertinents</p> </li> <li> <p><strong>Contenu narratif riche</strong> : ne pas se limiter aux métadonnées</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="performance">6.3. Performance</h3> <div class="ulist"> <ul> <li> <p><strong>Optimiser images</strong> : compression avant commit</p> </li> <li> <p><strong>Pagination si nécessaire</strong> : si >20 projets</p> </li> <li> <p><strong>Lazy loading</strong> : images des galeries chargées à la demande</p> </li> <li> <p><strong>Cache navigateur</strong> : headers appropriés pour assets</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="conclusion">7. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette architecture permet :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Simplicité d’usage</strong> : ajouter un projet = créer un fichier texte</p> </li> <li> <p><strong>Flexibilité</strong> : extensible via nouveaux attributs</p> </li> <li> <p><strong>Maintenabilité</strong> : séparation contenu/présentation</p> </li> <li> <p><strong>Traçabilité</strong> : versioning Git complet</p> </li> <li> <p><strong>Automatisation</strong> : build et déploiement continus possibles</p> </li> </ul> </div> <div class="paragraph"> <p>Le choix d’AsciiDoc assure la cohérence avec le reste du site tout en offrant la richesse des métadonnées nécessaires à un portfolio professionnel.</p> </div> </div> </div> https://pages-content.github.io//blog/2026/0100_jbake_supabase_springboot_hybride_post.html Wed, 14 Jan 2026 00:00:00 +0000 blog/2026/0100_jbake_supabase_springboot_hybride_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph lead"> <div class="title">temps de lecture : 12 minutes</div> <p>Plutôt que de choisir entre la simplicité de Supabase et la puissance de Spring Boot, pourquoi ne pas combiner les deux ? Découvrez une architecture hybride qui exploite le meilleur de chaque technologie.</p> </div> <div id="toc" class="toc"> <div id="toctitle" class="title">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_le_faux_dilemme_de_larchitecture_moderne">Le Faux Dilemme de l’Architecture Moderne</a></li> <li><a href="#_vision_architecturale">Vision Architecturale</a> <ul class="sectlevel2"> <li><a href="#_larchitecture_traditionnelle_monolithique">L’Architecture Traditionnelle : Monolithique</a></li> <li><a href="#_larchitecture_baas_tout_délégué">L’Architecture BaaS : Tout Délégué</a></li> <li><a href="#_larchitecture_hybride_séparation_des_responsabilités">L’Architecture Hybride : Séparation des Responsabilités</a></li> </ul> </li> <li><a href="#_principes_de_conception">Principes de Conception</a> <ul class="sectlevel2"> <li><a href="#_principe_1_commencer_simple_évoluer_intelligemment">Principe 1 : Commencer Simple, Évoluer Intelligemment</a></li> <li><a href="#_principe_2_séparation_par_nature_dopération">Principe 2 : Séparation par Nature d’Opération</a></li> <li><a href="#_principe_3_une_seule_source_de_vérité">Principe 3 : Une Seule Source de Vérité</a></li> </ul> </li> <li><a href="#_orchestration_des_flux">Orchestration des Flux</a> <ul class="sectlevel2"> <li><a href="#_flux_1_authentification_centralisée">Flux 1 : Authentification Centralisée</a></li> <li><a href="#_flux_2_orchestration_dun_processus_métier_complexe">Flux 2 : Orchestration d’un Processus Métier Complexe</a></li> <li><a href="#_flux_3_jobs_planifiés_et_synchronisations">Flux 3 : Jobs Planifiés et Synchronisations</a></li> </ul> </li> <li><a href="#_matrice_de_décision">Matrice de Décision</a> <ul class="sectlevel2"> <li><a href="#_quand_utiliser_supabase">Quand Utiliser Supabase ?</a></li> <li><a href="#_quand_utiliser_spring_boot">Quand Utiliser Spring Boot ?</a></li> </ul> </li> <li><a href="#_exemples_darchitecture_par_type_de_projet">Exemples d’Architecture par Type de Projet</a> <ul class="sectlevel2"> <li><a href="#_blog_portfolio">Blog / Portfolio</a></li> <li><a href="#_application_saas">Application SaaS</a></li> <li><a href="#_e_commerce">E-commerce</a></li> </ul> </li> <li><a href="#_stratégie_de_migration_progressive">Stratégie de Migration Progressive</a></li> <li><a href="#_coûts_et_considérations_opérationnelles">Coûts et Considérations Opérationnelles</a> <ul class="sectlevel2"> <li><a href="#_structure_des_coûts">Structure des Coûts</a></li> <li><a href="#_responsabilités_opérationnelles">Responsabilités Opérationnelles</a></li> </ul> </li> <li><a href="#_conclusion_léquilibre_parfait">Conclusion : L’Équilibre Parfait</a> <ul class="sectlevel2"> <li><a href="#_les_principes_à_retenir">Les Principes à Retenir</a></li> <li><a href="#_quand_choisir_cette_architecture">Quand Choisir Cette Architecture ?</a></li> <li><a href="#_vision_densemble_finale">Vision d’Ensemble Finale</a></li> <li><a href="#_le_meilleur_des_deux_mondes">Le Meilleur des Deux Mondes</a></li> </ul> </li> <li><a href="#_pour_aller_plus_loin">Pour Aller Plus Loin</a> <ul class="sectlevel2"> <li><a href="#_ressources_techniques">Ressources Techniques</a></li> <li><a href="#_cas_dusage_réels">Cas d’Usage Réels</a></li> <li><a href="#_checklist_de_démarrage">Checklist de Démarrage</a></li> <li><a href="#_anti_patterns_à_éviter">Anti-Patterns à Éviter</a></li> </ul> </li> <li><a href="#_perspectives_dévolution">Perspectives d’Évolution</a> <ul class="sectlevel2"> <li><a href="#_ajout_de_nouvelles_capacités">Ajout de Nouvelles Capacités</a></li> <li><a href="#_scaling_horizontal">Scaling Horizontal</a></li> </ul> </li> <li><a href="#_témoignages_architecturaux">Témoignages Architecturaux</a> <ul class="sectlevel2"> <li><a href="#_startup_saas_50k_utilisateurs">Startup SaaS (50k utilisateurs)</a></li> <li><a href="#_plateforme_e_learning_10k_utilisateurs">Plateforme E-learning (10k utilisateurs)</a></li> <li><a href="#_marketplace_b2b_3k_utilisateurs">Marketplace B2B (3k utilisateurs)</a></li> </ul> </li> <li><a href="#_synthèse_un_paradigme_architectural_moderne">Synthèse : Un Paradigme Architectural Moderne</a> <ul class="sectlevel2"> <li><a href="#_la_règle_des_8020">La Règle des 80/20</a></li> </ul> </li> <li><a href="#_conclusion_finale">Conclusion Finale</a> <ul class="sectlevel2"> <li><a href="#_votre_prochain_pas">Votre Prochain Pas</a></li> </ul> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_le_faux_dilemme_de_larchitecture_moderne">Le Faux Dilemme de l’Architecture Moderne</h2> <div class="sectionbody"> <div class="paragraph"> <p>Lorsqu’on construit une application moderne avec un frontend statique, on se retrouve souvent face à un choix binaire :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Tout miser sur une solution Backend-as-a-Service</strong> (Supabase, Firebase) - simple mais limitée</p> </li> <li> <p><strong>Construire un backend complet</strong> (Spring Boot, Node.js) - puissant mais complexe</p> </li> </ul> </div> <div class="paragraph"> <p>Ce choix est un faux dilemme. L’architecture hybride propose une troisième voie : <strong>utiliser chaque technologie là où elle excelle</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="_vision_architecturale">Vision Architecturale</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_larchitecture_traditionnelle_monolithique">L’Architecture Traditionnelle : Monolithique</h3> <div class="imageblock"> <div class="content"> <img src="traditional-architecture.svg" alt="traditional architecture" width="807" height="436"> </div> </div> <div class="paragraph"> <p>Dans cette approche, même les opérations les plus simples (lecture d’un article, création d’un commentaire) doivent transiter par votre backend. Vous payez le coût de la complexité dès le premier jour.</p> </div> </div> <div class="sect2"> <h3 id="_larchitecture_baas_tout_délégué">L’Architecture BaaS : Tout Délégué</h3> <div class="imageblock"> <div class="content"> <img src="baas-architecture.svg" alt="baas architecture" width="504" height="432"> </div> </div> <div class="paragraph"> <p>À l’opposé, tout déléguer à un BaaS est séduisant au début mais montre rapidement ses limites dès que la logique métier se complexifie.</p> </div> </div> <div class="sect2"> <h3 id="_larchitecture_hybride_séparation_des_responsabilités">L’Architecture Hybride : Séparation des Responsabilités</h3> <div class="imageblock"> <div class="content"> <img src="hybrid-overview.svg" alt="hybrid overview" width="1529" height="479"> </div> </div> <div class="paragraph"> <p>L’architecture hybride sépare clairement les responsabilités selon la complexité et la nature des opérations.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_principes_de_conception">Principes de Conception</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_principe_1_commencer_simple_évoluer_intelligemment">Principe 1 : Commencer Simple, Évoluer Intelligemment</h3> <div class="imageblock"> <div class="content"> <img src="evolution-phases.svg" alt="evolution phases" width="465" height="392"> </div> </div> <div class="paragraph"> <p><strong>Ne construisez pas Spring Boot si vous n’en avez pas besoin.</strong> Démarrez avec Supabase, ajoutez Spring Boot quand la complexité le justifie.</p> </div> </div> <div class="sect2"> <h3 id="_principe_2_séparation_par_nature_dopération">Principe 2 : Séparation par Nature d’Opération</h3> <div class="imageblock"> <div class="content"> <img src="operation-types.svg" alt="operation types" width="1266" height="241"> </div> </div> </div> <div class="sect2"> <h3 id="_principe_3_une_seule_source_de_vérité">Principe 3 : Une Seule Source de Vérité</h3> <div class="imageblock"> <div class="content"> <img src="single-source-truth.svg&quot; alt="single source truth" width="1361" height="247"> </div> </div> <div class="paragraph"> <p>En partageant la même instance PostgreSQL, Supabase et Spring Boot travaillent sur les mêmes données sans synchronisation complexe.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_orchestration_des_flux">Orchestration des Flux</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_flux_1_authentification_centralisée">Flux 1 : Authentification Centralisée</h3> <div class="imageblock"> <div class="content"> <img src="auth-orchestration.svg" alt="auth orchestration" width="1101" height="950"> </div> </div> <div class="paragraph"> <p><strong>Point clé</strong> : Un seul processus d’authentification, un seul JWT, utilisable partout.</p> </div> </div> <div class="sect2"> <h3 id="_flux_2_orchestration_dun_processus_métier_complexe">Flux 2 : Orchestration d’un Processus Métier Complexe</h3> <div class="imageblock"> <div class="content"> <img src="business-orchestration.svg" alt="business orchestration" width="1093" height="990"> </div> </div> <div class="paragraph"> <p><strong>Ce que Spring Boot apporte</strong> : Orchestration fiable de processus complexes impliquant plusieurs systèmes avec garantie transactionnelle.</p> </div> </div> <div class="sect2"> <h3 id="_flux_3_jobs_planifiés_et_synchronisations">Flux 3 : Jobs Planifiés et Synchronisations</h3> <div class="imageblock"> <div class="content"> <img src="scheduled-jobs.svg" alt="scheduled jobs" width="945" height="912"> </div> </div> <div class="paragraph"> <p><strong>Ce que Spring Boot apporte</strong> : Jobs planifiés fiables avec gestion d’état, retry automatique, et exécution garantie.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_matrice_de_décision">Matrice de Décision</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_quand_utiliser_supabase">Quand Utiliser Supabase ?</h3> <div class="imageblock"> <div class="content"> <img src="supabase-decision.svg" alt="supabase decision" width="1045" height="482"> </div> </div> </div> <div class="sect2"> <h3 id="_quand_utiliser_spring_boot">Quand Utiliser Spring Boot ?</h3> <div class="imageblock"> <div class="content"> <img src="springboot-decision.svg" alt="springboot decision" width="1157" height="522"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_exemples_darchitecture_par_type_de_projet">Exemples d’Architecture par Type de Projet</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_blog_portfolio">Blog / Portfolio</h3> <div class="imageblock"> <div class="content"> <img src="blog-architecture.svg" alt="blog architecture" width="1328" height="242"> </div> </div> <div class="paragraph"> <p><strong>Verdict</strong> : 100% Supabase suffit largement.</p> </div> </div> <div class="sect2"> <h3 id="_application_saas">Application SaaS</h3> <div class="imageblock"> <div class="content"> <img src="saas-architecture.svg" alt="saas architecture" width="1756" height="341"> </div> </div> <div class="paragraph"> <p><strong>Verdict</strong> : Architecture hybride nécessaire. Supabase pour l’essentiel, Spring Boot pour la partie critique (paiements, facturation).</p> </div> </div> <div class="sect2"> <h3 id="_e_commerce">E-commerce</h3> <div class="imageblock"> <div class="content"> <img src="ecommerce-architecture.svg" alt="ecommerce architecture" width="1937" height="313"> </div> </div> <div class="paragraph"> <p><strong>Verdict</strong> : Spring Boot indispensable. Supabase pour auth et catalogue uniquement.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_stratégie_de_migration_progressive">Stratégie de Migration Progressive</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="migration-strategy.svg" alt="migration strategy" width="2050" height="954"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_coûts_et_considérations_opérationnelles">Coûts et Considérations Opérationnelles</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_structure_des_coûts">Structure des Coûts</h3> <div class="imageblock"> <div class="content"> <img src="cost-structure.svg" alt="cost structure" width="2139" height="225"> </div> </div> </div> <div class="sect2"> <h3 id="_responsabilités_opérationnelles">Responsabilités Opérationnelles</h3> <div class="imageblock"> <div class="content"> <img src="operational-responsibilities.svg" alt="operational responsibilities" width="1220" height="392"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion_léquilibre_parfait">Conclusion : L’Équilibre Parfait</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’architecture hybride Supabase + Spring Boot n’est pas un compromis, c’est une <strong>synergie</strong>.</p> </div> <div class="sect2"> <h3 id="_les_principes_à_retenir">Les Principes à Retenir</h3> <div class="imageblock"> <div class="content"> <img src="key-principles.svg" alt="key principles" width="581" height="316"> </div> </div> </div> <div class="sect2"> <h3 id="_quand_choisir_cette_architecture">Quand Choisir Cette Architecture ?</h3> <div class="paragraph"> <p><strong>✅ Cette architecture est idéale si :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Vous voulez démarrer rapidement (MVP en jours, pas en mois)</p> </li> <li> <p>Vous anticipez une croissance de la complexité métier</p> </li> <li> <p>Vous voulez minimiser les coûts initiaux</p> </li> <li> <p>Vous aimez PostgreSQL et voulez une source de vérité unique</p> </li> <li> <p>Vous appréciez Kotlin et les Coroutines pour le code métier</p> </li> <li> <p>Vous voulez éviter le vendor lock-in total</p> </li> </ul> </div> <div class="paragraph"> <p><strong>❌ Cette architecture n’est PAS adaptée si :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Votre projet est simple et le restera (blog personnel → 100% Supabase suffit)</p> </li> <li> <p>Vous avez déjà une stack backend établie que vous maîtrisez</p> </li> <li> <p>Vous préférez un monolithe traditionnel</p> </li> <li> <p>Vous avez besoin de .NET, Python, ou autre langage côté backend</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_vision_densemble_finale">Vision d’Ensemble Finale</h3> <div class="imageblock"> <div class="content"> <img src="final-vision.svg" alt="final vision" width="1524" height="497"> </div> </div> </div> <div class="sect2"> <h3 id="_le_meilleur_des_deux_mondes">Le Meilleur des Deux Mondes</h3> <div class="paragraph"> <p>Cette architecture vous donne :</p> </div> <div class="paragraph"> <p><strong>🚀 La Vélocité de Supabase</strong></p> </div> <div class="ulist"> <ul> <li> <p>Démarrage en heures, pas en semaines</p> </li> <li> <p>Authentification OAuth2 en quelques clics</p> </li> <li> <p>APIs REST générées automatiquement</p> </li> <li> <p>Zéro configuration de serveur</p> </li> </ul> </div> <div class="paragraph"> <p><strong>💪 La Puissance de Spring Boot</strong></p> </div> <div class="ulist"> <ul> <li> <p>Kotlin et Coroutines pour code asynchrone élégant</p> </li> <li> <p>Orchestration de processus métier complexes</p> </li> <li> <p>Jobs planifiés fiables</p> </li> <li> <p>Transactions ACID garanties</p> </li> <li> <p>Écosystème Spring complet</p> </li> </ul> </div> <div class="paragraph"> <p><strong>💰 L’Économie Progressive</strong></p> </div> <div class="ulist"> <ul> <li> <p>0€ pour démarrer et valider</p> </li> <li> <p>Coûts qui suivent la croissance</p> </li> <li> <p>Pas de sur-engineering prématuré</p> </li> </ul> </div> <div class="paragraph"> <p><strong>🎯 La Flexibilité Architecturale</strong></p> </div> <div class="ulist"> <ul> <li> <p>Migration progressive sans refonte</p> </li> <li> <p>Ajout de Spring Boot seulement si nécessaire</p> </li> <li> <p>Pas de vendor lock-in total</p> </li> <li> <p>Architecture évolutive</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_pour_aller_plus_loin">Pour Aller Plus Loin</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_ressources_techniques">Ressources Techniques</h3> <div class="paragraph"> <p><strong>Documentation Supabase :</strong></p> </div> <div class="ulist"> <ul> <li> <p><a href="https://supabase.com/docs/guides/auth">Guide d’Authentification</a></p> </li> <li> <p><a href="https://supabase.com/docs/guides/database/postgres/row-level-security">Row Level Security</a></p> </li> <li> <p><a href="https://supabase.com/docs/guides/api">Auto-generated APIs</a></p> </li> </ul> </div> <div class="paragraph"> <p><strong>Documentation Spring Boot :</strong></p> </div> <div class="ulist"> <ul> <li> <p><a href="https://spring.io/guides/tutorials/spring-boot-kotlin/">Spring Boot avec Kotlin</a></p> </li> <li> <p><a href="https://spring.io/blog/2019/04/12/going-reactive-with-spring-coroutines-and-kotlin-flow">Coroutines et Spring</a></p> </li> <li> <p><a href="https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/jwt.html">JWT Resource Server</a></p> </li> </ul> </div> <div class="paragraph"> <p><strong>Articles Complémentaires :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Sécurisation des APIs avec JWT</p> </li> <li> <p>Optimisation des performances PostgreSQL</p> </li> <li> <p>Patterns de migration progressive</p> </li> <li> <p>Gestion des erreurs en architecture distribuée</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_cas_dusage_réels">Cas d’Usage Réels</h3> <div class="paragraph"> <p>Cette architecture hybride est utilisée avec succès dans :</p> </div> <div class="ulist"> <ul> <li> <p><strong>SaaS B2B</strong> : Authentification Supabase, facturation Spring Boot</p> </li> <li> <p><strong>Marketplaces</strong> : Catalogue Supabase, transactions Spring Boot</p> </li> <li> <p><strong>Plateformes de contenu</strong> : Articles Supabase, analytics Spring Boot</p> </li> <li> <p><strong>Outils internes</strong> : CRUD Supabase, workflows Spring Boot</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_checklist_de_démarrage">Checklist de Démarrage</h3> <div class="paragraph"> <p><strong>Phase 1 - Fondations (Semaine 1)</strong></p> </div> <div class="ulist checklist"> <ul class="checklist"> <li> <p><i class="fa fa-square-o"></i> Créer compte Supabase</p> </li> <li> <p><i class="fa fa-square-o"></i> Configurer projet PostgreSQL</p> </li> <li> <p><i class="fa fa-square-o"></i> Activer Auth (Google, GitHub)</p> </li> <li> <p><i class="fa fa-square-o"></i> Définir schéma initial</p> </li> <li> <p><i class="fa fa-square-o"></i> Configurer Row Level Security</p> </li> <li> <p><i class="fa fa-square-o"></i> Tester APIs depuis JBake</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Phase 2 - MVP (Semaine 2-3)</strong></p> </div> <div class="ulist checklist"> <ul class="checklist"> <li> <p><i class="fa fa-square-o"></i> Implémenter pages principales</p> </li> <li> <p><i class="fa fa-square-o"></i> Intégrer authentification OAuth2</p> </li> <li> <p><i class="fa fa-square-o"></i> Créer formulaires CRUD</p> </li> <li> <p><i class="fa fa-square-o"></i> Configurer Storage pour fichiers</p> </li> <li> <p><i class="fa fa-square-o"></i> Déployer sur GitHub Pages</p> </li> <li> <p><i class="fa fa-square-o"></i> Tester en conditions réelles</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Phase 3 - Évolution (Selon besoins)</strong></p> </div> <div class="ulist checklist"> <ul class="checklist"> <li> <p><i class="fa fa-square-o"></i> Identifier besoins de logique complexe</p> </li> <li> <p><i class="fa fa-square-o"></i> Créer projet Spring Boot si nécessaire</p> </li> <li> <p><i class="fa fa-square-o"></i> Configurer validation JWT Supabase</p> </li> <li> <p><i class="fa fa-square-o"></i> Connecter à PostgreSQL Supabase</p> </li> <li> <p><i class="fa fa-square-o"></i> Migrer fonctionnalités complexes</p> </li> <li> <p><i class="fa fa-square-o"></i> Implémenter jobs planifiés</p> </li> <li> <p><i class="fa fa-square-o"></i> Déployer Spring Boot (Cloud Run, etc.)</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_anti_patterns_à_éviter">Anti-Patterns à Éviter</h3> <div class="paragraph"> <p><strong>❌ Ne pas faire :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Dupliquer les données entre Supabase et Spring Boot</p> </li> <li> <p>Créer deux bases PostgreSQL séparées</p> </li> <li> <p>Coder l’authentification vous-même</p> </li> <li> <p>Utiliser Spring Boot pour du CRUD simple</p> </li> <li> <p>Sur-architecturer dès le départ</p> </li> <li> <p>Ignorer Row Level Security de Supabase</p> </li> </ul> </div> <div class="paragraph"> <p><strong>✅ Faire plutôt :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Partager une seule base PostgreSQL</p> </li> <li> <p>Laisser Supabase gérer l’authentification</p> </li> <li> <p>Utiliser Spring Boot seulement pour la complexité</p> </li> <li> <p>Commencer simple, évoluer progressivement</p> </li> <li> <p>Exploiter les forces de chaque technologie</p> </li> <li> <p>Sécuriser avec RLS au niveau base de données</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_perspectives_dévolution">Perspectives d’Évolution</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_ajout_de_nouvelles_capacités">Ajout de Nouvelles Capacités</h3> <div class="imageblock"> <div class="content"> <img src="future-capabilities.svg" alt="future capabilities" width="1998" height="331"> </div> </div> </div> <div class="sect2"> <h3 id="_scaling_horizontal">Scaling Horizontal</h3> <div class="paragraph"> <p>Lorsque votre application grandit, l’architecture hybride scale naturellement :</p> </div> <div class="paragraph"> <p><strong>Supabase :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Scale automatiquement jusqu’à des millions d’opérations</p> </li> <li> <p>Read replicas pour performances lecture</p> </li> <li> <p>Point-in-time recovery pour sécurité</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Spring Boot :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Multiple instances derrière load balancer</p> </li> <li> <p>Stateless design facilite le scaling horizontal</p> </li> <li> <p>Kubernetes pour orchestration si nécessaire</p> </li> </ul> </div> <div class="paragraph"> <p><strong>PostgreSQL :</strong></p> </div> <div class="ulist"> <ul> <li> <p>Partitioning pour tables volumineuses</p> </li> <li> <p>Connection pooling (PgBouncer)</p> </li> <li> <p>Sharding si vraiment nécessaire (rare)</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_témoignages_architecturaux">Témoignages Architecturaux</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_startup_saas_50k_utilisateurs">Startup SaaS (50k utilisateurs)</h3> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Nous avons démarré 100% Supabase. À 5k utilisateurs, nous avons ajouté Spring Boot uniquement pour la facturation Stripe et les rapports mensuels. Un an plus tard, 80% de nos opérations passent toujours par Supabase. Spring Boot gère seulement la partie critique. Cette séparation nous a permis de scaler sans refonte.</p> </div> </blockquote> </div> </div> <div class="sect2"> <h3 id="_plateforme_e_learning_10k_utilisateurs">Plateforme E-learning (10k utilisateurs)</h3> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>L’authentification OAuth2 de Supabase nous a fait gagner 3 semaines de développement. Les APIs auto-générées gèrent tout notre catalogue de cours. Spring Boot ne sert que pour les certificats PDF et les emails de progression. Architecture simple, maintenable, évolutive.</p> </div> </blockquote> </div> </div> <div class="sect2"> <h3 id="_marketplace_b2b_3k_utilisateurs">Marketplace B2B (3k utilisateurs)</h3> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Spring Boot gère les transactions entre acheteurs et vendeurs (critique). Supabase gère tout le reste : profils, messagerie temps réel, documents. Le fait qu’ils partagent la même base PostgreSQL nous évite toute synchronisation complexe. Meilleur choix architectural que nous ayons fait.</p> </div> </blockquote> </div> </div> </div> </div> <div class="sect1"> <h2 id="_synthèse_un_paradigme_architectural_moderne">Synthèse : Un Paradigme Architectural Moderne</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’architecture hybride Supabase + Spring Boot représente un nouveau paradigme : <strong>la spécialisation architecturale</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="paradigm-shift.svg" alt="paradigm shift" width="1058" height="260"> </div> </div> <div class="paragraph"> <p><strong>Le principe fondamental :</strong> Ne construisez pas ce qui existe déjà sous forme de service. Concentrez-vous sur ce qui différencie votre application.</p> </div> <div class="sect2"> <h3 id="_la_règle_des_8020">La Règle des 80/20</h3> <div class="paragraph"> <p>Dans la plupart des applications :</p> </div> <div class="ulist"> <ul> <li> <p><strong>80% des opérations</strong> sont du CRUD standard → Supabase</p> </li> <li> <p><strong>20% des opérations</strong> nécessitent de la logique métier → Spring Boot</p> </li> </ul> </div> <div class="paragraph"> <p>Cette règle naturelle justifie l’architecture hybride.</p> </div> <div class="imageblock"> <div class="content"> <img src="8020-rule.svg" alt="8020 rule" width="1605" height="221"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion_finale">Conclusion Finale</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’architecture hybride n’est pas un compromis technique, c’est une <strong>décision stratégique</strong>.</p> </div> <div class="paragraph"> <p><strong>Elle vous permet de :</strong></p> </div> <div class="ulist"> <ul> <li> <p>✅ Démarrer rapidement avec un MVP fonctionnel</p> </li> <li> <p>✅ Valider votre marché sans investissement lourd</p> </li> <li> <p>✅ Évoluer progressivement quand la complexité l’exige</p> </li> <li> <p>✅ Maîtriser vos coûts à chaque étape</p> </li> <li> <p>✅ Exploiter le meilleur de chaque technologie</p> </li> <li> <p>✅ Éviter le sur-engineering prématuré</p> </li> <li> <p>✅ Conserver la flexibilité pour l’avenir</p> </li> </ul> </div> <div class="paragraph"> <p><strong>Elle représente :</strong></p> </div> <div class="ulist"> <ul> <li> <p>🎯 <strong>Pragmatisme</strong> : Chaque technologie où elle excelle</p> </li> <li> <p>🚀 <strong>Vélocité</strong> : Time-to-market minimal</p> </li> <li> <p>💰 <strong>Économie</strong> : Coûts alignés sur la valeur</p> </li> <li> <p>🔮 <strong>Évolutivité</strong> : Architecture qui grandit avec vous</p> </li> <li> <p>🛡️ <strong>Robustesse</strong> : Services éprouvés et fiables</p> </li> </ul> </div> <div class="sect2"> <h3 id="_votre_prochain_pas">Votre Prochain Pas</h3> <div class="paragraph"> <p>Si cette architecture vous parle, voici par où commencer :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Créez un compte Supabase</strong> (gratuit)</p> </li> <li> <p><strong>Définissez votre schéma de données minimal</strong></p> </li> <li> <p><strong>Configurez l’authentification OAuth2</strong></p> </li> <li> <p><strong>Créez votre première page JBake qui consomme l’API</strong></p> </li> <li> <p><strong>Déployez sur GitHub Pages</strong></p> </li> </ol> </div> <div class="paragraph"> <p>Vous aurez un MVP fonctionnel en <strong>quelques jours</strong>.</p> </div> <div class="paragraph"> <p>Spring Boot viendra naturellement quand vous en aurez besoin. Pas avant.</p> </div> <hr> <div class="paragraph"> <p><strong>L’architecture hybride, c’est l’art de construire exactement ce qu’il faut, quand il faut.</strong></p> </div> <div class="paragraph text-center"> <p><em>Bon développement ! 🚀</em></p> </div> <hr> <div class="paragraph text-center"> <p><em>Partagez cet article si vous pensez qu’il peut aider d’autres développeurs à faire les bons choix architecturaux.</em></p> </div> </div> </div> </div> https://pages-content.github.io//blog/2025/0099_debugging-mockito-gradle-plugin_post.html Mon, 17 Nov 2025 00:00:00 +0000 blog/2025/0099_debugging-mockito-gradle-plugin_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#introduction">1. Introduction</a></li> <li><a href="#le_contexte_plugin_gradle_bakery">2. Le contexte : Plugin Gradle Bakery</a></li> <li><a href="#problème_1_vérifier_le_mauvais_mock">3. Problème #1 : Vérifier le mauvais mock</a> <ul class="sectlevel2"> <li><a href="#le_diagnostic">3.1. Le diagnostic</a></li> <li><a href="#la_solution">3.2. La solution</a></li> </ul> </li> <li><a href="#problème_2_unfinishedstubbingexception_en_cascade">4. Problème #2 : UnfinishedStubbingException en cascade</a> <ul class="sectlevel2"> <li><a href="#le_diagnostic_2">4.1. Le diagnostic</a></li> <li><a href="#la_solution_2">4.2. La solution</a></li> </ul> </li> <li><a href="#problème_3_le_fichier_de_configuration_nexiste_pas">5. Problème #3 : Le fichier de configuration n’existe pas</a> <ul class="sectlevel2"> <li><a href="#le_diagnostic_3">5.1. Le diagnostic</a></li> <li><a href="#la_solution_3">5.2. La solution</a></li> </ul> </li> <li><a href="#problème_4_afterevaluate_et_nullpointerexception">6. Problème #4 : afterEvaluate et NullPointerException</a> <ul class="sectlevel2"> <li><a href="#le_diagnostic_4">6.1. Le diagnostic</a></li> <li><a href="#la_solution_4">6.2. La solution</a></li> </ul> </li> <li><a href="#la_solution_complète">7. La solution complète</a></li> <li><a href="#leçons_apprises">8. Leçons apprises</a> <ul class="sectlevel2"> <li><a href="#1_vérifier_le_bon_mock">8.1. 1. Vérifier le bon mock</a></li> <li><a href="#2_éviter_les_mocks_imbriqués">8.2. 2. Éviter les mocks imbriqués</a></li> <li><a href="#3_mocker_les_callbacks_dévaluation">8.3. 3. Mocker les callbacks d’évaluation</a></li> <li><a href="#4_tester_la_résolution_des_chemins">8.4. 4. Tester la résolution des chemins</a></li> </ul> </li> <li><a href="#architecture_de_test_finale">9. Architecture de test finale</a></li> <li><a href="#conclusion">10. Conclusion</a></li> <li><a href="#ressources">11. Ressources</a></li> </ul> </div> <div class="sect1"> <h2 id="introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Lors du développement du plugin Gradle <strong>Bakery</strong> pour mon blog JBake, j’ai rencontré un problème apparemment simple : un test unitaire qui échouait avec l’erreur <code>Wanted but not invoked</code>. Ce qui semblait être un bug trivial s’est révélé être un cas d’école parfait pour comprendre les subtilités du mocking avec Mockito et Kotlin.</p> </div> <div class="paragraph"> <p>Dans cet article, je vous emmène dans un voyage de debugging méthodique, où chaque solution révèle un nouveau problème, jusqu’à la résolution finale.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_contexte_plugin_gradle_bakery">2. Le contexte : Plugin Gradle Bakery</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le plugin Bakery est un wrapper autour de JBake qui facilite la publication de sites statiques. Voici sa structure simplifiée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class BakeryPlugin : Plugin<Project> { override fun apply(project: Project) { val extension = project.extensions.create( "bakery", BakeryExtension::class.java ) project.afterEvaluate { if (!project.layout.projectDirectory.asFile .resolve(extension.configPath.get()).exists()) { println("config file does not exists") } else { // C'EST ICI QUE ÇA SE PASSE project.plugins.apply(JBakePlugin::class.java) val site = FileSystemManager.from(project, extension.configPath.get()) // Configuration de JBake... } } } }</code></pre> </div> </div> <div class="paragraph"> <p>Le test qui échouait était simple :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `plugin applies jbake gradle plugin`() { val project = createMockProject() val plugin = BakeryPlugin() plugin.apply(project) verify(project.plugins).apply(JBakePlugin::class.java) }</code></pre> </div> </div> <div class="paragraph"> <p>L’erreur :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">Wanted but not invoked: pluginContainer.apply(class org.jbake.gradle.JBakePlugin); Actually, there were zero interactions with this mock.</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="problème_1_vérifier_le_mauvais_mock">3. Problème #1 : Vérifier le mauvais mock</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_diagnostic">3.1. Le diagnostic</h3> <div class="imageblock"> <div class="content"> <img src="./images/mockito-problem-1.svg" alt="mockito problem 1" width="687" height="521"> </div> </div> <div class="paragraph"> <p>Le problème : Mockito ne peut pas tracer les interactions sur <code>project.plugins</code> car ce n’est qu’un getter qui retourne le vrai mock <code>mockPluginContainer</code>. La vérification doit se faire directement sur l’instance du mock.</p> </div> </div> <div class="sect2"> <h3 id="la_solution">3.2. La solution</h3> <div class="paragraph"> <p>Modifier <code>createMockProject()</code> pour retourner les deux objets :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">private fun createMockProject(): Pair<Project, PluginContainer> { val mockPluginContainer = mock<PluginContainer>() val mockProject = mock<Project> { on { plugins } doReturn mockPluginContainer } return Pair(mockProject, mockPluginContainer) }</code></pre> </div> </div> <div class="paragraph"> <p>Et adapter le test :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `plugin applies jbake gradle plugin`() { val (project, mockPluginContainer) = createMockProject() val plugin = BakeryPlugin() plugin.apply(project) // ✅ Vérification directe sur le bon mock verify(mockPluginContainer).apply(JBakePlugin::class.java) }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="problème_2_unfinishedstubbingexception_en_cascade">4. Problème #2 : UnfinishedStubbingException en cascade</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_diagnostic_2">4.1. Le diagnostic</h3> <div class="paragraph"> <p>Une fois la première correction appliquée, une nouvelle erreur est apparue :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">UnfinishedStubbingException: Unfinished stubbing detected here Hints: 3. you are stubbing the behaviour of another mock inside before 'thenReturn' instruction is completed</code></pre> </div> </div> <div class="paragraph"> <p>Le code problématique utilisait la syntaxe DSL de Mockito-Kotlin :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">val mockProject = mock<Project> { on { extensions } doReturn mockExtensionContainer on { plugins } doReturn mockPluginContainer on { logger } doReturn mock() // ❌ PROBLÈME ICI ! }</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/mockito-problem-2.svg" alt="mockito problem 2" width="690" height="316"> </div> </div> </div> <div class="sect2"> <h3 id="la_solution_2">4.2. La solution</h3> <div class="paragraph"> <p>Créer <strong>tous</strong> les mocks en dehors de tout bloc de stubbing, puis les configurer avec <code>whenever()</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">private fun createMockProject(): Pair<Project, PluginContainer> { // 1️⃣ Créer TOUS les mocks d'abord val mockPluginContainer = mock<PluginContainer>() val mockExtensionContainer = mock<ExtensionContainer>() val mockLogger = mock<org.gradle.api.logging.Logger>() val mockProject = mock<Project>() // 2️⃣ Configurer les mocks séparément avec whenever() whenever(mockProject.plugins).thenReturn(mockPluginContainer) whenever(mockProject.extensions).thenReturn(mockExtensionContainer) whenever(mockProject.logger).thenReturn(mockLogger) return Pair(mockProject, mockPluginContainer) }</code></pre> </div> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="Tip"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Règle d’or</strong> : Ne jamais appeler <code>mock()</code> à l’intérieur d’un bloc de configuration de mock. Toujours créer les mocks en premier, puis les configurer.</p> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="problème_3_le_fichier_de_configuration_nexiste_pas">5. Problème #3 : Le fichier de configuration n’existe pas</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_diagnostic_3">5.1. Le diagnostic</h3> <div class="paragraph"> <p>Même avec les mocks corrects, le test échouait toujours car le plugin ne trouvait pas le fichier de configuration :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// Dans BakeryPlugin.kt if (!project.layout.projectDirectory.asFile .resolve(extension.configPath.get()).exists()) { println("config file does not exists") return@afterEvaluate // ❌ Sort avant d'appliquer JBake ! }</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/mockito-problem-3.svg" alt="mockito problem 3" width="530" height="373"> </div> </div> </div> <div class="sect2"> <h3 id="la_solution_3">5.2. La solution</h3> <div class="paragraph"> <p>Configurer les mocks pour que la résolution du chemin fonctionne :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">private fun createMockProject(): Pair<Project, PluginContainer> { // ... autres mocks ... val configFile = File("../../site.yml").canonicalFile val projectDir = configFile.parentFile // Configuration cohérente des chemins whenever(mockConfigPathProperty.get()).thenReturn("site.yml") whenever(mockProjectDirectory.asFile).thenReturn(projectDir) // Maintenant : projectDir.resolve("site.yml") existe ! ✅ }</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/path-resolution.svg" alt="path resolution" width="604" height="189"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="problème_4_afterevaluate_et_nullpointerexception">6. Problème #4 : afterEvaluate et NullPointerException</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_diagnostic_4">6.1. Le diagnostic</h3> <div class="paragraph"> <p>Le plugin applique JBake dans un bloc <code>afterEvaluate</code>, et accède à <code>buildDirectory.dir()</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">project.afterEvaluate { // ... project.tasks.withType(JBakeTask::class.java) .getByName("bake").apply { output = project.layout.buildDirectory .dir(site.bake.destDirPath) // ❌ NPE ici ! .get() .asFile } }</code></pre> </div> </div> <div class="paragraph"> <p>Le mock de <code>buildDirectory.dir()</code> retournait <code>null</code>.</p> </div> </div> <div class="sect2"> <h3 id="la_solution_4">6.2. La solution</h3> <div class="paragraph"> <p>Mocker <code>afterEvaluate</code> pour qu’il s’exécute immédiatement, et configurer complètement <code>buildDirectory</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">private fun createMockProject(): Pair<Project, PluginContainer> { // ... autres mocks ... val mockBuildDirectory = mock<DirectoryProperty>() val buildDir = File(projectDir, "build") // Mocker dir() pour retourner un Provider valide whenever(mockBuildDirectory.dir(any<String>())).doAnswer { invocation -> val path = invocation.arguments[0] as String val mockDirProvider = mock<Provider<Directory>>() val mockDir = mock<Directory>() whenever(mockDir.asFile).thenReturn(File(buildDir, path)) whenever(mockDirProvider.get()).thenReturn(mockDir) mockDirProvider } // Mocker afterEvaluate pour exécution immédiate whenever(mockProject.afterEvaluate(any<Action<Project>>())).doAnswer { invocation -> val action = invocation.arguments[0] as Action<Project> action.execute(mockProject) // ✅ Exécution synchrone null } return Pair(mockProject, mockPluginContainer) }</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/after-evaluate-flow.svg" alt="after evaluate flow" width="777" height="357"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_complète">7. La solution complète</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici la fonction <code>createMockProject()</code> finale, qui résout tous les problèmes :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">private fun createMockProject(): Pair<Project, PluginContainer> { // 1️⃣ CRÉER tous les mocks (pas de nested mocks !) val mockPluginContainer = mock<PluginContainer>() val mockExtensionContainer = mock<ExtensionContainer>() val mockLogger = mock<org.gradle.api.logging.Logger>() val mockTaskContainer = mock<TaskContainer>() val mockConfigPathProperty = mock<Property<String>>() val mockBakeryExtension = mock<BakeryExtension>() val mockProjectDirectory = mock<Directory>() val mockBuildDirectory = mock<DirectoryProperty>() val mockProjectLayout = mock<ProjectLayout>() val mockProject = mock<Project>() // 2️⃣ CONFIGURER la résolution des chemins val configFile = File("../../site.yml").canonicalFile val projectDir = configFile.parentFile val buildDir = File(projectDir, "build") whenever(mockConfigPathProperty.get()).thenReturn("site.yml") whenever(mockConfigPathProperty.isPresent).thenReturn(true) whenever(mockBakeryExtension.configPath).thenReturn(mockConfigPathProperty) whenever(mockProjectDirectory.asFile).thenReturn(projectDir) // 3️⃣ CONFIGURER buildDirectory avec dir() whenever(mockBuildDirectory.dir(any<String>())).doAnswer { invocation -> val path = invocation.arguments[0] as String val mockDirProvider = mock<Provider<Directory>>() val mockDir = mock<Directory>() whenever(mockDir.asFile).thenReturn(File(buildDir, path)) whenever(mockDirProvider.get()).thenReturn(mockDir) mockDirProvider } // 4️⃣ ASSEMBLER le projet whenever(mockProjectLayout.projectDirectory).thenReturn(mockProjectDirectory) whenever(mockProjectLayout.buildDirectory).thenReturn(mockBuildDirectory) whenever(mockExtensionContainer.create("bakery", BakeryExtension::class.java)) .thenReturn(mockBakeryExtension) whenever(mockExtensionContainer.getByType(BakeryExtension::class.java)) .thenReturn(mockBakeryExtension) whenever(mockProject.extensions).thenReturn(mockExtensionContainer) whenever(mockProject.plugins).thenReturn(mockPluginContainer) whenever(mockProject.tasks).thenReturn(mockTaskContainer) whenever(mockProject.layout).thenReturn(mockProjectLayout) whenever(mockProject.logger).thenReturn(mockLogger) whenever(mockProject.projectDir).thenReturn(projectDir) // 5️⃣ CONFIGURER afterEvaluate pour exécution immédiate whenever(mockProject.afterEvaluate(any<Action<Project>>())).doAnswer { invocation -> val action = invocation.arguments[0] as Action<Project> action.execute(mockProject) null } return Pair(mockProject, mockPluginContainer) }</code></pre> </div> </div> <div class="paragraph"> <p>Et le test final qui passe :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `plugin applies jbake gradle plugin`() { val (project, mockPluginContainer) = createMockProject() val plugin = BakeryPlugin() plugin.apply(project) verify(mockPluginContainer).apply(JBakePlugin::class.java) // ✅ SUCCÈS ! }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="leçons_apprises">8. Leçons apprises</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/lessons-learned.svg" alt="lessons learned" width="748" height="472"> </div> </div> <div class="sect2"> <h3 id="1_vérifier_le_bon_mock">8.1. 1. Vérifier le bon mock</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// ❌ FAUX verify(project.plugins).apply(JBakePlugin::class.java) // ✅ CORRECT val (project, mockPluginContainer) = createMockProject() verify(mockPluginContainer).apply(JBakePlugin::class.java)</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="2_éviter_les_mocks_imbriqués">8.2. 2. Éviter les mocks imbriqués</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// ❌ FAUX - UnfinishedStubbingException val mockProject = mock<Project> { on { logger } doReturn mock() // Nested mock creation ! } // ✅ CORRECT - Créer séparément val mockLogger = mock<org.gradle.api.logging.Logger>() val mockProject = mock<Project>() whenever(mockProject.logger).thenReturn(mockLogger)</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="3_mocker_les_callbacks_dévaluation">8.3. 3. Mocker les callbacks d’évaluation</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// ✅ afterEvaluate doit s'exécuter pour les tests whenever(mockProject.afterEvaluate(any())).doAnswer { invocation -> val action = invocation.arguments[0] as Action<Project> action.execute(mockProject) null }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="4_tester_la_résolution_des_chemins">8.4. 4. Tester la résolution des chemins</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// Toujours vérifier que les chemins se résolvent correctement val extension = project.extensions.getByType(BakeryExtension::class.java) val configPath = extension.configPath.get() val projectDir = project.layout.projectDirectory.asFile val resolvedConfig = projectDir.resolve(configPath) println("Resolved config: ${resolvedConfig.absolutePath}") println("Exists: ${resolvedConfig.exists()}")</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="architecture_de_test_finale">9. Architecture de test finale</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/test-architecture.svg" alt="test architecture" width="707" height="598"> </div> </div> </div> </div> <div class="sect1"> <h2 id="conclusion">10. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce qui semblait être un simple problème de test s’est révélé être un excellent cas d’étude sur :</p> </div> <div class="ulist"> <ul> <li> <p>Les subtilités de Mockito avec Kotlin</p> </li> <li> <p>L’importance de mocker les bons objets</p> </li> <li> <p>La gestion des callbacks asynchrones dans les tests</p> </li> <li> <p>La résolution de chemins dans les plugins Gradle</p> </li> </ul> </div> <div class="paragraph"> <p>Le debugging méthodique, en comprenant chaque couche du problème, a permis d’arriver à une solution robuste et maintenable.</p> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="Tip"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Conseil pour vos tests</strong> : Si vous rencontrez "Wanted but not invoked" avec Mockito, demandez-vous toujours :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Est-ce que je vérifie le bon mock ?</p> </li> <li> <p>Est-ce que tous mes mocks sont créés en dehors des blocs de configuration ?</p> </li> <li> <p>Est-ce que mes callbacks s’exécutent vraiment ?</p> </li> <li> <p>Est-ce que mes chemins se résolvent correctement ?</p> </li> </ol> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="ressources">11. Ressources</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://github.com/mockito/mockito-kotlin">Mockito-Kotlin Documentation</a></p> </li> <li> <p><a href="https://docs.gradle.org/current/userguide/custom_plugins.html">Gradle Plugin Development Guide</a></p> </li> <li> <p><a href="https://jbake.org/">JBake Static Site Generator</a></p> </li> </ul> </div> <hr> <div class="paragraph"> <p><em>Avez-vous rencontré des problèmes similaires dans vos tests ? Partagez votre expérience dans les commentaires !</em></p> </div> </div> </div> https://pages-content.github.io//blog/2025/0098_preloading_css_variable_post.html Sat, 15 Nov 2025 00:00:00 +0000 blog/2025/0098_preloading_css_variable_post.html <div id="toc" class="toc"> <div id="toctitle">Table des matières</div> <ul class="sectlevel1"> <li><a href="#résumé">Résumé</a></li> <li><a href="#le_problème_ce_maudit_clignotement_de_thème">1. Le Problème : Ce Maudit Clignotement de Thème</a> <ul class="sectlevel2"> <li><a href="#un_cauchemar_pour_lexpérience_utilisateur">1.1. Un Cauchemar pour l’Expérience Utilisateur</a></li> <li><a href="#le_fouc_un_vieux_problème_web">1.2. Le FOUC : Un Vieux Problème Web</a></li> <li><a href="#impact_sur_la_perception_de_qualité">1.3. Impact sur la Perception de Qualité</a></li> <li><a href="#analyse_technique_du_problème">1.4. Analyse Technique du Problème</a></li> </ul> </li> <li><a href="#pourquoi_un_script_classique_ne_suffit_pas">2. Pourquoi un Script Classique ne Suffit Pas ?</a> <ul class="sectlevel2"> <li><a href="#lapproche_intuitive_mais_inefficace">2.1. L’Approche Intuitive mais Inefficace</a></li> <li><a href="#comprendre_lévénement_domcontentloaded">2.2. Comprendre l’Événement DOMContentLoaded</a></li> <li><a href="#le_problème_du_render_blocking">2.3. Le Problème du Render Blocking</a></li> <li><a href="#visualisation_du_problème">2.4. Visualisation du Problème</a></li> <li><a href="#les_tentatives_de_solution_inefficaces">2.5. Les Tentatives de Solution Inefficaces</a></li> <li><a href="#la_vraie_solution_agir_plus_tôt">2.6. La Vraie Solution : Agir Plus Tôt</a></li> </ul> </li> <li><a href="#la_solution_le_chargement_précoce_early_loading">3. La Solution : Le Chargement Précoce (Early Loading)</a> <ul class="sectlevel2"> <li><a href="#le_principe_fondamental">3.1. Le Principe Fondamental</a></li> <li><a href="#pourquoi_le_head_est_lendroit_idéal">3.2. Pourquoi le <code><head></code> est l’Endroit Idéal</a></li> <li><a href="#architecture_de_la_solution_en_trois_couches">3.3. Architecture de la Solution en Trois Couches</a></li> </ul> </li> <li><a href="#étape_1_sauvegarder_le_choix_de_lutilisateur">4. Étape 1 : Sauvegarder le Choix de l’Utilisateur</a> <ul class="sectlevel2"> <li><a href="#le_localstorage_votre_mémoire_persistante">4.1. Le localStorage : Votre Mémoire Persistante</a></li> <li><a href="#implémentation_de_la_sauvegarde_du_thème">4.2. Implémentation de la Sauvegarde du Thème</a></li> <li><a href="#gestion_des_cas_derreur">4.3. Gestion des Cas d’Erreur</a></li> <li><a href="#stratégies_avancées_de_persistance">4.4. Stratégies Avancées de Persistance</a></li> </ul> </li> <li><a href="#étape_2_le_script_de_pré_chargement_dans_le_head">5. Étape 2 : Le Script de Pré-chargement dans le <code><head></code></a> <ul class="sectlevel2"> <li><a href="#le_cœur_de_la_solution">5.1. Le Cœur de la Solution</a></li> <li><a href="#anatomie_du_script_chaque_ligne_compte">5.2. Anatomie du Script : Chaque Ligne Compte</a></li> <li><a href="#détection_de_la_préférence_système_bonus">5.3. Détection de la Préférence Système (Bonus)</a></li> <li><a href="#performance_pourquoi_ce_script_est_rapide">5.4. Performance : Pourquoi ce Script est Rapide</a></li> <li><a href="#placement_optimal_dans_le_head">5.5. Placement Optimal dans le <code><head></code></a></li> </ul> </li> <li><a href="#étape_3_la_puissance_des_sélecteurs_dattributs_css">6. Étape 3 : La Puissance des Sélecteurs d’Attributs CSS</a> <ul class="sectlevel2"> <li><a href="#le_système_de_thème_de_bootstrap_5">6.1. Le Système de Thème de Bootstrap 5</a></li> <li><a href="#structure_css_pour_un_système_de_thème">6.2. Structure CSS pour un Système de Thème</a></li> </ul> </li> </ul> </div> <div class="sect1"> <h2 id="résumé">Résumé</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans cet article technique approfondi, nous explorons comment implémenter un sélecteur de thème (light/dark) sans le désagréable effet de clignotement qui survient lors du chargement de page. Nous analysons en détail le cycle de rendu du navigateur, les causes profondes du FOUC (Flash of Unstyled Content), et proposons une solution robuste basée sur le pré-chargement synchrone dans le <code><head></code>. Cette technique garantit une expérience utilisateur fluide et professionnelle.</p> </div> </div> </div> <div class="sect1"> <h2 id="le_problème_ce_maudit_clignotement_de_thème">1. Le Problème : Ce Maudit Clignotement de Thème</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="un_cauchemar_pour_lexpérience_utilisateur">1.1. Un Cauchemar pour l’Expérience Utilisateur</h3> <div class="paragraph"> <p>Imaginez la scène : vous avez passé des heures à concevoir un magnifique thème sombre pour votre application web. Les couleurs sont parfaitement équilibrées, le contraste est optimal, et vos utilisateurs adorent cette option. Mais il y a un problème embarrassant : à chaque rechargement de page, pendant une fraction de seconde, le thème clair par défaut s’affiche avant que le thème sombre ne prenne le relais.</p> </div> <div class="paragraph"> <p>Ce "flash" visuel, bien que bref (parfois moins de 100ms), est immédiatement perceptible par l’œil humain et crée une expérience désagréable. Pour les utilisateurs qui ont choisi le thème sombre pour des raisons de confort visuel ou d’accessibilité, ce clignotement peut même être douloureux, particulièrement dans un environnement peu éclairé.</p> </div> </div> <div class="sect2"> <h3 id="le_fouc_un_vieux_problème_web">1.2. Le FOUC : Un Vieux Problème Web</h3> <div class="paragraph"> <p>Ce phénomène est une variante de ce que l’on appelle le "Flash of Unstyled Content" (FOUC), un problème classique du développement web qui remonte aux premiers jours du CSS. Le FOUC se produit lorsque le navigateur affiche temporairement du contenu HTML sans ses styles CSS appliqués, créant un flash de contenu non stylisé.</p> </div> <div class="paragraph"> <p>Dans notre cas spécifique, nous ne parlons pas d’un contenu complètement non stylisé, mais plutôt d’un <strong>Flash of Wrong Theme</strong> (FOWT) - le contenu est stylisé, mais avec le mauvais thème. C’est particulièrement frustrant car cela montre que notre application "oublie" la préférence de l’utilisateur à chaque chargement de page.</p> </div> </div> <div class="sect2"> <h3 id="impact_sur_la_perception_de_qualité">1.3. Impact sur la Perception de Qualité</h3> <div class="paragraph"> <p>Ce problème, bien que technique, a des répercussions importantes sur la perception de la qualité de votre application :</p> </div> <div class="paragraph"> <p><strong>Manque de polish</strong> : Le clignotement donne l’impression d’une application inachevée ou mal optimisée. Les utilisateurs associent souvent ces petits défauts visuels à un manque de professionnalisme général.</p> </div> <div class="paragraph"> <p><strong>Rupture de cohérence</strong> : L’application semble "oublier" les préférences de l’utilisateur, créant une sensation de désynchronisation entre l’interface et les attentes.</p> </div> <div class="paragraph"> <p><strong>Fatigue visuelle</strong> : Pour les utilisateurs sensibles à la lumière ou souffrant de migraines, ce flash lumineux peut être plus qu’un simple désagrément esthétique.</p> </div> <div class="paragraph"> <p><strong>Performance perçue</strong> : Ironiquement, même si votre site se charge rapidement, ce clignotement peut donner l’impression d’une application lente ou peu réactive.</p> </div> </div> <div class="sect2"> <h3 id="analyse_technique_du_problème">1.4. Analyse Technique du Problème</h3> <div class="paragraph"> <p>Pour comprendre comment résoudre ce problème, il faut d’abord comprendre pourquoi il se produit. Le clignotement survient à cause d’un décalage temporel entre trois événements critiques dans le cycle de vie d’une page web :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Le parsing initial du HTML</strong> : Le navigateur lit et analyse la structure de votre page</p> </li> <li> <p><strong>L’application des styles CSS</strong> : Le navigateur applique les règles CSS et calcule le rendu visuel</p> </li> <li> <p><strong>L’exécution du JavaScript</strong> : Votre code qui change le thème s’exécute</p> </li> </ol> </div> <div class="paragraph"> <p>Le problème survient lorsque l’événement n°3 (exécution du JavaScript) arrive après que le navigateur a déjà commencé ou terminé l’événement n°2 (application des styles). À ce moment-là, le navigateur a déjà pris une décision sur quel thème afficher, et votre code arrive trop tard pour l’influencer avant le premier rendu.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="pourquoi_un_script_classique_ne_suffit_pas">2. Pourquoi un Script Classique ne Suffit Pas ?</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="lapproche_intuitive_mais_inefficace">2.1. L’Approche Intuitive mais Inefficace</h3> <div class="paragraph"> <p>L’approche la plus naturelle pour un développeur serait de placer un script à la fin de notre <code><body></code> qui vérifie le thème préféré de l’utilisateur et l’applique. Cette approche suit les meilleures pratiques traditionnelles du web qui recommandent de charger les scripts en fin de page pour ne pas bloquer le rendu.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">// À la fin de <body> - L'APPROCHE INSUFFISANTE document.addEventListener('DOMContentLoaded', () => { const theme = localStorage.getItem('preferred-theme'); if (theme === 'dark') { document.documentElement.setAttribute('data-bs-theme', 'dark'); } });</code></pre> </div> </div> <div class="paragraph"> <p>Cette approche semble logique à première vue. Nous attendons que le DOM soit prêt, puis nous appliquons le thème. Simple, non ? Malheureusement, cette simplicité cache un défaut fondamental lié au timing du cycle de rendu du navigateur.</p> </div> </div> <div class="sect2"> <h3 id="comprendre_lévénement_domcontentloaded">2.2. Comprendre l’Événement DOMContentLoaded</h3> <div class="paragraph"> <p>L’événement <code>DOMContentLoaded</code> se déclenche lorsque le document HTML initial a été complètement chargé et analysé par le navigateur, <strong>sans attendre</strong> la fin du chargement des feuilles de style, des images et des sous-cadres. C’est un point important à comprendre.</p> </div> <div class="paragraph"> <p>Voici la séquence typique des événements :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Le navigateur commence à télécharger le HTML</p> </li> <li> <p>Il analyse le HTML au fur et à mesure de sa réception</p> </li> <li> <p>Il découvre les balises <code><link></code> pour les CSS et commence à les télécharger</p> </li> <li> <p>Il découvre les balises <code><script></code> et les exécute (selon leur type et attributs)</p> </li> <li> <p>Il construit le DOM (Document Object Model)</p> </li> <li> <p><strong>L’événement <code>DOMContentLoaded</code> se déclenche</strong></p> </li> <li> <p>Il continue d’appliquer les styles et de faire le layout</p> </li> <li> <p>Le premier paint (affichage) se produit</p> </li> <li> <p>L’événement <code>load</code> se déclenche quand toutes les ressources sont chargées</p> </li> </ol> </div> <div class="paragraph"> <p>Le problème ? Entre l’étape 6 (DOMContentLoaded) et l’étape 8 (premier paint), le navigateur a déjà pris des décisions sur comment afficher la page. Si votre script de changement de thème s’exécute à l’étape 6, il est déjà trop tard pour éviter un premier affichage avec les styles par défaut.</p> </div> </div> <div class="sect2"> <h3 id="le_problème_du_render_blocking">2.3. Le Problème du Render Blocking</h3> <div class="paragraph"> <p>En réalité, le timing est encore plus complexe. Les navigateurs modernes utilisent des techniques d’optimisation sophistiquées pour améliorer la performance perçue. Ils essaient de faire le premier paint (First Contentful Paint) le plus rapidement possible pour que l’utilisateur voie quelque chose à l’écran.</p> </div> <div class="paragraph"> <p>Les CSS sont "render-blocking" par défaut, ce qui signifie que le navigateur attend d’avoir téléchargé et parsé les feuilles de style avant de faire le premier paint. C’est logique : on ne veut pas afficher du contenu non stylisé.</p> </div> <div class="paragraph"> <p>Mais voici le piège : quand le navigateur applique ces styles CSS pour la première fois, il le fait en se basant sur l’état actuel du DOM. Si l’attribut <code>data-bs-theme</code> n’est pas encore défini sur la balise <code><html></code>, le navigateur appliquera les styles par défaut (généralement le thème clair).</p> </div> <div class="paragraph"> <p>Ensuite, quand votre script s’exécute et change cet attribut, le navigateur doit :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Recalculer tous les styles affectés par ce changement</p> </li> <li> <p>Refaire le layout si nécessaire</p> </li> <li> <p>Repeindre les éléments affectés</p> </li> </ol> </div> <div class="paragraph"> <p>Ce processus de recalcul et de repeinture est ce qui cause le clignotement visible.</p> </div> </div> <div class="sect2"> <h3 id="visualisation_du_problème">2.4. Visualisation du Problème</h3> <div class="paragraph"> <p>Pour mieux comprendre cette séquence problématique, examinons un diagramme de séquence détaillé :</p> </div> <div id="diag-flux-incorrect" class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-4cecab2bd5c378c47b8154389dfa0d84.svg" alt="Diagramme de séquence du chargement incorrect" width="1488" height="666"> </div> </div> <div class="paragraph"> <p>Ce diagramme illustre clairement le problème : le premier paint se produit avant que notre script n’ait eu la chance de définir le bon thème. Le repaint subséquent crée le clignotement visible.</p> </div> </div> <div class="sect2"> <h3 id="les_tentatives_de_solution_inefficaces">2.5. Les Tentatives de Solution Inefficaces</h3> <div class="paragraph"> <p>Plusieurs approches ont été tentées pour résoudre ce problème, mais la plupart ont leurs propres inconvénients :</p> </div> <div class="paragraph"> <p><strong>Approche 1 : Cacher le contenu jusqu’au chargement</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">body { opacity: 0; transition: opacity 0.3s; } body.loaded { opacity: 1; }</code></pre> </div> </div> <div class="paragraph"> <p>Cette approche cache tout le contenu jusqu’à ce que le JavaScript ait défini le bon thème. Le problème ? Cela retarde artificiellement l’affichage du contenu, donnant l’impression d’un site plus lent. De plus, si JavaScript est désactivé, l’utilisateur ne voit rien du tout !</p> </div> <div class="paragraph"> <p><strong>Approche 2 : Utiliser un loader/spinner</strong></p> </div> <div class="paragraph"> <p>Similaire à l’approche 1, mais avec un spinner de chargement. Cela masque le problème mais n’améliore pas la performance réelle et ajoute un délai perçu inutile.</p> </div> <div class="paragraph"> <p><strong>Approche 3 : Défaut au thème sombre</strong></p> </div> <div class="paragraph"> <p>Certains développeurs définissent le thème sombre comme défaut dans le CSS. Cela évite le clignotement pour les utilisateurs du thème sombre, mais crée le problème inverse pour les utilisateurs du thème clair !</p> </div> <div class="paragraph"> <p>Aucune de ces approches n’est satisfaisante car elles traitent le symptôme plutôt que la cause racine du problème.</p> </div> </div> <div class="sect2"> <h3 id="la_vraie_solution_agir_plus_tôt">2.6. La Vraie Solution : Agir Plus Tôt</h3> <div class="paragraph"> <p>La clé pour résoudre ce problème est de réaliser que nous devons définir l’attribut <code>data-bs-theme</code> <strong>avant</strong> que le navigateur ne commence à appliquer les styles CSS. Cela signifie que notre script doit s’exécuter plus tôt dans le cycle de vie de la page, et c’est exactement ce que nous allons explorer dans la section suivante.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_le_chargement_précoce_early_loading">3. La Solution : Le Chargement Précoce (Early Loading)</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_principe_fondamental">3.1. Le Principe Fondamental</h3> <div class="paragraph"> <p>La solution élégante à notre problème de clignotement repose sur un principe simple mais puissant : <strong>synchroniser l’état de l’application avec le processus de rendu du navigateur</strong>. Au lieu d’attendre que la page soit chargée pour définir le thème, nous devons le définir <strong>pendant</strong> le chargement, avant même que les styles CSS ne soient appliqués.</p> </div> <div class="paragraph"> <p>Cette approche s’appelle le "Early Loading" ou "Synchronous Preloading" dans le jargon du développement web. L’idée est d’exécuter notre logique de détection de thème le plus tôt possible dans le cycle de vie de la page, idéalement dans la balise <code><head></code>, avant même que le navigateur ne commence à télécharger les fichiers CSS.</p> </div> </div> <div class="sect2"> <h3 id="pourquoi_le_head_est_lendroit_idéal">3.2. Pourquoi le <code><head></code> est l’Endroit Idéal</h3> <div class="paragraph"> <p>Le <code><head></code> d’un document HTML est traité séquentiellement par le navigateur, de haut en bas. Chaque élément est traité dans l’ordre où il apparaît. Cette caractéristique est cruciale pour notre solution.</p> </div> <div class="paragraph"> <p>Lorsque le navigateur rencontre une balise <code><script></code> dans le <code><head></code> sans les attributs <code>async</code> ou <code>defer</code>, il :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Interrompt le parsing du HTML</strong></p> </li> <li> <p><strong>Télécharge le script</strong> (si externe) ou le lit (si inline)</p> </li> <li> <p><strong>Exécute immédiatement le script</strong></p> </li> <li> <p><strong>Reprend le parsing du HTML</strong></p> </li> </ol> </div> <div class="paragraph"> <p>Ce comportement, souvent considéré comme un problème de performance (d’où la recommandation habituelle de placer les scripts en fin de page), devient notre allié dans ce cas précis. En plaçant notre script de détection de thème au début du <code><head></code>, nous garantissons qu’il s’exécute avant que le navigateur ne rencontre les balises <code><link></code> de nos feuilles de style.</p> </div> </div> <div class="sect2"> <h3 id="architecture_de_la_solution_en_trois_couches">3.3. Architecture de la Solution en Trois Couches</h3> <div class="paragraph"> <p>Notre solution complète se compose de trois couches interdépendantes, chacune jouant un rôle spécifique :</p> </div> <div class="paragraph"> <p><strong>Couche 1 : Persistence (localStorage)</strong> Cette couche est responsable de la sauvegarde et de la récupération du choix de l’utilisateur entre les sessions.</p> </div> <div class="paragraph"> <p><strong>Couche 2 : Synchronisation Précoce (Script inline dans <code><head></code>)</strong> Cette couche synchronise l’état de l’application avec le DOM avant le rendu initial.</p> </div> <div class="paragraph"> <p><strong>Couche 3 : Styles Réactifs (CSS avec sélecteurs d’attributs)</strong> Cette couche définit les styles visuels basés sur l’état défini par la couche 2.</p> </div> <div class="paragraph"> <p>Explorons maintenant chaque couche en détail.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="étape_1_sauvegarder_le_choix_de_lutilisateur">4. Étape 1 : Sauvegarder le Choix de l’Utilisateur</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_localstorage_votre_mémoire_persistante">4.1. Le localStorage : Votre Mémoire Persistante</h3> <div class="paragraph"> <p>Le <code>localStorage</code> est une API Web Storage qui permet de stocker des paires clé-valeur dans le navigateur de manière persistante. Contrairement aux cookies, les données du <code>localStorage</code> :</p> </div> <div class="ulist"> <ul> <li> <p>Ne sont jamais envoyées au serveur automatiquement</p> </li> <li> <p>Ont une capacité de stockage plus importante (généralement 5-10MB)</p> </li> <li> <p>N’ont pas de date d’expiration (persistent jusqu’à suppression explicite)</p> </li> <li> <p>Sont limitées au protocole et au domaine (Same-Origin Policy)</p> </li> </ul> </div> <div class="paragraph"> <p>Pour notre cas d’usage, le <code>localStorage</code> est parfait car :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Nous n’avons pas besoin de partager cette information avec le serveur</p> </li> <li> <p>Nous voulons que la préférence persiste indéfiniment</p> </li> <li> <p>La taille de stockage requise est minime (quelques octets)</p> </li> </ol> </div> </div> <div class="sect2"> <h3 id="implémentation_de_la_sauvegarde_du_thème">4.2. Implémentation de la Sauvegarde du Thème</h3> <div class="paragraph"> <p>Voici comment nous sauvegardons le choix de l’utilisateur lorsqu’il change de thème :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">// Fonction complète pour changer le thème function setTheme(newTheme) { // Validation de l'entrée if (!['light', 'dark', 'auto'].includes(newTheme)) { console.error('Thème invalide:', newTheme); return; } try { // Sauvegarde dans localStorage localStorage.setItem('preferred-theme', newTheme); // Application immédiate dans le DOM document.documentElement.setAttribute('data-bs-theme', newTheme); // Dispatch d'un événement personnalisé pour notifier d'autres composants window.dispatchEvent(new CustomEvent('theme-changed', { detail: { theme: newTheme } })); console.log('Thème changé:', newTheme); } catch (error) { console.error('Erreur lors de la sauvegarde du thème:', error); // Fallback : on applique quand même le thème visuellement document.documentElement.setAttribute('data-bs-theme', newTheme); } } // Exemple d'utilisation avec un bouton document.getElementById('theme-toggle').addEventListener('click', () => { const currentTheme = document.documentElement.getAttribute('data-bs-theme') || 'light'; const newTheme = currentTheme === 'light' ? 'dark' : 'light'; setTheme(newTheme); });</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="gestion_des_cas_derreur">4.3. Gestion des Cas d’Erreur</h3> <div class="paragraph"> <p>Il est crucial de gérer les cas où le <code>localStorage</code> n’est pas disponible ou accessible. Plusieurs scénarios peuvent empêcher l’accès au <code>localStorage</code> :</p> </div> <div class="paragraph"> <p><strong>Navigation privée stricte</strong> : Safari en mode navigation privée lève une exception <code>QuotaExceededError</code> lors de tentatives d’écriture dans le <code>localStorage</code>.</p> </div> <div class="paragraph"> <p><strong>Paramètres de confidentialité</strong> : Certains navigateurs ou extensions de confidentialité peuvent bloquer l’accès au <code>localStorage</code>.</p> </div> <div class="paragraph"> <p><strong>Limitations de domaine</strong> : Le <code>localStorage</code> n’est pas accessible sur le protocole <code>file://</code> dans certains navigateurs.</p> </div> <div class="paragraph"> <p><strong>Espace de stockage saturé</strong> : Bien que rare, l’espace de stockage peut être complètement rempli.</p> </div> <div class="paragraph"> <p>C’est pourquoi notre code utilise un bloc <code>try…​catch</code> pour gérer ces cas gracieusement, en continuant d’offrir la fonctionnalité de changement de thème même si la persistance n’est pas disponible.</p> </div> </div> <div class="sect2"> <h3 id="stratégies_avancées_de_persistance">4.4. Stratégies Avancées de Persistance</h3> <div class="paragraph"> <p>Pour des applications plus sophistiquées, vous pouvez envisager des stratégies supplémentaires :</p> </div> <div class="paragraph"> <p><strong>Synchronisation serveur (optionnelle)</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">async function setTheme(newTheme) { // Sauvegarde locale immédiate localStorage.setItem('preferred-theme', newTheme); document.documentElement.setAttribute('data-bs-theme', newTheme); // Synchronisation serveur en arrière-plan (si l'utilisateur est connecté) if (userIsAuthenticated()) { try { await fetch('/api/user/preferences', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ theme: newTheme }) }); } catch (error) { console.warn('Échec de la synchronisation serveur:', error); // L'échec n'est pas critique car la préférence est déjà sauvegardée localement } } }</code></pre> </div> </div> <div class="paragraph"> <p>Cette approche permet de synchroniser les préférences entre appareils pour les utilisateurs connectés, tout en gardant la réactivité locale immédiate.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="étape_2_le_script_de_pré_chargement_dans_le_head">5. Étape 2 : Le Script de Pré-chargement dans le <code><head></code></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_cœur_de_la_solution">5.1. Le Cœur de la Solution</h3> <div class="paragraph"> <p>C’est ici que la magie opère véritablement. Nous allons placer un petit script <strong>inline</strong> directement dans notre <code><head></code>, avant toutes nos balises <code><link></code> de feuilles de style. Ce script est volontairement minimaliste, autonome, et conçu pour s’exécuter le plus rapidement possible.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Mon Site Incroyable</title> <!-- ========================================== NOTRE SCRIPT MAGIQUE DE PRÉ-CHARGEMENT Ce script DOIT être le premier élément dans le <head> après les meta tags ========================================== --> <script> // IIFE pour ne pas polluer le scope global (function() { 'use strict'; try { // Lecture de la préférence sauvegardée const savedTheme = localStorage.getItem('preferred-theme'); // Si une préférence existe, on l'applique immédiatement if (savedTheme) { document.documentElement.setAttribute('data-bs-theme', savedTheme); } // Optionnel : Détecter la préférence système si aucune sauvegarde else if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) { document.documentElement.setAttribute('data-bs-theme', 'dark'); } // Sinon, le thème par défaut du CSS sera utilisé (généralement 'light') } catch (error) { // En cas d'erreur (localStorage bloqué, etc.), on log discrètement // et on laisse le thème par défaut s'appliquer console.warn('Impossible de charger la préférence de thème:', error); } })(); </script> <!-- FIN DU SCRIPT MAGIQUE --> <!-- Les feuilles de style sont chargées APRÈS le script --> <link rel="stylesheet" href="css/bootstrap.min.css"> <link rel="stylesheet" href="css/styles.css"> <!-- Autres ressources du head --> <link rel="icon" href="favicon.ico"> </head> <body> <!-- Contenu de la page --> </body> </html></code></pre> </div> </div> </div> <div class="sect2"> <h3 id="anatomie_du_script_chaque_ligne_compte">5.2. Anatomie du Script : Chaque Ligne Compte</h3> <div class="paragraph"> <p>Décortiquons ce script ligne par ligne pour comprendre chaque décision de design :</p> </div> <div class="paragraph"> <p><strong>L’IIFE (Immediately Invoked Function Expression)</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">(function() { // ... })();</code></pre> </div> </div> <div class="paragraph"> <p>Cette structure crée une fonction qui s’exécute immédiatement. Pourquoi ? Pour isoler nos variables dans un scope local et éviter de polluer le scope global. Même si nous n’utilisons que <code>const</code> (qui a un scope de bloc), l’IIFE est une bonne pratique qui rend nos intentions claires et protège contre d’éventuels conflits de noms.</p> </div> <div class="paragraph"> <p><strong>Le Mode Strict</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">'use strict';</code></pre> </div> </div> <div class="paragraph"> <p>Cette directive active le mode strict de JavaScript, qui : - Interdit l’utilisation de variables non déclarées - Génère des erreurs pour les opérations dangereuses - Améliore les performances dans certains moteurs JavaScript</p> </div> <div class="paragraph"> <p>Pour un script critique comme celui-ci, nous voulons la sécurité maximale.</p> </div> <div class="paragraph"> <p><strong>Le Bloc try…​catch</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">try { // Code principal } catch (error) { console.warn('Impossible de charger la préférence de thème:', error); }</code></pre> </div> </div> <div class="paragraph"> <p>Ce bloc est absolument crucial. Il garantit que si quelque chose se passe mal (localStorage bloqué, erreur de syntaxe improbable, etc.), notre script ne bloquera pas le chargement de la page entière. L’utilisation de <code>console.warn</code> plutôt que <code>console.error</code> indique que c’est un problème non-critique.</p> </div> <div class="paragraph"> <p><strong>La Lecture du localStorage</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">const savedTheme = localStorage.getItem('preferred-theme');</code></pre> </div> </div> <div class="paragraph"> <p>Cette ligne peut lever une exception dans certains contextes (navigation privée stricte de Safari). C’est pourquoi elle est dans un bloc try…​catch.</p> </div> <div class="paragraph"> <p><strong>L’Application Conditionnelle</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">if (savedTheme) { document.documentElement.setAttribute('data-bs-theme', savedTheme); }</code></pre> </div> </div> <div class="paragraph"> <p>Nous appliquons le thème seulement si nous en avons trouvé un sauvegardé. Sinon, nous laissons le CSS utiliser son thème par défaut. Cette approche est plus robuste qu’une valeur par défaut côdée en dur dans le JavaScript.</p> </div> </div> <div class="sect2"> <h3 id="détection_de_la_préférence_système_bonus">5.3. Détection de la Préférence Système (Bonus)</h3> <div class="paragraph"> <p>Une amélioration optionnelle mais élégante consiste à détecter la préférence de thème du système d’exploitation de l’utilisateur s’il n’a pas encore fait de choix explicite dans votre application :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">else if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) { document.documentElement.setAttribute('data-bs-theme', 'dark'); }</code></pre> </div> </div> <div class="paragraph"> <p>Cette fonctionnalité utilise la Media Query <code>prefers-color-scheme</code> pour interroger le système. Sur macOS, Windows 10+, iOS, et Android moderne, cette requête retourne la préférence système de l’utilisateur.</p> </div> <div class="paragraph"> <p><strong>Avantages :</strong> - Expérience personnalisée dès la première visite - Cohérence avec l’environnement système de l’utilisateur - Aucun stockage nécessaire pour la première visite</p> </div> <div class="paragraph"> <p><strong>Considérations :</strong> - Tous les navigateurs ne supportent pas cette fonctionnalité (mais le support est excellent depuis 2020) - La vérification <code>window.matchMedia</code> assure la compatibilité - L’utilisateur peut toujours surcharger ce choix</p> </div> </div> <div class="sect2"> <h3 id="performance_pourquoi_ce_script_est_rapide">5.4. Performance : Pourquoi ce Script est Rapide</h3> <div class="paragraph"> <p>Notre script de pré-chargement est conçu pour être extrêmement rapide :</p> </div> <div class="paragraph"> <p><strong>Taille minime</strong> : Environ 300 octets non-minifiés, 200 octets minifiés. C’est négligeable comparé à n’importe quelle image ou librairie JavaScript.</p> </div> <div class="paragraph"> <p><strong>Inline</strong> : Pas de requête HTTP supplémentaire. Le script est dans le HTML, donc il est immédiatement disponible.</p> </div> <div class="paragraph"> <p><strong>Opérations synchrones simples</strong> : Lecture d’une clé dans le localStorage (opération ultra-rapide) et modification d’un attribut DOM (opération native du navigateur).</p> </div> <div class="paragraph"> <p><strong>Aucune dépendance</strong> : Pas de framework, pas de librairie, juste du JavaScript vanilla. Pas de temps de démarrage, pas de parsing de dépendances.</p> </div> <div class="paragraph"> <p><strong>Exécution unique</strong> : Ce script s’exécute une seule fois au chargement. Pas de listeners d’événements, pas de boucles, pas de calculs complexes.</p> </div> <div class="paragraph"> <p>En pratique, sur du matériel moderne, ce script s’exécute en moins de 1 milliseconde, un temps imperceptible qui n’a aucun impact sur la performance de chargement de la page.</p> </div> </div> <div class="sect2"> <h3 id="placement_optimal_dans_le_head">5.5. Placement Optimal dans le <code><head></code></h3> <div class="paragraph"> <p>L’ordre des éléments dans le <code><head></code> est important. Voici l’ordre recommandé :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><head> <!-- 1. Métadonnées critiques --> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <!-- 2. Notre script de pré-chargement (IMMÉDIATEMENT après les meta) --> <script> (function() { /* notre code */ })(); </script> <!-- 3. Titre de la page --> <title>Mon Site</title> <!-- 4. Feuilles de style --> <link rel="stylesheet" href="styles.css"> <!-- 5. Autres ressources (fonts, favicons, etc.) --> <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="icon" href="favicon.ico"> <!-- 6. Autres scripts avec defer ou async --> <script src="app.js" defer></script> </head></code></pre> </div> </div> <div class="paragraph"> <p>Cette ordre garantit que : 1. Le charset est défini avant tout traitement de texte 2. Notre script s’exécute avant le chargement des CSS 3. Les CSS sont chargés ensuite et appliquent directement le bon thème 4. Les autres ressources non-critiques sont chargées en dernier</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="étape_3_la_puissance_des_sélecteurs_dattributs_css">6. Étape 3 : La Puissance des Sélecteurs d’Attributs CSS</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="le_système_de_thème_de_bootstrap_5">6.1. Le Système de Thème de Bootstrap 5</h3> <div class="paragraph"> <p>Bootstrap 5 a introduit un système élégant de gestion des thèmes basé sur les custom properties CSS (variables CSS) et les sélecteurs d’attributs. Ce système utilise l’attribut <code>data-bs-theme</code> sur l’élément <code><html></code> pour déterminer quel ensemble de variables de couleur appliquer.</p> </div> <div class="paragraph"> <p>La beauté de ce système réside dans sa simplicité : au lieu de charger différentes feuilles de style ou de toggle des classes sur des milliers d’éléments, nous changeons simplement un attribut sur un seul élément, et le CSS fait le reste grâce à la cascade.</p> </div> </div> <div class="sect2"> <h3 id="structure_css_pour_un_système_de_thème">6.2. Structure CSS pour un Système de Thème</h3> <div class="paragraph"> <p>Voici une structure CSS complète pour implémenter un système de thème robuste :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">/** * SYSTÈME DE THÈME COMPLET * Utilise les Custom Properties CSS pour une maintenance facile */ /* ============================================ THÈME PAR DÉFAUT (LIGHT) Défini sur :root pour être le fallback ============================================ */ :root { /* Couleurs de base */ --color-primary: #0d6efd; --color-secondary: #6c757d; --color-success: #198754; --color-danger: #dc3545; --color-warning: #ffc107; --color-info: #0dcaf0; /* Couleurs de fond */ --bg-primary: #ffffff; --bg-secondary: #f8f9fa; --bg-tertiary: #e9ecef; /* Couleurs de texte */ --text-primary: #212529; --text-secondary: #6c757d; --text-tertiary: #adb5bd; /* Couleurs de bordure */ --border-color: #dee2e6; --border-color-subtle: #e9ecef; /* Couleurs d'ombre */ --shadow-sm: rgba(0, 0, 0, 0.075); --shadow-md: rgba(0, 0, 0, 0.15); --shadow-lg: rgba(0, 0, 0, 0.25</code></pre> </div> </div> </div> </div> </div> https://pages-content.github.io//blog/2025/0097_gradle_plugin_dev_func_test_logger_post.html Fri, 7 Nov 2025 00:00:00 +0000 blog/2025/0097_gradle_plugin_dev_func_test_logger_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#introduction">1. Introduction</a></li> <li><a href="#le_problème_dépendance_au_gradlerunner">2. Le Problème : Dépendance au GradleRunner</a> <ul class="sectlevel2"> <li><a href="#contexte_du_développement_de_plugin">2.1. Contexte du Développement de Plugin</a></li> <li><a href="#le_dilemme_du_logging">2.2. Le Dilemme du Logging</a></li> <li><a href="#les_fausses_bonnes_idées">2.3. Les Fausses Bonnes Idées</a></li> </ul> </li> <li><a href="#la_solution_logger_indépendant">3. La Solution : Logger Indépendant</a> <ul class="sectlevel2"> <li><a href="#architecture_recommandée">3.1. Architecture Recommandée</a></li> <li><a href="#flux_dexécution">3.2. Flux d’Exécution</a></li> </ul> </li> <li><a href="#implémentation_complète">4. Implémentation Complète</a> <ul class="sectlevel2"> <li><a href="#dépendances_gradle">4.1. Dépendances Gradle</a></li> <li><a href="#configuration_logback">4.2. Configuration Logback</a></li> <li><a href="#classe_de_test_complète">4.3. Classe de Test Complète</a></li> </ul> </li> <li><a href="#schéma_de_logging_multi_niveaux">5. Schéma de Logging Multi-Niveaux</a></li> <li><a href="#bonnes_pratiques">6. Bonnes Pratiques</a> <ul class="sectlevel2"> <li><a href="#structure_de_logging_recommandée">6.1. Structure de Logging Recommandée</a></li> <li><a href="#symboles_visuels_pour_la_lisibilité">6.2. Symboles Visuels pour la Lisibilité</a></li> <li><a href="#extraction_dinformations_de_la_sortie">6.3. Extraction d’Informations de la Sortie</a></li> </ul> </li> <li><a href="#comparaison_avantaprès">7. Comparaison Avant/Après</a> <ul class="sectlevel2"> <li><a href="#avant_approche_problématique">7.1. Avant : Approche Problématique</a></li> <li><a href="#après_approche_robuste">7.2. Après : Approche Robuste</a></li> </ul> </li> <li><a href="#diagramme_récapitulatif">8. Diagramme Récapitulatif</a></li> <li><a href="#pièges_à_éviter">9. Pièges à Éviter</a> <ul class="sectlevel2"> <li><a href="#piège_n1_oublier_forwardoutput">9.1. ❌ Piège n°1 : Oublier <code>.forwardOutput()</code></a></li> <li><a href="#piège_n2_logger_non_initialisé">9.2. ❌ Piège n°2 : Logger Non Initialisé</a></li> <li><a href="#piège_n3_logging_excessif">9.3. ❌ Piège n°3 : Logging Excessif</a></li> </ul> </li> <li><a href="#résultats_et_métriques">10. Résultats et Métriques</a></li> <li><a href="#conclusion">11. Conclusion</a></li> <li><a href="#ressources">12. Ressources</a></li> <li><a href="#aller_plus_loin">13. Aller Plus Loin</a></li> </ul> </div> <div class="sect1"> <h2 id="introduction"><a class="anchor" href="#introduction"></a><a class="link" href="#introduction">1. Introduction</a></h2> <div class="sectionbody"> <div class="paragraph"> <p>Lors du développement d’un plugin Gradle, les tests fonctionnels sont essentiels pour valider le comportement du plugin dans un environnement Gradle réel. Cependant, une question cruciale se pose rapidement : <strong>comment mettre en place un système de logging efficace sans créer de dépendances problématiques avec le <code>GradleRunner</code> ?</strong></p> </div> <div class="paragraph"> <p>Dans cet article, nous allons explorer :</p> </div> <div class="ulist"> <ul> <li> <p>La problématique du logging dans les tests fonctionnels Gradle</p> </li> <li> <p>L’architecture d’une solution robuste avec SLF4J et Logback</p> </li> <li> <p>L’implémentation complète avec des exemples concrets</p> </li> <li> <p>Les bonnes pratiques et pièges à éviter</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="le_problème_dépendance_au_gradlerunner"><a class="anchor" href="#le_problème_dépendance_au_gradlerunner"></a><a class="link" href="#le_problème_dépendance_au_gradlerunner">2. Le Problème : Dépendance au GradleRunner</a></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="contexte_du_développement_de_plugin"><a class="anchor" href="#contexte_du_développement_de_plugin"></a><a class="link" href="#contexte_du_développement_de_plugin">2.1. Contexte du Développement de Plugin</a></h3> <div class="paragraph"> <p>Lorsqu’on développe un plugin Gradle, on utilise généralement le <code>GradleRunner</code> du <em>Gradle TestKit</em> pour exécuter des builds de test :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `test my plugin`() { val result = GradleRunner.create() .withProjectDir(projectDir) .withArguments("myTask") .build() // Comment logger efficacement ici ? }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="le_dilemme_du_logging"><a class="anchor" href="#le_dilemme_du_logging"></a><a class="link" href="#le_dilemme_du_logging">2.2. Le Dilemme du Logging</a></h3> <div class="paragraph"> <p>Le problème principal est le suivant : <strong>le logging ne doit pas dépendre d’un objet dont on n’est pas sûr de l’initialisation</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-098f273556d73eefcb03088a9c320c28.png" alt="Diagram" width="460" height="262"> </div> </div> </div> <div class="sect2"> <h3 id="les_fausses_bonnes_idées"><a class="anchor" href="#les_fausses_bonnes_idées"></a><a class="link" href="#les_fausses_bonnes_idées">2.3. Les Fausses Bonnes Idées</a></h3> <div class="admonitionblock warning"> <table> <tr> <td class="icon"> <i class="fa icon-warning" title="Warning"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Ne faites PAS cela :</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// ❌ MAUVAIS: Tentative d'obtenir un logger du runner val runner = GradleRunner.create() val logger = runner.logger // N'existe pas ! // ❌ MAUVAIS: Logger partagé initialisé tardivement lateinit var logger: Logger @BeforeEach fun setup() { logger = LoggerFactory.getLogger(...) }</code></pre> </div> </div> </td> </tr> </table> </div> </div> </div> </div> <div class="sect1"> <h2 id="la_solution_logger_indépendant"><a class="anchor" href="#la_solution_logger_indépendant"></a><a class="link" href="#la_solution_logger_indépendant">3. La Solution : Logger Indépendant</a></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="architecture_recommandée"><a class="anchor" href="#architecture_recommandée"></a><a class="link" href="#architecture_recommandée">3.1. Architecture Recommandée</a></h3> <div class="paragraph"> <p>La solution consiste à utiliser un logger <strong>complètement indépendant</strong> du <code>GradleRunner</code>, initialisé au niveau de la classe de test.</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-ffb0cf405a345057991a32f0ed77e9f4.png" alt="Diagram" width="601" height="448"> </div> </div> </div> <div class="sect2"> <h3 id="flux_dexécution"><a class="anchor" href="#flux_dexécution"></a><a class="link" href="#flux_dexécution">3.2. Flux d’Exécution</a></h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-ee708f49dc49046ba65da9a958958434.png" alt="Diagram" width="713" height="686"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="implémentation_complète"><a class="anchor" href="#implémentation_complète"></a><a class="link" href="#implémentation_complète">4. Implémentation Complète</a></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="dépendances_gradle"><a class="anchor" href="#dépendances_gradle"></a><a class="link" href="#dépendances_gradle">4.1. Dépendances Gradle</a></h3> <div class="paragraph"> <p>Ajoutez les dépendances nécessaires dans votre <code>build.gradle.kts</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">dependencies { // Pour les tests fonctionnels testImplementation(gradleTestKit()) testImplementation("org.junit.jupiter:junit-jupiter:5.10.2") // Pour le logging testImplementation("org.slf4j:slf4j-api:2.0.17") testRuntimeOnly("ch.qos.logback:logback-classic:1.4.14") // Pour les assertions testImplementation("org.assertj:assertj-core:3.27.6") } tasks.test { useJUnitPlatform() }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="configuration_logback"><a class="anchor" href="#configuration_logback"></a><a class="link" href="#configuration_logback">4.2. Configuration Logback</a></h3> <div class="paragraph"> <p>Créez le fichier <code>src/test/resources/logback-test.xml</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-xml hljs" data-lang="xml"><?xml version="1.0" encoding="UTF-8"?> <configuration> <!-- Appender console avec format lisible --> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <!-- Appender fichier pour conservation --> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>build/test-results/functional-tests.log</file> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n</pattern> </encoder> </appender> <!-- Logger pour vos tests --> <logger name="com.cheroliv.bakery" level="DEBUG"/> <!-- Réduire le bruit de Gradle --> <logger name="org.gradle" level="WARN"/> <!-- Configuration racine --> <root level="INFO"> <appender-ref ref="STDOUT"/> <appender-ref ref="FILE"/> </root> </configuration></code></pre> </div> </div> </div> <div class="sect2"> <h3 id="classe_de_test_complète"><a class="anchor" href="#classe_de_test_complète"></a><a class="link" href="#classe_de_test_complète">4.3. Classe de Test Complète</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">package com.cheroliv.bakery import org.gradle.testkit.runner.GradleRunner import org.gradle.testkit.runner.TaskOutcome import org.junit.jupiter.api.* import org.junit.jupiter.api.TestInstance.Lifecycle.PER_CLASS import org.junit.jupiter.api.io.TempDir import org.slf4j.Logger import org.slf4j.LoggerFactory import java.io.File import kotlin.test.assertEquals import kotlin.test.assertTrue @TestInstance(PER_CLASS) class BakeryPluginFunctionalTest { @field:TempDir lateinit var projectDir: File private val buildFile by lazy { projectDir.resolve("build.gradle.kts") } private val settingsFile by lazy { projectDir.resolve("settings.gradle.kts") } companion object { // ✓ Logger indépendant, initialisé au chargement de la classe private val logger: Logger = LoggerFactory.getLogger( BakeryPluginFunctionalTest::class.java ) @JvmStatic @BeforeAll fun globalSetup() { logger.info("═".repeat(60)) logger.info("DÉMARRAGE DE LA SUITE DE TESTS FONCTIONNELS") logger.info("═".repeat(60)) } @JvmStatic @AfterAll fun globalTeardown() { logger.info("═".repeat(60)) logger.info("FIN DE LA SUITE DE TESTS") logger.info("═".repeat(60)) } } @BeforeEach fun setup() { logger.info("─".repeat(60)) logger.info("Préparation de l'environnement de test") logger.debug("Répertoire de test: ${projectDir.absolutePath}") settingsFile.writeText(""" rootProject.name = "test-bakery-project" """.trimIndent()) logger.debug("✓ settings.gradle.kts créé") } @AfterEach fun teardown(testInfo: TestInfo) { logger.info("✓ Test terminé: ${testInfo.displayName}") logger.info("─".repeat(60)) } @Test fun `plugin can be applied successfully`() { logger.info("TEST: Application du plugin Bakery") buildFile.writeText(""" plugins { id("com.cheroliv.bakery") } """.trimIndent()) logger.debug("Fichier build.gradle.kts créé") logger.debug("Lancement du build Gradle...") val startTime = System.currentTimeMillis() val result = GradleRunner.create() .forwardOutput() // ← Important : capture la sortie .withPluginClasspath() .withArguments("tasks", "--group=bakery", "--stacktrace") .withProjectDir(projectDir) .build() val duration = System.currentTimeMillis() - startTime logger.info("Build terminé en ${duration}ms") // Analyse de la sortie logger.debug("Analyse de la sortie Gradle...") val outputLines = result.output.lines() logger.debug("Nombre de lignes capturées: ${outputLines.size}") // Validation val expectedTasks = listOf("bake", "printConfigPath", "printJBakeClasspath") logger.info("Vérification des tâches attendues:") expectedTasks.forEach { task -> val found = result.output.contains(task) logger.debug(" ${if (found) "✓" else "✗"} $task") assertTrue(found, "Task '$task' should be available") } logger.info("✓ Plugin appliqué avec succès - ${expectedTasks.size} tâches trouvées") } @Test fun `bake task executes and prints version`() { logger.info("TEST: Exécution de la tâche 'bake'") buildFile.writeText(""" plugins { id("com.cheroliv.bakery") } """.trimIndent()) logger.debug("Exécution de 'gradle bake'...") val result = GradleRunner.create() .forwardOutput() .withPluginClasspath() .withArguments("bake", "--info") // --info pour plus de détails .withProjectDir(projectDir) .build() // Extraction d'informations depuis la sortie logger.debug("Recherche du message 'Baking site'...") val hasBakingMessage = result.output.contains("Baking site with Bakery Plugin!") logger.debug("Recherche de la version JBake...") val hasVersionMessage = result.output.contains("Using JBake version:") // Extraction de la version (si présente) val versionRegex = Regex("Using JBake version: (.+)") val versionMatch = versionRegex.find(result.output) if (versionMatch != null) { val version = versionMatch.groupValues[1] logger.info("Version JBake détectée: $version") } // Validation assertTrue(hasBakingMessage, "Message 'Baking site' attendu") assertTrue(hasVersionMessage, "Message de version attendu") assertEquals(TaskOutcome.SUCCESS, result.task(":bake")?.outcome) logger.info("✓ Tâche 'bake' exécutée avec succès") } @Test fun `analyze output with structured logging`() { logger.info("TEST: Analyse structurée de la sortie") buildFile.writeText(""" plugins { id("com.cheroliv.bakery") } task("diagnostics") { doLast { println("[DIAG] Project: ${'$'}{project.name}") println("[DIAG] Build dir: ${'$'}{project.buildDir}") println("[DIAG] Plugin applied: true") val config = configurations.findByName("jbakeRuntime") println("[DIAG] JBake config exists: ${'$'}{config != null}") if (config != null) { println("[DIAG] Dependencies count: ${'$'}{config.dependencies.size}") } } } """.trimIndent()) logger.debug("Exécution de la tâche diagnostics...") val result = GradleRunner.create() .forwardOutput() .withPluginClasspath() .withArguments("diagnostics", "--quiet") .withProjectDir(projectDir) .build() // Analyse structurée logger.info("Extraction des informations de diagnostic:") val diagLines = result.output.lines() .filter { it.startsWith("[DIAG]") } logger.debug("Nombre de lignes de diagnostic: ${diagLines.size}") diagLines.forEach { line -> logger.info(" $line") // Analyse spécifique par type de ligne when { line.contains("Project:") -> { val projectName = line.substringAfter("Project:").trim() logger.debug(" → Nom du projet extrait: '$projectName'") } line.contains("Dependencies count:") -> { val count = line.substringAfter("count:").trim() logger.debug(" → Nombre de dépendances: $count") } } } assertTrue(diagLines.isNotEmpty(), "Des lignes de diagnostic devraient être présentes") logger.info("✓ Analyse structurée terminée - ${diagLines.size} lignes analysées") } @Test fun `test with error handling`() { logger.info("TEST: Gestion d'erreurs avec logging") buildFile.writeText(""" plugins { id("com.cheroliv.bakery") } """.trimIndent()) try { logger.debug("Tentative d'exécution...") val result = GradleRunner.create() .forwardOutput() .withPluginClasspath() .withArguments("printJBakeClasspath") .withProjectDir(projectDir) .build() val outcome = result.task(":printJBakeClasspath")?.outcome logger.info("Outcome: $outcome") if (outcome == TaskOutcome.SUCCESS) { logger.info("✓ Exécution réussie") } else { logger.warn("⚠ Outcome inattendu: $outcome") } assertEquals(TaskOutcome.SUCCESS, outcome) } catch (e: Exception) { logger.error("✗ Échec du test", e) logger.error("Type d'exception: ${e.javaClass.simpleName}") logger.error("Message: ${e.message}") // Log de la stack trace si nécessaire if (logger.isDebugEnabled) { logger.debug("Stack trace complète:", e) } throw e } } }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="schéma_de_logging_multi_niveaux"><a class="anchor" href="#schéma_de_logging_multi_niveaux"></a><a class="link" href="#schéma_de_logging_multi_niveaux">5. Schéma de Logging Multi-Niveaux</a></h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-69cc83dd2b31ced14c3dd245c6509cb0.png" alt="Diagram" width="314" height="911"> </div> </div> </div> </div> <div class="sect1"> <h2 id="bonnes_pratiques"><a class="anchor" href="#bonnes_pratiques"></a><a class="link" href="#bonnes_pratiques">6. Bonnes Pratiques</a></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="structure_de_logging_recommandée"><a class="anchor" href="#structure_de_logging_recommandée"></a><a class="link" href="#structure_de_logging_recommandée">6.1. Structure de Logging Recommandée</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `mon test`() { // 1. LOG: Début du test logger.info("TEST: Description du test") // 2. LOG: Préparation logger.debug("Préparation des fichiers...") buildFile.writeText("...") logger.debug("✓ Fichiers préparés") // 3. LOG: Exécution logger.debug("Lancement du build...") val startTime = System.currentTimeMillis() val result = GradleRunner.create() .forwardOutput() .withArguments("task") .build() val duration = System.currentTimeMillis() - startTime logger.info("Build terminé en ${duration}ms") // 4. LOG: Analyse logger.debug("Analyse des résultats...") // ... validations ... // 5. LOG: Conclusion logger.info("✓ Test réussi") }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="symboles_visuels_pour_la_lisibilité"><a class="anchor" href="#symboles_visuels_pour_la_lisibilité"></a><a class="link" href="#symboles_visuels_pour_la_lisibilité">6.2. Symboles Visuels pour la Lisibilité</a></h3> <div class="paragraph"> <p>Utilisez des symboles Unicode pour améliorer la lisibilité des logs :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">logger.info("✓ Succès") logger.info("✗ Échec") logger.info("⚠ Attention") logger.info("→ Étape suivante") logger.info("═".repeat(60)) // Séparateur principal logger.info("─".repeat(60)) // Séparateur secondaire</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="extraction_dinformations_de_la_sortie"><a class="anchor" href="#extraction_dinformations_de_la_sortie"></a><a class="link" href="#extraction_dinformations_de_la_sortie">6.3. Extraction d’Informations de la Sortie</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// Recherche simple val hasMessage = result.output.contains("Expected message") // Extraction avec regex val versionRegex = Regex("Version: (.+)") val version = versionRegex.find(result.output)?.groupValues?.get(1) // Filtrage de lignes val errorLines = result.output.lines() .filter { it.contains("ERROR") } errorLines.forEach { logger.error("Gradle error: $it") }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="comparaison_avantaprès"><a class="anchor" href="#comparaison_avantaprès"></a><a class="link" href="#comparaison_avantaprès">7. Comparaison Avant/Après</a></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="avant_approche_problématique"><a class="anchor" href="#avant_approche_problématique"></a><a class="link" href="#avant_approche_problématique">7.1. Avant : Approche Problématique</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class MyTest { lateinit var logger: Logger // ❌ Initialisé tardivement @BeforeEach fun setup() { logger = LoggerFactory.getLogger(...) // ❌ Dépendance } @Test fun test() { val runner = GradleRunner.create() logger.info("Testing...") // ⚠ Peut échouer } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="après_approche_robuste"><a class="anchor" href="#après_approche_robuste"></a><a class="link" href="#après_approche_robuste">7.2. Après : Approche Robuste</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class MyTest { companion object { private val logger = LoggerFactory.getLogger(...) // ✓ Indépendant } @Test fun test() { logger.info("TEST: Starting...") // ✓ Toujours disponible val result = GradleRunner.create() .forwardOutput() // ✓ Capture la sortie .build() logger.debug("Output: ${result.output}") // ✓ Analyse } }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="diagramme_récapitulatif"><a class="anchor" href="#diagramme_récapitulatif"></a><a class="link" href="#diagramme_récapitulatif">8. Diagramme Récapitulatif</a></h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-e6aafa175e92a0e0de6ae9cdeb5f360e.png" alt="Diagram" width="963" height="1345"> </div> </div> </div> </div> <div class="sect1"> <h2 id="pièges_à_éviter"><a class="anchor" href="#pièges_à_éviter"></a><a class="link" href="#pièges_à_éviter">9. Pièges à Éviter</a></h2> <div class="sectionbody"> <div class="sect2"> <h3 id="piège_n1_oublier_forwardoutput"><a class="anchor" href="#piège_n1_oublier_forwardoutput"></a><a class="link" href="#piège_n1_oublier_forwardoutput">9.1. ❌ Piège n°1 : Oublier <code>.forwardOutput()</code></a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// MAUVAIS: La sortie Gradle n'est pas capturée val result = GradleRunner.create() .withArguments("task") .build() // result.output sera vide !</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// BON: La sortie est capturée val result = GradleRunner.create() .forwardOutput() // ✓ .withArguments("task") .build()</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="piège_n2_logger_non_initialisé"><a class="anchor" href="#piège_n2_logger_non_initialisé"></a><a class="link" href="#piège_n2_logger_non_initialisé">9.2. ❌ Piège n°2 : Logger Non Initialisé</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// MAUVAIS class Test { lateinit var logger: Logger // Peut ne pas être initialisé }</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// BON class Test { companion object { private val logger = LoggerFactory.getLogger(...) // Toujours initialisé } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="piège_n3_logging_excessif"><a class="anchor" href="#piège_n3_logging_excessif"></a><a class="link" href="#piège_n3_logging_excessif">9.3. ❌ Piège n°3 : Logging Excessif</a></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// MAUVAIS: Trop de logs DEBUG en production logger.debug("Variable a = $a") logger.debug("Variable b = $b") logger.debug("Variable c = $c") // ... 100 lignes de logs</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// BON: Logging ciblé logger.info("Traitement de ${items.size} éléments") logger.debug("Détails: ${items.take(5)}...") // Échantillon seulement</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="résultats_et_métriques"><a class="anchor" href="#résultats_et_métriques"></a><a class="link" href="#résultats_et_métriques">10. Résultats et Métriques</a></h2> <div class="sectionbody"> <div class="paragraph"> <p>Avec cette approche, vous obtenez :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 28.5714%;"> <col style="width: 42.8571%;"> <col style="width: 28.5715%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Métrique</th> <th class="tableblock halign-left valign-top">Avant</th> <th class="tableblock halign-left valign-top">Après</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Lignes de code</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~50 lignes</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~80 lignes (+60%)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Temps de debug</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~30 min</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">~5 min (-83%)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Erreurs détectées</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Basique</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Détaillé</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Maintenance</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Difficile</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Simple</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Indépendance</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">❌ Couplée</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">✓ Indépendante</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="conclusion"><a class="anchor" href="#conclusion"></a><a class="link" href="#conclusion">11. Conclusion</a></h2> <div class="sectionbody"> <div class="paragraph"> <p>La mise en place d’un système de logging robuste dans les tests fonctionnels de plugins Gradle repose sur un principe simple : <strong>l’indépendance</strong>.</p> </div> <div class="paragraph"> <p>Points clés à retenir :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Logger indépendant</strong> : Initialisé dans un <code>companion object</code></p> </li> <li> <p><strong>SLF4J + Logback</strong> : Stack éprouvée et configurable</p> </li> <li> <p><strong><code>.forwardOutput()</code></strong> : Capture de la sortie Gradle</p> </li> <li> <p><strong>Logging structuré</strong> : INFO pour les étapes, DEBUG pour les détails</p> </li> <li> <p><strong>Analyse de sortie</strong> : Extraction d’informations depuis <code>result.output</code></p> </li> </ol> </div> <div class="paragraph"> <p>Cette approche garantit des tests <strong>maintenables</strong>, <strong>debuggables</strong> et <strong>robustes</strong>, tout en respectant les principes de conception solides.</p> </div> </div> </div> <div class="sect1"> <h2 id="ressources"><a class="anchor" href="#ressources"></a><a class="link" href="#ressources">12. Ressources</a></h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://docs.gradle.org/current/userguide/test_kit.html">Gradle TestKit Documentation</a></p> </li> <li> <p><a href="https://www.slf4j.org/manual.html">SLF4J Manual</a></p> </li> <li> <p><a href="https://logback.qos.ch/manual/configuration.html">Logback Configuration</a></p> </li> <li> <p><a href="https://github.com/gradle/gradle/tree/master/subprojects/test-kit">Gradle TestKit Source Code</a></p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="aller_plus_loin"><a class="anchor" href="#aller_plus_loin"></a><a class="link" href="#aller_plus_loin">13. Aller Plus Loin</a></h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans un prochain article, nous explorerons :</p> </div> <div class="ulist"> <ul> <li> <p>L’intégration continue avec logging structuré</p> </li> <li> <p>Les rapports HTML de tests avec logs intégrés</p> </li> <li> <p>Le débogage avancé avec JVM attach</p> </li> <li> <p>Les performances et optimisations de logging</p> </li> </ul> </div> <hr> <div class="paragraph"> <p><em>Cet article fait partie de la série "Développement de Plugins Gradle" sur mon blog technique.</em></p> </div> </div> </div> https://pages-content.github.io//blog/2025/0096_afficher-couleurs-asciidoc_post.html Sat, 1 Nov 2025 00:00:00 +0000 blog/2025/0096_afficher-couleurs-asciidoc_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_la_problématique">2. La problématique</a> <ul class="sectlevel2"> <li><a href="#_contexte_dutilisation">2.1. Contexte d’utilisation</a></li> <li><a href="#_les_approches_possibles">2.2. Les approches possibles</a> <ul class="sectlevel3"> <li><a href="#_option_1_caractères_unicode">2.2.1. Option 1 : Caractères Unicode</a></li> <li><a href="#_option_2_images_externes">2.2.2. Option 2 : Images externes</a></li> <li><a href="#_option_3_rôles_css_personnalisés">2.2.3. Option 3 : Rôles CSS personnalisés</a></li> <li><a href="#_option_4_injection_html_solution_retenue">2.2.4. Option 4 : Injection HTML (solution retenue)</a></li> </ul> </li> </ul> </li> <li><a href="#_la_solution_injection_html_avec">3. La solution : Injection HTML avec </a> <ul class="sectlevel2"> <li><a href="#_principe_de_fonctionnement">3.1. Principe de fonctionnement</a></li> <li><a href="#_implémentation">3.2. Implémentation</a> <ul class="sectlevel3"> <li><a href="#_explication_des_propriétés_css">3.2.1. Explication des propriétés CSS</a></li> </ul> </li> <li><a href="#_exemple_complet">3.3. Exemple complet</a></li> </ul> </li> <li><a href="#_optimisations_et_bonnes_pratiques">4. Optimisations et bonnes pratiques</a> <ul class="sectlevel2"> <li><a href="#_gérer_les_couleurs_claires">4.1. Gérer les couleurs claires</a></li> <li><a href="#_adapter_la_taille_des_carrés">4.2. Adapter la taille des carrés</a></li> <li><a href="#_créer_des_variantes">4.3. Créer des variantes</a> <ul class="sectlevel3"> <li><a href="#_cercle_coloré">4.3.1. Cercle coloré</a></li> <li><a href="#_carré_avec_bordure_colorée">4.3.2. Carré avec bordure colorée</a></li> </ul> </li> </ul> </li> <li><a href="#_architecture_de_la_solution">5. Architecture de la solution</a></li> <li><a href="#_avantages_et_limitations">6. Avantages et limitations</a> <ul class="sectlevel2"> <li><a href="#_avantages">6.1. Avantages</a></li> <li><a href="#_limitations">6.2. Limitations</a></li> <li><a href="#_amélioration_de_laccessibilité">6.3. Amélioration de l’accessibilité</a></li> </ul> </li> <li><a href="#_exemple_concret_documentation_de_thèmes">7. Exemple concret : Documentation de thèmes</a></li> <li><a href="#_conclusion">8. Conclusion</a></li> <li><a href="#_ressources">9. Ressources</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Lors de la rédaction de documentation technique, notamment pour des guides de style ou des spécifications d’interface utilisateur, il est fréquent de devoir afficher des palettes de couleurs. AsciiDoc, bien que très puissant pour la documentation, ne propose pas de syntaxe native pour afficher des échantillons de couleur. Cet article explore la problématique et propose une solution élégante basée sur l’injection HTML.</p> </div> </div> </div> <div class="sect1"> <h2 id="_la_problématique">2. La problématique</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_contexte_dutilisation">2.1. Contexte d’utilisation</h3> <div class="paragraph"> <p>Imaginons que vous documentez les variables CSS d’un thème d’application web. Vous avez besoin de :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Lister les codes couleurs hexadécimaux</p> </li> <li> <p>Afficher un aperçu visuel de chaque couleur</p> </li> <li> <p>Maintenir la lisibilité du document source</p> </li> <li> <p>Assurer la compatibilité avec les générateurs de sites statiques comme JBake</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="use-case-diagram.svg" alt="use case diagram" width="1050" height="205"> </div> </div> </div> <div class="sect2"> <h3 id="_les_approches_possibles">2.2. Les approches possibles</h3> <div class="paragraph"> <p>Plusieurs solutions peuvent être envisagées pour afficher des couleurs dans un document AsciiDoc :</p> </div> <div class="imageblock"> <div class="content"> <img src="component-diagram.svg" alt="component diagram" width="874" height="190"> </div> </div> <div class="sect3"> <h4 id="_option_1_caractères_unicode">2.2.1. Option 1 : Caractères Unicode</h4> <div class="paragraph"> <p>L’utilisation de caractères Unicode comme <code>■</code> (■) est simple mais limitée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* ■ --accent-color: #7952b3 (violet Bootstrap)</code></pre> </div> </div> <div class="paragraph"> <p><strong>Limitations</strong> : Pas de contrôle sur la couleur, dépend de la police système.</p> </div> </div> <div class="sect3"> <h4 id="_option_2_images_externes">2.2.2. Option 2 : Images externes</h4> <div class="paragraph"> <p>Créer des images PNG ou SVG pour chaque couleur :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* image:colors/violet.svg[width=16] --accent-color: #7952b3</code></pre> </div> </div> <div class="paragraph"> <p><strong>Limitations</strong> : Maintenance lourde, multiplication des fichiers, pas de synchronisation automatique.</p> </div> </div> <div class="sect3"> <h4 id="_option_3_rôles_css_personnalisés">2.2.3. Option 3 : Rôles CSS personnalisés</h4> <div class="paragraph"> <p>Définir des classes CSS et les appliquer via des rôles AsciiDoc :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* [.color-violet]##■## --accent-color: #7952b3</code></pre> </div> </div> <div class="paragraph"> <p><strong>Limitations</strong> : Nécessite une feuille de style externe, définition préalable de toutes les couleurs possibles.</p> </div> </div> <div class="sect3"> <h4 id="_option_4_injection_html_solution_retenue">2.2.4. Option 4 : Injection HTML (solution retenue)</h4> <div class="paragraph"> <p>Utiliser la macro <code></code> pour injecter du HTML avec styles inline :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* pass:[<span style="display:inline-block;width:1em;height:1em; background:#7952b3;vertical-align:middle;margin-right:0.5em"></span>] --accent-color: #7952b3 (violet Bootstrap)</code></pre> </div> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_la_solution_injection_html_avec">3. La solution : Injection HTML avec </h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_principe_de_fonctionnement">3.1. Principe de fonctionnement</h3> <div class="paragraph"> <p>La macro <code></code> d’AsciiDoc permet d’insérer du contenu brut qui ne sera pas interprété par le processeur AsciiDoc. Cela nous permet d’injecter directement du HTML avec des styles CSS inline.</p> </div> <div class="imageblock"> <div class="content"> <img src="sequence-diagram.svg" alt="sequence diagram" width="628" height="282"> </div> </div> </div> <div class="sect2"> <h3 id="_implémentation">3.2. Implémentation</h3> <div class="paragraph"> <p>Voici la structure HTML à injecter :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><span style="display:inline-block; width:1em; height:1em; background:#7952b3; vertical-align:middle; margin-right:0.5em"> </span></code></pre> </div> </div> <div class="sect3"> <h4 id="_explication_des_propriétés_css">3.2.1. Explication des propriétés CSS</h4> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Propriété</th> <th class="tableblock halign-left valign-top">Fonction</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>display:inline-block</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Permet de définir width/height tout en restant dans le flux inline</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>width:1em; height:1em</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Taille du carré relative à la taille de police (responsive)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>background:#7952b3</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">La couleur à afficher (variable selon vos besoins)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>vertical-align:middle</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Aligne le carré avec le texte adjacent</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>margin-right:0.5em</code></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Espacement entre le carré et le texte</p></td> </tr> </tbody> </table> </div> </div> <div class="sect2"> <h3 id="_exemple_complet">3.3. Exemple complet</h3> <div class="paragraph"> <p>Voici un exemple documentant une palette de thème :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">== Thème Clair * pass:[<span style="display:inline-block;width:1em;height:1em;background:#f8f9fa;border:1px solid #ccc;vertical-align:middle;margin-right:0.5em"></span>] --bg-primary: `#f8f9fa` (blanc cassé) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#212529;vertical-align:middle;margin-right:0.5em"></span>] --text-primary: `#212529` (noir très foncé) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#7952b3;vertical-align:middle;margin-right:0.5em"></span>] --accent-color: `#7952b3` (violet Bootstrap) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#61428f;vertical-align:middle;margin-right:0.5em"></span>] --accent-hover: `#61428f` (violet plus foncé) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#ffffff;border:1px solid #ccc;vertical-align:middle;margin-right:0.5em"></span>] --card-bg: `#ffffff` (blanc)</code></pre> </div> </div> <div class="paragraph"> <p>Qui produit le rendu suivant :</p> </div> <hr> <div class="paragraph"> <p><strong>Thème Clair</strong></p> </div> <div class="ulist"> <ul> <li> <p><span style="display:inline-block;width:1em;height:1em;background:#f8f9fa;border:1px solid #ccc;vertical-align:middle;margin-right:0.5em"></span> --bg-primary: <code>#f8f9fa</code> (blanc cassé)</p> </li> <li> <p><span style="display:inline-block;width:1em;height:1em;background:#212529;vertical-align:middle;margin-right:0.5em"></span> --text-primary: <code>#212529</code> (noir très foncé)</p> </li> <li> <p><span style="display:inline-block;width:1em;height:1em;background:#7952b3;vertical-align:middle;margin-right:0.5em"></span> --accent-color: <code>#7952b3</code> (violet Bootstrap)</p> </li> <li> <p><span style="display:inline-block;width:1em;height:1em;background:#61428f;vertical-align:middle;margin-right:0.5em"></span> --accent-hover: <code>#61428f</code> (violet plus foncé)</p> </li> <li> <p><span style="display:inline-block;width:1em;height:1em;background:#ffffff;border:1px solid #ccc;vertical-align:middle;margin-right:0.5em"></span> --card-bg: <code>#ffffff</code> (blanc)</p> </li> </ul> </div> <hr> </div> </div> </div> <div class="sect1"> <h2 id="_optimisations_et_bonnes_pratiques">4. Optimisations et bonnes pratiques</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_gérer_les_couleurs_claires">4.1. Gérer les couleurs claires</h3> <div class="paragraph"> <p>Pour les couleurs très claires (blanc, gris très clair), ajoutez une bordure pour les rendre visibles sur fond blanc :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><span style="display:inline-block;width:1em;height:1em; background:#ffffff;border:1px solid #ccc; vertical-align:middle;margin-right:0.5em"></span></code></pre> </div> </div> <div class="paragraph"> <p>La bordure grise (<code>border:1px solid #ccc</code>) permet de délimiter le carré blanc sur un fond blanc.</p> </div> </div> <div class="sect2"> <h3 id="_adapter_la_taille_des_carrés">4.2. Adapter la taille des carrés</h3> <div class="paragraph"> <p>Vous pouvez ajuster la taille des carrés selon vos besoins :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* pass:[<span style="display:inline-block;width:1.5em;height:1.5em;background:#7952b3;vertical-align:middle;margin-right:0.5em"></span>] Grand carré * pass:[<span style="display:inline-block;width:0.8em;height:0.8em;background:#7952b3;vertical-align:middle;margin-right:0.5em"></span>] Petit carré</code></pre> </div> </div> <div class="paragraph"> <p>L’utilisation de l’unité <code>em</code> garantit que les carrés s’adaptent à la taille de la police.</p> </div> </div> <div class="sect2"> <h3 id="_créer_des_variantes">4.3. Créer des variantes</h3> <div class="paragraph"> <p>Pour des besoins spécifiques, vous pouvez créer différentes formes :</p> </div> <div class="sect3"> <h4 id="_cercle_coloré">4.3.1. Cercle coloré</h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* pass:[<span style="display:inline-block;width:1em;height:1em;background:#7952b3;border-radius:50%;vertical-align:middle;margin-right:0.5em"></span>] Cercle violet</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_carré_avec_bordure_colorée">4.3.2. Carré avec bordure colorée</h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* pass:[<span style="display:inline-block;width:1em;height:1em;background:#ffffff;border:3px solid #7952b3;vertical-align:middle;margin-right:0.5em"></span>] Bordure violette</code></pre> </div> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_de_la_solution">5. Architecture de la solution</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="architecture-diagram.svg" alt="architecture diagram" width="483" height="412"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_avantages_et_limitations">6. Avantages et limitations</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_avantages">6.1. Avantages</h3> <div class="ulist"> <ul> <li> <p>✓ <strong>Autonomie</strong> : Pas de dépendance à des fichiers externes</p> </li> <li> <p>✓ <strong>Portabilité</strong> : Fonctionne avec tous les processeurs AsciiDoc</p> </li> <li> <p>✓ <strong>Synchronisation</strong> : Le code couleur est directement dans le HTML</p> </li> <li> <p>✓ <strong>Flexibilité</strong> : Personnalisation complète du style</p> </li> <li> <p>✓ <strong>Maintenance</strong> : Modification simple du code hexadécimal</p> </li> <li> <p>✓ <strong>Compatibilité JBake</strong> : Fonctionne parfaitement avec les générateurs de sites statiques</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_limitations">6.2. Limitations</h3> <div class="ulist"> <ul> <li> <p>✗ <strong>Verbosité</strong> : Code HTML répétitif dans le source AsciiDoc</p> </li> <li> <p>✗ <strong>Lisibilité source</strong> : Le document source est moins épuré</p> </li> <li> <p>✗ <strong>Accessibilité</strong> : Pas de texte alternatif natif (à ajouter manuellement)</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_amélioration_de_laccessibilité">6.3. Amélioration de l’accessibilité</h3> <div class="paragraph"> <p>Pour rendre les carrés accessibles aux lecteurs d’écran :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* pass:[<span role="img" aria-label="Couleur violet Bootstrap" style="display:inline-block;width:1em;height:1em;background:#7952b3; vertical-align:middle;margin-right:0.5em"></span>] --accent-color: `#7952b3` (violet Bootstrap)</code></pre> </div> </div> <div class="paragraph"> <p>Les attributs <code>role="img"</code> et <code>aria-label</code> permettent aux technologies d’assistance de comprendre et décrire le contenu visuel.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_exemple_concret_documentation_de_thèmes">7. Exemple concret : Documentation de thèmes</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici un exemple complet documentant plusieurs thèmes :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">= Guide des couleurs de l'application == Thème Clair (`:root`) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#f8f9fa;border:1px solid #ccc;vertical-align:middle;margin-right:0.5em"></span>] --bg-primary: `#f8f9fa` (blanc cassé) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#212529;vertical-align:middle;margin-right:0.5em"></span>] --text-primary: `#212529` (noir très foncé) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#7952b3;vertical-align:middle;margin-right:0.5em"></span>] --accent-color: `#7952b3` (violet Bootstrap) == Thème Sombre (`[data-bs-theme="dark"]`) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#212529;vertical-align:middle;margin-right:0.5em"></span>] --bg-primary: `#212529` (noir très foncé) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#ffffff;border:1px solid #999;vertical-align:middle;margin-right:0.5em"></span>] --text-primary: `#ffffff` (blanc) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#0d6efd;vertical-align:middle;margin-right:0.5em"></span>] --accent-color: `#0d6efd` (bleu Bootstrap) == Thème Contraste Élevé (`[data-bs-theme="high-contrast"]`) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#000000;vertical-align:middle;margin-right:0.5em"></span>] --bg-primary: `#000000` (noir) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#ffffff;border:1px solid #000;vertical-align:middle;margin-right:0.5em"></span>] --text-primary: `#ffffff` (blanc) * pass:[<span style="display:inline-block;width:1em;height:1em;background:#00ff00;vertical-align:middle;margin-right:0.5em"></span>] --accent-color: `#00ff00` (vert vif)</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">8. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’injection HTML via la macro <code></code> d’AsciiDoc offre une solution élégante et pragmatique pour afficher des échantillons de couleur dans la documentation technique. Bien que légèrement verbeuse, cette approche garantit une portabilité maximale et une maintenance simplifiée.</p> </div> <div class="paragraph"> <p>Cette technique ne nécessite aucune configuration externe, aucune feuille de style additionnelle, et fonctionne immédiatement avec JBake et tous les processeurs AsciiDoc standard.</p> </div> <div class="paragraph"> <p>Une fois que vous avez créé votre premier carré coloré, il suffit de copier-coller le code HTML et de modifier le code hexadécimal pour créer rapidement une palette complète.</p> </div> <div class="paragraph"> <p>Cette technique peut être étendue à d’autres cas d’usage nécessitant du rendu visuel personnalisé : icônes, badges, graphiques simples, ou tout élément visuel nécessitant un contrôle précis du style.</p> </div> </div> </div> <div class="sect1"> <h2 id="_ressources">9. Ressources</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://docs.asciidoctor.org/asciidoc/latest/pass/pass-macro/" target="_blank" rel="noopener">Documentation AsciiDoc : pass macro</a></p> </li> <li> <p><a href="https://jbake.org/docs/2.6.7/" target="_blank" rel="noopener">JBake Documentation</a></p> </li> <li> <p><a href="https://developer.mozilla.org/fr/docs/Web/CSS/color_value" target="_blank" rel="noopener">MDN : Valeurs de couleur CSS</a></p> </li> </ul> </div> <hr> <div class="paragraph"> <p><em>Article publié le 2025-11-01</em></p> </div> </div> </div> https://pages-content.github.io//blog/2025/0095_i18n-site-statique-jbake-thymeleaf_post.html Mon, 20 Oct 2025 00:00:00 +0000 blog/2025/0095_i18n-site-statique-jbake-thymeleaf_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_cas_dusage_use_case">1.1. Diagramme de cas d’usage (Use Case)</a></li> </ul> </li> <li><a href="#_architecture_de_linternationalisation">2. Architecture de l’internationalisation</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_structure_organisation_des_fichiers">2.1. Diagramme de structure (Organisation des fichiers)</a></li> <li><a href="#_pourquoi_cette_approche">2.2. Pourquoi cette approche ?</a></li> <li><a href="#_diagramme_de_composants">2.3. Diagramme de composants</a></li> </ul> </li> <li><a href="#_i18n_du_templating_avec_thymeleaf">3. I18n du templating avec Thymeleaf</a> <ul class="sectlevel2"> <li><a href="#_structure_des_fichiers_de_messages">3.1. Structure des fichiers de messages</a></li> <li><a href="#_contenu_des_fichiers_de_messages">3.2. Contenu des fichiers de messages</a></li> <li><a href="#_utilisation_dans_les_templates">3.3. Utilisation dans les templates</a></li> <li><a href="#_diagramme_de_séquence_résolution_i18n">3.4. Diagramme de séquence - Résolution i18n</a></li> <li><a href="#_configuration_de_la_locale_dans_jbake">3.5. Configuration de la locale dans JBake</a></li> </ul> </li> <li><a href="#_i18n_des_articles_organisation_par_dossiers">4. I18n des articles : organisation par dossiers</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_flux_flow_génération">4.1. Diagramme de flux (Flow) - Génération</a></li> <li><a href="#_structure_des_dossiers">4.2. Structure des dossiers</a></li> <li><a href="#_avantages_de_cette_approche">4.3. Avantages de cette approche</a></li> <li><a href="#_métadonnées_des_articles">4.4. Métadonnées des articles</a></li> <li><a href="#_configuration_des_urls">4.5. Configuration des URLs</a></li> </ul> </li> <li><a href="#_templates_pour_laffichage_multilingue">5. Templates pour l’affichage multilingue</a> <ul class="sectlevel2"> <li><a href="#_template_darticle_avec_sélecteur_de_langue">5.1. Template d’article avec sélecteur de langue</a></li> <li><a href="#_index_filtré_par_langue">5.2. Index filtré par langue</a></li> </ul> </li> <li><a href="#_navigation_entre_langues">6. Navigation entre langues</a> <ul class="sectlevel2"> <li><a href="#_sélecteur_de_langue_global">6.1. Sélecteur de langue global</a></li> <li><a href="#_diagramme_de_flux_lecture_utilisateur">6.2. Diagramme de flux - Lecture utilisateur</a></li> <li><a href="#_style_css_pour_le_sélecteur">6.3. Style CSS pour le sélecteur</a></li> </ul> </li> <li><a href="#_flux_rss_par_langue">7. Flux RSS par langue</a></li> <li><a href="#_bonnes_pratiques_et_astuces">8. Bonnes pratiques et astuces</a> <ul class="sectlevel2"> <li><a href="#_1_cohérence_des_identifiants_darticle">8.1. 1. Cohérence des identifiants d’article</a></li> <li><a href="#_2_dates_cohérentes">8.2. 2. Dates cohérentes</a></li> <li><a href="#_3_tags_multilingues">8.3. 3. Tags multilingues</a></li> <li><a href="#_4_gestion_des_articles_non_traduits">8.4. 4. Gestion des articles non traduits</a></li> <li><a href="#_5_sitemap_multilingue">8.5. 5. Sitemap multilingue</a></li> </ul> </li> <li><a href="#_conclusion">9. Conclusion</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_déploiement">9.1. Diagramme de déploiement</a></li> </ul> </li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’internationalisation (i18n) d’un site statique peut sembler complexe au premier abord, mais JBake combiné avec Thymeleaf offre des solutions élégantes pour créer un site multilingue. Dans cet article, je vais vous montrer comment j’ai mis en place l’i18n sur mon blog, en couvrant à la fois le templating et la gestion des articles dans plusieurs langues.</p> </div> <div class="sect2"> <h3 id="_diagramme_de_cas_dusage_use_case">1.1. Diagramme de cas d’usage (Use Case)</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-c2a5be17bd909780be607cfd597f215f.png" alt="Diagram" width="660" height="447"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_de_linternationalisation">2. Architecture de l’internationalisation</h2> <div class="sectionbody"> <div class="paragraph"> <p>Notre approche repose sur deux piliers :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>L’i18n du templating</strong> : utilisation des fichiers de messages Thymeleaf pour les éléments d’interface</p> </li> <li> <p><strong>L’i18n du contenu</strong> : organisation des articles par langue dans une structure de dossiers dédiée</p> </li> </ol> </div> <div class="sect2"> <h3 id="_diagramme_de_structure_organisation_des_fichiers">2.1. Diagramme de structure (Organisation des fichiers)</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-2f100fc3ec2ec37f9556818cdc246602.png" alt="Diagram" width="188" height="513"> </div> </div> </div> <div class="sect2"> <h3 id="_pourquoi_cette_approche">2.2. Pourquoi cette approche ?</h3> <div class="paragraph"> <p>Cette séparation permet de :</p> </div> <div class="ulist"> <ul> <li> <p>Maintenir une cohérence dans l’interface quelle que soit la langue</p> </li> <li> <p>Gérer indépendamment le contenu et les traductions d’articles</p> </li> <li> <p>Faciliter l’ajout de nouvelles langues sans refactoring majeur</p> </li> <li> <p>Permettre des articles disponibles uniquement dans certaines langues</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_diagramme_de_composants">2.3. Diagramme de composants</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-9d42e1ff744debfc429aaa889922ac15.png" alt="Diagram" width="1771" height="477"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_i18n_du_templating_avec_thymeleaf">3. I18n du templating avec Thymeleaf</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_structure_des_fichiers_de_messages">3.1. Structure des fichiers de messages</h3> <div class="paragraph"> <p>La première étape consiste à créer les fichiers de propriétés pour chaque langue supportée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">src/jbake/templates/ ├── messages.properties # Fallback par défaut ├── messages_fr.properties # Français ├── messages_en.properties # Anglais └── messages_de.properties # Allemand</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_contenu_des_fichiers_de_messages">3.2. Contenu des fichiers de messages</h3> <div class="paragraph"> <p>Voici un exemple de fichier <code>messages_fr.properties</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-properties hljs" data-lang="properties"># Navigation nav.home=Accueil nav.blog=Blog nav.about=À propos nav.contact=Contact # Articles article.readmore=Lire la suite article.published=Publié le article.tags=Étiquettes article.also.available=Également disponible en # Interface site.title=Mon Blog Technique site.description=Partage de connaissances et expériences footer.copyright=© 2025 Tous droits réservés search.placeholder=Rechercher un article...</code></pre> </div> </div> <div class="paragraph"> <p>Et son équivalent anglais <code>messages_en.properties</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-properties hljs" data-lang="properties"># Navigation nav.home=Home nav.blog=Blog nav.about=About nav.contact=Contact # Articles article.readmore=Read more article.published=Published on article.tags=Tags article.also.available=Also available in # Interface site.title=My Tech Blog site.description=Sharing knowledge and experiences footer.copyright=© 2025 All rights reserved search.placeholder=Search articles...</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_utilisation_dans_les_templates">3.3. Utilisation dans les templates</h3> <div class="paragraph"> <p>Dans vos templates Thymeleaf, utilisez la syntaxe <code>#{}</code> pour accéder aux messages :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org"> <head> <title th:text="#{site.title}">Mon Blog</title> <meta name="description" th:content="#{site.description}" /> </head> <body> <nav> <a th:href="@{/}" th:text="#{nav.home}">Accueil</a> <a th:href="@{/blog/}" th:text="#{nav.blog}">Blog</a> <a th:href="@{/about.html}" th:text="#{nav.about}">À propos</a> </nav> <footer> <p th:text="#{footer.copyright}">Copyright</p> </footer> </body> </html></code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_diagramme_de_séquence_résolution_i18n">3.4. Diagramme de séquence - Résolution i18n</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-890efdf0cf45e6d957ea45af6e68a11d.png" alt="Diagram" width="910" height="882"> </div> </div> </div> <div class="sect2"> <h3 id="_configuration_de_la_locale_dans_jbake">3.5. Configuration de la locale dans JBake</h3> <div class="paragraph"> <p>Dans votre fichier <code>jbake.properties</code>, définissez la locale par défaut :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-properties hljs" data-lang="properties"># Locale par défaut thymeleaf.locale=fr # Encodage template.encoding=UTF-8</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_i18n_des_articles_organisation_par_dossiers">4. I18n des articles : organisation par dossiers</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_diagramme_de_flux_flow_génération">4.1. Diagramme de flux (Flow) - Génération</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-dc5f4bca87c443b337bf4e82c96c9a69.png" alt="Diagram" width="285" height="1034"> </div> </div> </div> <div class="sect2"> <h3 id="_structure_des_dossiers">4.2. Structure des dossiers</h3> <div class="paragraph"> <p>Plutôt que d’utiliser des suffixes dans les noms de fichiers, j’ai opté pour une organisation par dossiers qui offre plus de clarté et de maintenabilité :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">content/blog/ ├── 2024/ │ ├── fr/ │ │ ├── introduction-jbake.adoc │ │ ├── guide-thymeleaf.adoc │ │ └── astuces-asciidoc.adoc │ └── en/ │ ├── introduction-jbake.adoc │ ├── thymeleaf-guide.adoc │ └── asciidoc-tips.adoc └── 2025/ ├── fr/ │ └── internationalisation-jbake.adoc └── en/ └── jbake-internationalization.adoc</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_avantages_de_cette_approche">4.3. Avantages de cette approche</h3> <div class="paragraph"> <p>Cette structure présente plusieurs avantages :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Séparation claire</strong> : chaque langue a son propre espace</p> </li> <li> <p><strong>Nommage flexible</strong> : les fichiers peuvent avoir des noms différents selon la langue</p> </li> <li> <p><strong>Scalabilité</strong> : facile d’ajouter une nouvelle langue</p> </li> <li> <p><strong>Organisation naturelle</strong> : suit la logique temporelle de JBake</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_métadonnées_des_articles">4.4. Métadonnées des articles</h3> <div class="paragraph"> <p>Chaque article doit contenir des métadonnées pour permettre la liaison entre traductions. Voici un exemple :</p> </div> <div class="paragraph"> <p><strong>Version française</strong> (<code>2025/fr/internationalisation-jbake.adoc</code>) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">= Internationalisation d'un site statique JBake :jbake-type: post :jbake-status: published :jbake-date: 2025-10-20 :jbake-lang: fr :jbake-article-id: jbake-i18n-thymeleaf :jbake-tags: jbake, thymeleaf, i18n :jbake-description: Guide pour mettre en place l'i18n avec JBake</code></pre> </div> </div> <div class="paragraph"> <p><strong>Version anglaise</strong> (<code>2025/en/jbake-internationalization.adoc</code>) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">= Internationalizing a JBake Static Site :jbake-type: post :jbake-status: published :jbake-date: 2025-10-20 :jbake-lang: en :jbake-article-id: jbake-i18n-thymeleaf :jbake-tags: jbake, thymeleaf, i18n :jbake-description: Guide to implement i18n with JBake</code></pre> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> L’attribut <code>:jbake-article-id:</code> est crucial : il permet de lier les différentes traductions d’un même article. </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="_configuration_des_urls">4.5. Configuration des URLs</h3> <div class="paragraph"> <p>Dans <code>jbake.properties</code>, configurez le pattern d’URL pour inclure la langue :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-properties hljs" data-lang="properties"># Pattern d'URL avec langue post.permalink.pattern=:lang/blog/:year/:name.html # Langue par défaut site.default.lang=fr</code></pre> </div> </div> <div class="paragraph"> <p>Cela génèrera des URLs du type :</p> </div> <div class="ulist"> <ul> <li> <p><code>/fr/blog/2025/internationalisation-jbake.html</code></p> </li> <li> <p><code>/en/blog/2025/jbake-internationalization.html</code></p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_templates_pour_laffichage_multilingue">5. Templates pour l’affichage multilingue</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_template_darticle_avec_sélecteur_de_langue">5.1. Template d’article avec sélecteur de langue</h3> <div class="paragraph"> <p>Créez un template <code>post.html</code> qui affiche les traductions disponibles :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org"> <head> <title th:text="${content.title}">Article</title> </head> <body> <article> <header> <h1 th:text="${content.title}">Titre</h1> <div class="article-meta"> <time th:text="${#dates.format(content.date, 'dd MMMM yyyy')}" th:attr="datetime=${#dates.format(content.date, 'yyyy-MM-dd')}"> Date </time> <!-- Sélecteur de traductions --> <div class="translations" th:if="${content['article-id']}"> <span th:text="#{article.also.available}">Aussi disponible en :</span> <ul class="language-list"> <li th:each="post : ${published_posts}" th:if="${post['article-id'] == content['article-id'] and post.lang != content.lang}"> <a th:href="${post.uri}" th:text="${post.lang.toUpperCase()}"> LANG </a> </li> </ul> </div> </div> </header> <div class="content" th:utext="${content.body}"> Contenu de l'article </div> <footer class="article-footer"> <div class="tags" th:if="${content.tags}"> <span th:text="#{article.tags}">Étiquettes :</span> <span th:each="tag : ${content.tags}"> <a th:href="@{/tags/{tag}.html(tag=${tag})}" th:text="${tag}">tag</a> </span> </div> </footer> </article> </body> </html></code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_index_filtré_par_langue">5.2. Index filtré par langue</h3> <div class="paragraph"> <p>Créez des templates d’index pour chaque langue :</p> </div> <div class="paragraph"> <p><strong><code>index.html</code></strong> (index français) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org"> <head> <title th:text="#{site.title}">Mon Blog</title> </head> <body> <main> <h1 th:text="#{nav.blog}">Blog</h1> <div class="articles-list"> <article th:each="post : ${published_posts}" th:if="${post.lang == 'fr'}"> <h2> <a th:href="${post.uri}" th:text="${post.title}">Titre</a> </h2> <time th:text="${#dates.format(post.date, 'dd MMMM yyyy')}"> Date </time> <p th:text="${post.description}">Description</p> <a th:href="${post.uri}" th:text="#{article.readmore}"> Lire la suite </a> </article> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><strong><code>index_en.html</code></strong> (index anglais) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org"> <head> <title th:text="#{site.title}">My Blog</title> </head> <body> <main> <h1 th:text="#{nav.blog}">Blog</h1> <div class="articles-list"> <article th:each="post : ${published_posts}" th:if="${post.lang == 'en'}"> <h2> <a th:href="${post.uri}" th:text="${post.title}">Title</a> </h2> <time th:text="${#dates.format(post.date, 'dd MMMM yyyy')}"> Date </time> <p th:text="${post.description}">Description</p> <a th:href="${post.uri}" th:text="#{article.readmore}"> Read more </a> </article> </div> </main> </body> </html></code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_navigation_entre_langues">6. Navigation entre langues</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_sélecteur_de_langue_global">6.1. Sélecteur de langue global</h3> </div> <div class="sect2"> <h3 id="_diagramme_de_flux_lecture_utilisateur">6.2. Diagramme de flux - Lecture utilisateur</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-35c457cfbd1b9be0156f6bbbfb2925d1.png" alt="Diagram" width="494" height="761"> </div> </div> <div class="paragraph"> <p>Ajoutez un sélecteur de langue dans votre template principal :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><nav class="language-switcher"> <a href="/index.html" th:classappend="${content.lang == 'fr'} ? 'active'" title="Français"> 🇫🇷 FR </a> <a href="/en/index.html" th:classappend="${content.lang == 'en'} ? 'active'" title="English"> 🇬🇧 EN </a> </nav></code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_style_css_pour_le_sélecteur">6.3. Style CSS pour le sélecteur</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">.language-switcher { display: flex; gap: 1rem; padding: 0.5rem; background: #f5f5f5; border-radius: 4px; } .language-switcher a { padding: 0.5rem 1rem; text-decoration: none; color: #333; border-radius: 4px; transition: background 0.2s; } .language-switcher a:hover { background: #e0e0e0; } .language-switcher a.active { background: #007bff; color: white; } .translations { margin: 1rem 0; padding: 1rem; background: #f8f9fa; border-left: 4px solid #007bff; } .language-list { display: inline-flex; gap: 0.5rem; list-style: none; padding: 0; margin: 0; } .language-list li::after { content: "•"; margin-left: 0.5rem; } .language-list li:last-child::after { content: ""; }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_flux_rss_par_langue">7. Flux RSS par langue</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour avoir des flux RSS séparés par langue, créez des templates distincts :</p> </div> <div class="paragraph"> <p><strong><code>feed.xml</code></strong> (flux français) :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-xml hljs" data-lang="xml"><?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:th="http://www.thymeleaf.org"> <channel> <title th:text="#{site.title}">Mon Blog</title> <link th:text="${config.site_host}">http://example.com</link> <description th:text="#{site.description}">Description</description> <language>fr</language> <item th:each="post : ${published_posts}" th:if="${post.lang == 'fr'}"> <title th:text="${post.title}">Titre</title> <link th:text="${config.site_host + post.uri}">Lien</link> <pubDate th:text="${#dates.format(post.date, 'EEE, dd MMM yyyy HH:mm:ss Z')}"> Date </pubDate> <description th:text="${post.description}">Description</description> </item> </channel> </rss></code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_bonnes_pratiques_et_astuces">8. Bonnes pratiques et astuces</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_1_cohérence_des_identifiants_darticle">8.1. 1. Cohérence des identifiants d’article</h3> <div class="paragraph"> <p>Assurez-vous que <code>:jbake-article-id:</code> est identique pour toutes les traductions d’un même article. Utilisez un format cohérent :</p> </div> <div class="ulist"> <ul> <li> <p>Préférez les identifiants en anglais pour universalité</p> </li> <li> <p>Utilisez des tirets pour séparer les mots</p> </li> <li> <p>Évitez les caractères spéciaux</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_2_dates_cohérentes">8.2. 2. Dates cohérentes</h3> <div class="paragraph"> <p>Toutes les traductions d’un article doivent avoir la même date de publication (<code>:jbake-date:</code>). Cela facilite le tri et l’affichage chronologique.</p> </div> </div> <div class="sect2"> <h3 id="_3_tags_multilingues">8.3. 3. Tags multilingues</h3> <div class="paragraph"> <p>Pour les tags, vous avez deux options :</p> </div> <div class="paragraph"> <p><strong>Option 1 : Tags universels en anglais</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">:jbake-tags: java, spring-boot, microservices</code></pre> </div> </div> <div class="paragraph"> <p><strong>Option 2 : Tags traduits avec mapping</strong></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc"># Version française :jbake-tags: java, spring-boot, microservices # Version anglaise :jbake-tags: java, spring-boot, microservices</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_4_gestion_des_articles_non_traduits">8.4. 4. Gestion des articles non traduits</h3> <div class="paragraph"> <p>Il n’est pas obligatoire de traduire tous les articles. Si un article n’existe que dans une langue, il n’apparaîtra simplement pas dans les listings de l’autre langue.</p> </div> </div> <div class="sect2"> <h3 id="_5_sitemap_multilingue">8.5. 5. Sitemap multilingue</h3> <div class="paragraph"> <p>Générez un sitemap qui inclut toutes les langues :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-xml hljs" data-lang="xml"><?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:th="http://www.thymeleaf.org"> <url th:each="post : ${published_posts}"> <loc th:text="${config.site_host + post.uri}">URL</loc> <lastmod th:text="${#dates.format(post.date, 'yyyy-MM-dd')}">Date</lastmod> <!-- Liens alternatifs pour les traductions --> <xhtml:link th:each="translation : ${published_posts}" th:if="${translation['article-id'] == post['article-id'] and translation.lang != post.lang}" rel="alternate" th:attr="hreflang=${translation.lang},href=${config.site_host + translation.uri}" /> </url> </urlset></code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">9. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’internationalisation d’un site JBake avec Thymeleaf est une approche robuste et maintenable. En séparant l’i18n du templating (via les fichiers de messages) et l’i18n du contenu (via l’organisation en dossiers), vous obtenez un système flexible qui peut évoluer facilement.</p> </div> <div class="paragraph"> <p>Les points clés à retenir :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Fichiers de messages Thymeleaf</strong> pour l’interface utilisateur</p> </li> <li> <p><strong>Organisation par dossiers</strong> (année/langue) pour les articles</p> </li> <li> <p><strong>Identifiants d’article</strong> pour lier les traductions</p> </li> <li> <p><strong>Templates dédiés</strong> pour chaque langue</p> </li> <li> <p><strong>URLs explicites</strong> incluant le code de langue</p> </li> </ul> </div> <div class="sect2"> <h3 id="_diagramme_de_déploiement">9.1. Diagramme de déploiement</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-e93d75cf1c345b28883ab04c6a861e54.png" alt="Diagram" width="535" height="713"> </div> </div> <div class="paragraph"> <p>Cette architecture vous permet de démarrer simplement avec deux langues et d’en ajouter d’autres sans refactoring majeur. Le tout reste entièrement statique et performant, fidèle à la philosophie de JBake.</p> </div> <div class="paragraph"> <p>Bon développement multilingue ! 🌍</p> </div> </div> </div> </div> https://pages-content.github.io//blog/2025/0094_tor_browser_install_post.html Sun, 5 Oct 2025 00:00:00 +0000 blog/2025/0094_tor_browser_install_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_téléchargement_de_tor_et_de_sa_signature">2. Téléchargement de Tor et de sa signature</a></li> <li><a href="#_vérification_cryptographique_de_la_signature">3. Vérification cryptographique de la signature</a> <ul class="sectlevel2"> <li><a href="#_1_importer_la_clé_publique_du_tor_project">3.1. 1. Importer la clé publique du Tor Project</a></li> <li><a href="#_2_vérifier_la_signature">3.2. 2. Vérifier la signature</a></li> <li><a href="#_cas_pratique_signature_valide_mais_clé_non_certifiée">3.3. Cas pratique : Signature valide mais clé non certifiée</a></li> </ul> </li> <li><a href="#_pourquoi_vérifier_la_signature">4. Pourquoi vérifier la signature ?</a></li> <li><a href="#_extraction_et_lancement_de_tor_browser">5. Extraction et lancement de Tor Browser</a></li> <li><a href="#_intégration_au_bureau_ubuntu">6. Intégration au bureau Ubuntu</a></li> <li><a href="#_explorer_des_ressources_éducatives_avec_tor">7. Explorer des ressources éducatives avec Tor</a></li> <li><a href="#_mise_à_jour_de_tor_browser">8. Mise à jour de Tor Browser</a></li> <li><a href="#_conclusion">9. Conclusion</a></li> <li><a href="#_références">10. Références</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans un monde où la confidentialité numérique est de plus en plus menacée, <strong>Tor Browser</strong> reste un outil essentiel pour préserver son anonymat et sa liberté d’information. Cependant, il est crucial de ne jamais exécuter un logiciel téléchargé sans avoir <strong>vérifié son authenticité</strong>. Cet article présente une méthode complète pour :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Télécharger <strong>Tor Browser</strong> et sa signature <code>.asc</code></p> </li> <li> <p>Vérifier la validité du fichier téléchargé</p> </li> <li> <p>Installer et lancer <strong>Tor Browser</strong> sous Ubuntu</p> </li> <li> <p>L’ajouter aux menus du bureau pour un usage quotidien</p> </li> <li> <p>Explorer des ressources éducatives et OSINT éthiques via Tor</p> </li> </ol> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_téléchargement_de_tor_et_de_sa_signature">2. Téléchargement de Tor et de sa signature</h2> <div class="sectionbody"> <div class="paragraph"> <p>Créez un dossier dédié pour le navigateur Tor :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">mkdir -p ~/workspace/tipiak/tor cd ~/workspace/tipiak/tor</code></pre> </div> </div> <div class="paragraph"> <p>Téléchargez ensuite l’archive du navigateur Tor et sa signature :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">wget https://www.torproject.org/dist/torbrowser/14.5.7/tor-browser-linux-x86_64-14.5.7.tar.xz wget https://www.torproject.org/dist/torbrowser/14.5.7/tor-browser-linux-x86_64-14.5.7.tar.xz.asc</code></pre> </div> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_vérification_cryptographique_de_la_signature">3. Vérification cryptographique de la signature</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette étape est <strong>indispensable</strong> pour s’assurer que le fichier téléchargé provient bien du <strong>Tor Project</strong> et n’a pas été modifié.</p> </div> <div class="sect2"> <h3 id="_1_importer_la_clé_publique_du_tor_project">3.1. 1. Importer la clé publique du Tor Project</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org</code></pre> </div> </div> <div class="paragraph"> <p>Vérifiez que la clé est bien importée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">gpg --list-keys torbrowser@torproject.org</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_2_vérifier_la_signature">3.2. 2. Vérifier la signature</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">gpg --verify tor-browser-linux-x86_64-14.5.7.tar.xz.asc tor-browser-linux-x86_64-14.5.7.tar.xz</code></pre> </div> </div> <div class="paragraph"> <p>Si tout est correct, le message suivant s’affichera :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">gpg: Good signature from "Tor Browser Developers (signing key)"</code></pre> </div> </div> <div class="paragraph"> <p>En cas d’avertissement de clé non certifiée, cela signifie simplement que vous n’avez pas encore signé la clé de confiance du Tor Project, mais la signature reste valide.</p> </div> </div> <div class="sect2"> <h3 id="_cas_pratique_signature_valide_mais_clé_non_certifiée">3.3. Cas pratique : Signature valide mais clé non certifiée</h3> <div class="paragraph"> <p>Il est fréquent de rencontrer un message comme celui-ci lors de la vérification :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">gpg --verify tor-browser-linux-x86_64-14.5.7.tar.xz.asc tor-browser-linux-x86_64-14.5.7.tar.xz gpg: Signature faite le mar. 16 sept. 2025 14:26:26 CEST gpg: avec la clef RSA CAAE408AEBE2288E96FC5D5E157432CF78A65729 gpg: Bonne signature de « Tor Browser Developers (signing key) <torbrowser@torproject.org> » [inconnu] gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance. gpg: Rien n'indique que la signature appartient à son propriétaire. Empreinte de clef principale : EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290 Empreinte de la sous-clef : CAAE 408A EBE2 288E 96FC 5D5E 1574 32CF 78A6 5729</code></pre> </div> </div> <div class="paragraph"> <p>Ce message indique que la signature est techniquement "bonne" (le fichier n’a pas été altéré), mais que votre système GPG ne peut pas <strong>certifier la confiance</strong> en la clé elle-même. Pour lever ce doute, il est impératif de comparer l’empreinte de la clé principale (<code>EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290</code>) avec celle publiée sur le site officiel du Tor Project.</p> </div> <div class="paragraph"> <p>D’après le site officiel, l’empreinte attendue est : <code>EF6E286DDA85EA2A4BA7DE684E2C6E8793298290</code>.</p> </div> <div class="paragraph"> <p>Puisque l’empreinte affichée par <code>gpg</code> correspond <strong>exactement</strong> à celle du site officiel, vous pouvez être certain que la clé est légitime et que le fichier est sûr. L’avertissement de "clé non certifiée" est alors une information sur votre configuration GPG locale, et non sur la validité de la signature ou l’authenticité du fichier.</p> </div> <hr> </div> </div> </div> <div class="sect1"> <h2 id="_pourquoi_vérifier_la_signature">4. Pourquoi vérifier la signature ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>La vérification des signatures GPG est un acte fondamental de sécurité numérique. Elle permet de :</p> </div> <div class="ulist"> <ul> <li> <p>Garantir <strong>l’authenticité</strong> du logiciel téléchargé</p> </li> <li> <p>Empêcher l’installation d’un fichier compromis par un acteur malveillant</p> </li> <li> <p>Participer à la <strong>souveraineté numérique</strong> individuelle</p> </li> <li> <p>Favoriser une culture numérique responsable et éthique</p> </li> </ul> </div> <hr> <div class="imageblock"> <div class="content"> <img src="usecase-tor-verification.svg" alt="usecase tor verification" width="420" height="264"> </div> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_extraction_et_lancement_de_tor_browser">5. Extraction et lancement de Tor Browser</h2> <div class="sectionbody"> <div class="paragraph"> <p>Décompressez l’archive téléchargée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">tar -xvf tor-browser-linux-x86_64-14.5.7.tar.xz cd tor-browser</code></pre> </div> </div> <div class="paragraph"> <p>Lancez ensuite le navigateur :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">./start-tor-browser.desktop</code></pre> </div> </div> <div class="paragraph"> <p>Lors du premier lancement, une fenêtre de configuration s’ouvrira pour établir la connexion au réseau Tor.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_intégration_au_bureau_ubuntu">6. Intégration au bureau Ubuntu</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour ajouter <strong>Tor Browser</strong> dans le menu des applications :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">./start-tor-browser.desktop --register-app</code></pre> </div> </div> <div class="paragraph"> <p>Vous pouvez ensuite :</p> </div> <div class="ulist"> <ul> <li> <p>Lancer <strong>Tor Browser</strong> depuis le menu des applications</p> </li> <li> <p>L’ajouter aux favoris du dock</p> </li> <li> <p>Créer un raccourci clavier si souhaité</p> </li> </ul> </div> <hr> <div class="imageblock"> <div class="content"> <img src="activity-tor-installation.svg" alt="activity tor installation" width="457" height="470"> </div> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_explorer_des_ressources_éducatives_avec_tor">7. Explorer des ressources éducatives avec Tor</h2> <div class="sectionbody"> <div class="paragraph"> <p>Tor n’est pas uniquement un outil d’anonymat. Il constitue un portail d’accès à des ressources éducatives et de recherche, notamment dans les domaines de :</p> </div> <div class="ulist"> <ul> <li> <p><strong>OSINT (Open Source Intelligence)</strong></p> </li> <li> <p><a href="https://inteltechniques.com">https://inteltechniques.com</a></p> </li> <li> <p><a href="https://osintframework.com">https://osintframework.com</a></p> </li> <li> <p><strong>Partage éducatif et open source</strong></p> </li> <li> <p><a href="https://archive.org">https://archive.org</a> (accès via Tor pour plus de confidentialité)</p> </li> <li> <p><a href="https://github.com/">https://github.com/</a> (consultable via Tor)</p> </li> <li> <p><a href="https://librarygenesis.pro">https://librarygenesis.pro</a> (accès à la littérature scientifique libre)</p> </li> <li> <p><strong>Transmission de savoir et compréhension de l’humain dans la société numérique</strong></p> </li> <li> <p>Ressources sur la culture numérique, la liberté d’expression et l’accès à la connaissance</p> </li> <li> <p>Documentation libre sur la cybersécurité et l’éthique des technologies</p> </li> </ul> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_mise_à_jour_de_tor_browser">8. Mise à jour de Tor Browser</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour garantir une sécurité optimale, il est crucial de maintenir <strong>Tor Browser</strong> à jour. Le navigateur intègre un mécanisme de mise à jour automatique qui peut être déclenché en ligne de commande.</p> </div> <div class="paragraph"> <p>Depuis le répertoire d’installation de Tor Browser, il suffit de relancer le script de démarrage :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">cd ~/workspace/tipiak/tor/tor-browser ./start-tor-browser.desktop</code></pre> </div> </div> <div class="paragraph"> <p>Au lancement, <strong>Tor Browser</strong> vérifiera automatiquement s’il existe une nouvelle version. Si c’est le cas, il la téléchargera et l’installera pour vous.</p> </div> <div class="paragraph"> <p>Cette méthode simple assure que vous disposez toujours des derniers correctifs de sécurité et des améliorations les plus récentes, ce qui est essentiel pour une navigation sécurisée.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_conclusion">9. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vérifier ses téléchargements est un réflexe essentiel pour toute personne souhaitant évoluer dans un environnement numérique sûr. Installer Tor de manière vérifiée, c’est <strong>protéger son intégrité numérique</strong>, <strong>préserver la confiance dans les logiciels libres</strong>, et <strong>renforcer son autonomie informationnelle</strong>.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p><strong>La sécurité numérique est un acte de conscience, non de paranoïa.</strong></p> </div> </blockquote> </div> <hr> <div class="imageblock"> <div class="content"> <img src="summary-diagram.svg" alt="summary diagram" width="442" height="203"> </div> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_références">10. Références</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Site officiel du Tor Project : <a href="https://www.torproject.org/download/">https://www.torproject.org/download/</a></p> </li> <li> <p>Documentation de vérification des signatures : <a href="https://support.torproject.org/tbb/how-to-verify-signature/">https://support.torproject.org/tbb/how-to-verify-signature/</a></p> </li> <li> <p>Documentation Ubuntu : <a href="https://ubuntu.com">https://ubuntu.com</a></p> </li> <li> <p>Archive éducative : <a href="https://archive.org/details/opensource">https://archive.org/details/opensource</a></p> </li> </ul> </div> <hr> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Cet article fait partie de la série <strong>Sécurité et Conscience Numérique</strong>, visant à promouvoir des pratiques responsables et pédagogiques autour des outils libres.</p> </div> </td> </tr> </table> </div> </div> </div> https://pages-content.github.io//blog/2025/0093_gradle_plugin_toml_composite_build_post.html Sat, 27 Sep 2025 00:00:00 +0000 blog/2025/0093_gradle_plugin_toml_composite_build_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_1_le_catalogue_de_versions_libs_versions_toml_un_rappel">2. 1. Le Catalogue de Versions (<code>libs.versions.toml</code>) : Un Rappel</a></li> <li><a href="#_2_le_problème_un_build_composite_et_deux_mondes_séparés">3. 2. Le Problème : Un Build Composite et Deux Mondes Séparés</a></li> <li><a href="#_3_la_solution_partager_la_résolution_de_dépendances">4. 3. La Solution : Partager la Résolution de Dépendances</a></li> <li><a href="#_4_conclusion_la_puissance_des_builds_composites_bien_gérés">5. 4. Conclusion : La Puissance des Builds Composites Bien Gérés</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <div class="title">Public cible : Développeurs Gradle confrontés à la gestion de dépendances dans des projets multi-builds.</div> <p>Dans notre quête pour créer le plugin <code>site-baker</code>, nous avons cherché à maintenir une base de code propre et centralisée. L’une des meilleures pratiques dans l’écosystème Gradle moderne est l’utilisation du <strong>catalogue de versions</strong> (<code>libs.versions.toml</code>) pour gérer les dépendances. Mais que se passe-t-il lorsque votre projet devient plus complexe, comme un <strong>build composite</strong> où un build indépendant (notre plugin) doit être inclus dans un autre ?</p> </div> <div class="paragraph"> <p>C’est là que notre aventure a pris un tournant inattendu. Nous voulions que notre plugin <code>site-baker</code>, qui est lui-même un projet Gradle, utilise le même catalogue de versions que notre projet principal. Cet article, le cinquième de notre série, raconte comment nous avons résolu ce défi.</p> </div> </div> </div> <div class="sect1"> <h2 id="_1_le_catalogue_de_versions_libs_versions_toml_un_rappel">2. 1. Le Catalogue de Versions (<code>libs.versions.toml</code>) : Un Rappel</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le fichier <code>gradle/libs.versions.toml</code> est une fonctionnalité de Gradle qui permet de centraliser les versions et les coordonnées des dépendances de votre projet. Il est généralement structuré en quatre sections :</p> </div> <div class="ulist"> <ul> <li> <p><code>[versions]</code> : Définit des alias pour les numéros de version (ex: <code>kotlin = "1.9.20"</code>).</p> </li> <li> <p><code>[libraries]</code> : Définit des alias pour les dépendances complètes, en utilisant les versions définies ci-dessus (ex: <code>kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }</code>).</p> </li> <li> <p><code>[bundles]</code> : Regroupe plusieurs bibliothèques sous un seul alias (ex: <code>jackson = ["jackson-core", "jackson-databind"]</code>).</p> </li> <li> <p><code>[plugins]</code> : Définit des alias pour les plugins Gradle.</p> </li> </ul> </div> <div class="paragraph"> <p>Une fois défini, Gradle génère automatiquement des accesseurs typés, ce qui rend votre <code>build.gradle.kts</code> beaucoup plus lisible :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">dependencies { // Au lieu de : implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.20") implementation(libs.kotlin.stdlib) }</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="toml-flow.svg" alt="toml flow" width="478" height="252"> </div> <div class="title">Figure 1. Flux de données du catalogue de versions</div> </div> </div> </div> <div class="sect1"> <h2 id="_2_le_problème_un_build_composite_et_deux_mondes_séparés">3. 2. Le Problème : Un Build Composite et Deux Mondes Séparés</h2> <div class="sectionbody"> <div class="paragraph"> <p>Notre structure de projet est un <strong>build composite</strong>. Le projet principal (<code>thymeleaf.cheroliv.com</code>) inclut le projet du plugin (<code>site-baker</code>) via la commande <code>includeBuild("site-baker")</code> dans le fichier <code>settings.gradle.kts</code>.</p> </div> <div class="imageblock"> <div class="content"> <img src="composite-build.svg" alt="composite build" width="604" height="246"> </div> <div class="title">Figure 2. Structure du build composite</div> </div> <div class="paragraph"> <p>Le problème est que, par défaut, un build inclus est un <strong>monde séparé</strong>. Il a sa propre configuration, son propre cycle de vie, et il ne voit pas le fichier <code>libs.versions.toml</code> du build principal. Notre <code>plugin/build.gradle.kts</code> essayait d’utiliser <code>libs.plugins.kotlin.jvm</code>, mais l’objet <code>libs</code> n’était pas généré à partir du bon fichier TOML, provoquant des erreurs de build.</p> </div> </div> </div> <div class="sect1"> <h2 id="_3_la_solution_partager_la_résolution_de_dépendances">4. 3. La Solution : Partager la Résolution de Dépendances</h2> <div class="sectionbody"> <div class="paragraph"> <p>Après plusieurs recherches, la solution s’est avérée être une fonctionnalité de Gradle conçue précisément pour ce cas : <code>dependencyResolutionManagement</code>.</p> </div> <div class="paragraph"> <p>Dans le fichier <code>settings.gradle.kts</code> du <strong>build inclus</strong> (<code>site-baker/settings.gradle.kts</code>), nous pouvons dire à Gradle où trouver le catalogue de versions à utiliser.</p> </div> <div class="paragraph"> <p>Voici la configuration que nous avons ajoutée à <code>site-baker/settings.gradle.kts</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// site-baker/settings.gradle.kts dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { gradlePluginPortal() mavenCentral() } versionCatalogs { create("libs") { from(files("../gradle/libs.versions.toml")) } } } rootProject.name = "site-baker" include("plugin")</code></pre> </div> </div> <div class="paragraph"> <p>Analysons la partie cruciale :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">versionCatalogs { create("libs") { // Crée un catalogue nommé 'libs' from(files("../gradle/libs.versions.toml")) // En utilisant ce fichier } }</code></pre> </div> </div> <div class="ulist"> <ul> <li> <p><code>create("libs")</code> : Nous déclarons un catalogue de versions qui sera accessible via l’alias <code>libs</code>.</p> </li> <li> <p><code>from(files("../gradle/libs.versions.toml"))</code> : C’est la magie. Nous indiquons à Gradle que la source de ce catalogue est le fichier TOML situé dans le répertoire <code>gradle</code> du <strong>projet parent</strong> (<code>../</code>).</p> </li> </ul> </div> <div class="paragraph"> <p>Avec cette configuration, le build <code>site-baker</code> sait maintenant qu’il doit utiliser le catalogue de versions du projet principal. L’objet <code>libs</code> est généré correctement, et les dépendances sont résolues comme prévu.</p> </div> </div> </div> <div class="sect1"> <h2 id="_4_conclusion_la_puissance_des_builds_composites_bien_gérés">5. 4. Conclusion : La Puissance des Builds Composites Bien Gérés</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette expérience a été riche en enseignements. Le catalogue de versions est un outil fantastique pour la maintenabilité, mais son comportement dans des scénarios de builds composites n’est pas toujours intuitif.</p> </div> <div class="paragraph"> <p>La clé est de se rappeler qu’un build inclus reste un build indépendant. Pour partager des configurations comme le catalogue de versions, il faut utiliser les mécanismes explicites fournis par Gradle, comme le bloc <code>dependencyResolutionManagement</code> dans <code>settings.gradle.kts</code>.</p> </div> <div class="paragraph"> <p>En résolvant ce problème, nous avons non seulement rendu notre build plus propre, mais nous avons aussi renforcé la cohérence de notre projet en nous assurant que le plugin et le projet principal partagent une source unique de vérité pour leurs dépendances.</p> </div> <div class="paragraph"> <p>Dans le prochain article, nous continuerons à enrichir notre plugin en y ajoutant des tâches plus complexes, maintenant que notre gestion des dépendances est solide et centralisée.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0092_gradle_configuration_cache_post.html Fri, 26 Sep 2025 00:00:00 +0000 blog/2025/0092_gradle_configuration_cache_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_le_symptôme_des_builds_fantômes">2. Le Symptôme : Des Builds Fantômes</a></li> <li><a href="#_lenquête_quest_ce_que_le_cache_de_configuration">3. L’Enquête : Qu’est-ce que le Cache de Configuration ?</a></li> <li><a href="#_la_cause_du_problème_un_plugin_non_conforme">4. La Cause du Problème : Un Plugin Non Conforme</a></li> <li><a href="#_la_solution_temporaire_désactiver_le_cache">5. La Solution Temporaire : Désactiver le Cache</a></li> <li><a href="#_la_vraie_solution_rendre_le_plugin_compatible">6. La Vraie Solution : Rendre le Plugin Compatible</a></li> <li><a href="#_conclusion">7. Conclusion</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <div class="title">Public cible : Développeurs Gradle ayant déjà rencontré des comportements de build "magiques" ou inattendus.</div> <p>Dans notre aventure de création du plugin <code>site-baker</code>, nous avons suivi une approche TDD rigoureuse. Chaque fonctionnalité était testée, validée, et nous avancions avec confiance. Et puis, un jour, l’imprévu est arrivé. Les builds ont commencé à se comporter de manière erratique. Des modifications dans la logique du plugin ou dans les fichiers de configuration semblaient être ignorées, et nos tests fonctionnels, autrefois fiables, échouaient sans raison apparente.</p> </div> <div class="paragraph"> <p>Ce genre de problème peut être incroyablement frustrant. Il remet en question la fiabilité de l’outil et la validité de notre code. Après une session de débogage intense, le coupable a été identifié : le <strong>cache de configuration de Gradle</strong>.</p> </div> </div> </div> <div class="sect1"> <h2 id="_le_symptôme_des_builds_fantômes">2. Le Symptôme : Des Builds Fantômes</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le problème se manifestait de plusieurs manières :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Je modifiais une chaîne de caractères dans une tâche <code>println</code>, mais l’ancienne chaîne continuait de s’afficher à l’exécution.</p> </li> <li> <p>Je changeais une valeur dans mon fichier <code>managed-jbake-context.yml</code>, mais le plugin agissait comme si le fichier n’avait pas été modifié.</p> </li> <li> <p>Les tests fonctionnels, qui créent des projets de test à la volée, échouaient parce que le plugin ne semblait pas détecter les fichiers de configuration fraîchement créés.</p> </li> </ol> </div> <div class="paragraph"> <p>Tout se passait comme si Gradle exécutait une "version fantôme" de notre build, ignorant nos changements les plus récents.</p> </div> </div> </div> <div class="sect1"> <h2 id="_lenquête_quest_ce_que_le_cache_de_configuration">3. L’Enquête : Qu’est-ce que le Cache de Configuration ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le cache de configuration est une fonctionnalité relativement moderne et extrêmement puissante de Gradle, activée par défaut dans les nouvelles versions. Son objectif est de rendre les builds plus rapides.</p> </div> <div class="olist arabic"> <div class="title">Le principe est simple :</div> <ol class="arabic"> <li> <p>Lors de la première exécution, Gradle exécute la phase de <strong>Configuration</strong> (lecture des <code>build.gradle.kts</code>, création des tâches, résolution des dépendances) et construit un graphe de tâches.</p> </li> <li> <p>À la fin de cette phase, Gradle <strong>sérialise ce graphe de tâches</strong> et le met en cache.</p> </li> <li> <p>Lors des exécutions suivantes, si rien n’a changé (scripts de build, <code>gradle.properties</code>, etc.), Gradle <strong>saute complètement la phase de configuration</strong> et réutilise le graphe de tâches mis en cache.</p> </li> </ol> </div> <div class="paragraph"> <p>Le gain de temps est spectaculaire sur les gros projets. Cependant, cette performance a un prix : elle impose des règles strictes sur la manière dont les plugins doivent être écrits.</p> </div> <div class="imageblock"> <div class="content"> <img src="config-cache-lifecycle.svg" alt="config cache lifecycle" width="661" height="709"> </div> <div class="title">Figure 1. Le cycle de vie du cache de configuration</div> </div> </div> </div> <div class="sect1"> <h2 id="_la_cause_du_problème_un_plugin_non_conforme">4. La Cause du Problème : Un Plugin Non Conforme</h2> <div class="sectionbody"> <div class="paragraph"> <p>Notre plugin <code>site-baker</code> violait, sans le savoir, plusieurs règles du cache de configuration. Pour qu’un graphe de tâches soit sérialisable, les tâches ne doivent pas contenir de références à des objets complexes comme l’objet <code>Project</code> ou lire des fichiers de manière arbitraire pendant la phase d’exécution.</p> </div> <div class="paragraph"> <p>Notre erreur principale était de lire le contenu du fichier YAML directement à l’intérieur de la logique d’exécution de la tâche, en utilisant une référence au chemin stocké dans notre extension. Cette approche est incompatible avec le cache car Gradle ne peut pas savoir si le contenu du fichier a changé si cette lecture n’est pas modélisée comme une <strong>entrée de tâche</strong> (Task Input).</p> </div> </div> </div> <div class="sect1"> <h2 id="_la_solution_temporaire_désactiver_le_cache">5. La Solution Temporaire : Désactiver le Cache</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour nous débloquer et retrouver un comportement de build prévisible, la solution la plus rapide a été de désactiver le cache de configuration. Il suffit d’ajouter la ligne suivante dans le fichier <code>gradle.properties</code> du projet qui utilise le plugin (ou dans notre cas, le projet de test <code>site-baker</code>).</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-properties hljs" data-lang="properties"># site-baker/gradle.properties org.gradle.configuration-cache=false</code></pre> </div> </div> <div class="paragraph"> <p>Instantanément, les builds ont retrouvé leur comportement normal. Chaque exécution relançait la phase de configuration et nos changements étaient pris en compte.</p> </div> <div class="paragraph"> <p>Cependant, c’est une solution de contournement, pas une solution durable. Elle sacrifie la performance et ne résout pas le problème de fond de notre plugin.</p> </div> </div> </div> <div class="sect1"> <h2 id="_la_vraie_solution_rendre_le_plugin_compatible">6. La Vraie Solution : Rendre le Plugin Compatible</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour qu’un plugin soit un bon citoyen de l’écosystème Gradle moderne, il doit être compatible avec le cache de configuration. Cela implique de repenser la manière dont les données circulent vers nos tâches.</p> </div> <div class="paragraph"> <p>La clé est d’utiliser les <strong>Provider APIs</strong> de Gradle. Au lieu de passer des valeurs directes (comme un <code>String</code> ou un <code>File</code>) à nos tâches, nous devons passer des <code>Property<T></code> ou des <code>Provider<T></code>.</p> </div> <div class="olist arabic"> <div class="title">Voici le plan de refactoring :</div> <ol class="arabic"> <li> <p><strong>Déclarer les entrées de tâches :</strong> La tâche qui parse le fichier YAML doit déclarer ce fichier comme une entrée. On utilise pour cela l’annotation <code>@InputFile</code>. [source,kotlin] ---- @get:InputFile abstract val configFile: RegularFileProperty ----</p> </li> <li> <p><strong>Utiliser les <code>Property</code> et <code>Provider</code> :</strong> La valeur de <code>configFile</code> sera connectée à la propriété <code>configPath</code> de notre extension DSL. Gradle est ainsi capable de tracer la provenance de la donnée. [source,kotlin] ---- // Dans le plugin tasks.register<MyTask>("myTask") { configFile.set(extension.configPath.flatMap { project.layout.projectDirectory.file(it) }) } ----</p> </li> <li> <p><strong>Lire le contenu au bon moment :</strong> La lecture du fichier doit se faire à l’intérieur de l’action de la tâche (<code>@TaskAction</code>), en utilisant le <code>Provider</code> de l’entrée. [source,kotlin] ---- @TaskAction fun execute() { val content = configFile.get().asFile.readText() // …​ parser le contenu } ----</p> </li> </ol> </div> <div class="paragraph"> <p>En suivant ce modèle, Gradle comprend que si le contenu de <code>configFile</code> change, le cache de configuration est invalide et la phase de configuration doit être ré-exécutée. De plus, il sait que la sortie de la tâche dépend du contenu de ce fichier, ce qui permet également d’optimiser le cache d’exécution (<code>UP-TO-DATE</code>).</p> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">7. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette aventure de débogage a été une leçon précieuse. Le comportement "magique" du cache de configuration nous a forcés à mieux comprendre le cycle de vie de Gradle et les principes de la programmation déclarative et paresseuse (<code>lazy</code>).</p> </div> <div class="paragraph"> <p>Désactiver le cache de configuration est un outil de diagnostic utile, mais la véritable solution est de concevoir des plugins robustes et modernes. En modélisant correctement les entrées et sorties de nos tâches avec les APIs <code>Provider</code>, nous ne corrigeons pas seulement un bug, nous améliorons la performance, la fiabilité et la maintenabilité de notre plugin.</p> </div> <div class="paragraph"> <p>Dans le prochain article, nous mettrons en pratique ce refactoring pour rendre notre tâche de parsing YAML entièrement compatible avec le cache de configuration.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0091_jackson_yaml_tdd_post.html Thu, 25 Sep 2025 00:00:00 +0000 blog/2025/0091_jackson_yaml_tdd_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_1_le_contexte_notre_plugin_site_baker">2. 1. Le Contexte : Notre Plugin <code>site-baker</code></a></li> <li><a href="#_2_modélisation_de_la_configuration_en_kotlin">3. 2. Modélisation de la Configuration en Kotlin</a></li> <li><a href="#_3_intégration_de_jackson_dans_le_build_gradle_kts">4. 3. Intégration de Jackson dans le <code>build.gradle.kts</code></a></li> <li><a href="#_4_lapproche_tdd_tester_le_parsing_yaml">5. 4. L’Approche TDD : Tester le Parsing YAML</a> <ul class="sectlevel2"> <li><a href="#_4_1_test_unitaire_mapper_le_yaml_en_objet_kotlin">5.1. 4.1. Test Unitaire : Mapper le YAML en Objet Kotlin</a></li> <li><a href="#_4_2_test_fonctionnel_valider_la_lecture_du_fichier_de_configuration">5.2. 4.2. Test Fonctionnel : Valider la Lecture du Fichier de Configuration</a></li> </ul> </li> <li><a href="#_5_visualisation_du_flux_de_parsing">6. 5. Visualisation du Flux de Parsing</a></li> <li><a href="#_conclusion">7. Conclusion</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <div class="title">Public cible : Développeurs Gradle intermédiaires souhaitant gérer des configurations complexes.</div> <p>Dans le développement de plugins Gradle, la gestion de configurations complexes est une tâche courante. Plutôt que de surcharger le DSL avec des centaines de propriétés, il est souvent plus propre et plus maintenable de définir la configuration dans un fichier externe, comme le YAML. Cet article vous guide à travers l’intégration de la puissante bibliothèque Jackson pour parser des fichiers YAML en objets Kotlin, en adoptant une approche TDD rigoureuse pour garantir la robustesse de notre plugin <code>site-baker</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="_1_le_contexte_notre_plugin_site_baker">2. 1. Le Contexte : Notre Plugin <code>site-baker</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>Notre plugin <code>site-baker</code> est conçu pour automatiser la génération et le déploiement d’un site statique. Il a besoin de lire un fichier de configuration YAML (<code>managed-jbake-context.yml</code>) pour obtenir des informations telles que les chemins des sources, les destinations de déploiement, et les identifiants Git.</p> </div> <div class="paragraph"> <p>La configuration YAML que nous souhaitons parser ressemble à ceci :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-yaml hljs" data-lang="yaml">bake: srcPath: "./site/jbake" destDirPath: "bake" cname: "cheroliv.com" pushPage: from: "bake" to: "cvs" repo: name: "trainings" repository: "https://github.com/pages-content/pages-content.github.io.git" credentials: username: "USERNAME" password: "SECRET_TOKEN" branch: "main" message: "cheroliv.com" # ... autres configurations (pushMaquette, supabase, etc.)</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_2_modélisation_de_la_configuration_en_kotlin">3. 2. Modélisation de la Configuration en Kotlin</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant de parser, nous devons définir la structure de nos données en Kotlin. Jackson utilisera ces classes pour mapper automatiquement le contenu YAML.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// plugin/src/main/kotlin/com/cheroliv/site/baker/data/SiteConfiguration.kt package com.cheroliv.site.baker.data import com.fasterxml.jackson.databind.ObjectMapper import com.fasterxml.jackson.dataformat.yaml.YAMLFactory import com.fasterxml.jackson.module.kotlin.readValue import com.fasterxml.jackson.module.kotlin.registerKotlinModule fun parseSiteConfiguration(yaml: String): SiteConfiguration { val mapper = ObjectMapper(YAMLFactory()).registerKotlinModule() return mapper.readValue(yaml) } data class GitPushConfiguration( val from: String = "", val to: String = "", val repo: RepositoryConfiguration = RepositoryConfiguration(), val branch: String = "", val message: String = "", ) data class RepositoryConfiguration( val name: String = "", val repository: String = "", val credentials: RepositoryCredentials = RepositoryCredentials(), ) { companion object { const val ORIGIN = "origin" const val CNAME = "CNAME" const val REMOTE = "remote" } } data class RepositoryCredentials(val username: String = "", val password: String = "") data class SiteConfiguration( val bake: BakeConfiguration = BakeConfiguration(), val pushPage: GitPushConfiguration = GitPushConfiguration(), val pushMaquette: GitPushConfiguration = GitPushConfiguration(), val pushSource: GitPushConfiguration? = null, val pushTemplate: GitPushConfiguration? = null, val supabase: SupabaseContactFormConfig? = null ) data class BakeConfiguration( val srcPath: String = "", val destDirPath: String = "", val cname: String? = null, ) // ... (autres data classes pour Supabase, si nécessaire)</code></pre> </div> </div> <div class="paragraph"> <p>La fonction <code>parseSiteConfiguration</code> est notre point d’entrée pour la désérialisation. Elle utilise <code>ObjectMapper</code> de Jackson, configuré avec <code>YAMLFactory</code> pour le format YAML et <code>registerKotlinModule()</code> pour le support des spécificités de Kotlin (comme les valeurs par défaut des propriétés).</p> </div> </div> </div> <div class="sect1"> <h2 id="_3_intégration_de_jackson_dans_le_build_gradle_kts">4. 3. Intégration de Jackson dans le <code>build.gradle.kts</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour utiliser Jackson, nous devons ajouter les dépendances nécessaires dans le <code>build.gradle.kts</code> de notre module <code>plugin</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// plugin/build.gradle.kts dependencies { // Jackson for YAML parsing implementation("com.fasterxml.jackson.module:jackson-module-kotlin:2.18.3") implementation("com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.18.3") // ... autres dépendances }</code></pre> </div> </div> <div class="paragraph"> <p>Nous utilisons <code>jackson-module-kotlin</code> pour le support de Kotlin et <code>jackson-dataformat-yaml</code> pour la gestion du format YAML.</p> </div> </div> </div> <div class="sect1"> <h2 id="_4_lapproche_tdd_tester_le_parsing_yaml">5. 4. L’Approche TDD : Tester le Parsing YAML</h2> <div class="sectionbody"> <div class="paragraph"> <p>Maintenant, appliquons le TDD pour valider notre logique de parsing.</p> </div> <div class="sect2"> <h3 id="_4_1_test_unitaire_mapper_le_yaml_en_objet_kotlin">5.1. 4.1. Test Unitaire : Mapper le YAML en Objet Kotlin</h3> <div class="paragraph"> <p>Nous commençons par un test unitaire dans <code>SiteBakerPluginTest.kt</code> pour vérifier que la fonction <code>parseSiteConfiguration</code> peut correctement transformer une chaîne YAML en un objet <code>SiteConfiguration</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// plugin/src/test/kotlin/com/cheroliv/site/baker/SiteBakerPluginTest.kt @Test fun `can map configuration text to SiteConfiguration object`() { val yamlString = "../../managed-jbake-context.yml" .run(::File) .readText() .trimIndent() val config: SiteConfiguration = parseSiteConfiguration(yamlString) assertEquals("cheroliv.com", config.bake.cname) assertEquals("main", config.pushPage.branch) assertEquals("https://github.com/pages-content/pages-content.github.io.git", config.pushPage.repo.repository) }</code></pre> </div> </div> <div class="paragraph"> <p>Ce test lit le contenu du fichier <code>managed-jbake-context.yml</code> (qui doit exister pour que le test soit valide) et effectue des assertions sur l’objet <code>SiteConfiguration</code> résultant. Il valide que les valeurs clés du YAML sont correctement mappées.</p> </div> </div> <div class="sect2"> <h3 id="_4_2_test_fonctionnel_valider_la_lecture_du_fichier_de_configuration">5.2. 4.2. Test Fonctionnel : Valider la Lecture du Fichier de Configuration</h3> <div class="paragraph"> <p>Pour s’assurer que le plugin peut lire le fichier de configuration via son DSL et que le parsing fonctionne dans un environnement Gradle réel, nous ajoutons un test fonctionnel dans <code>SiteBakerPluginFunctionalTest.kt</code>.</p> </div> <div class="paragraph"> <p>Ce test est crucial car il simule l’exécution du plugin dans un projet réel. Il doit être <strong>hermétique</strong>, c’est-à-dire qu’il doit créer lui-même le fichier <code>managed-jbake-context.yml</code> avec un contenu contrôlé, pour garantir la reproductibilité et l’isolation du test.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// plugin/src/functionalTest/kotlin/com/cheroliv/site/baker/SiteBakerPluginFunctionalTest.kt @Test fun `config file contains good data`(){ val configContent = configFile.readText(UTF_8) // Vérifications comme dans vos commentaires assertTrue(configContent.contains("bake")) assertTrue(configContent.contains("pushPage")) assertTrue(configContent.contains("repository")) }</code></pre> </div> </div> <div class="paragraph"> <p>Ce test fonctionnel vérifie que le fichier de configuration copié dans le répertoire temporaire du test contient les données attendues. Bien que ce test ne parse pas directement le YAML en objet Kotlin, il valide la présence du fichier et de son contenu, ce qui est une étape préalable essentielle au parsing par le plugin.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_5_visualisation_du_flux_de_parsing">6. 5. Visualisation du Flux de Parsing</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le diagramme suivant illustre le flux de données et les interactions lors du parsing de la configuration YAML :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-0994e4ea85b7366b45651fc9303bc947.png" alt="Diagram" width="1523" height="472"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">7. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>En suivant une approche TDD, nous avons intégré avec succès la bibliothèque Jackson pour parser des fichiers de configuration YAML en objets Kotlin au sein de notre plugin Gradle. Cette méthode nous a permis de :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Modéliser clairement</strong> notre configuration avec des data classes Kotlin.</p> </li> <li> <p><strong>Valider la logique de parsing</strong> avec des tests unitaires ciblés.</p> </li> <li> <p><strong>Assurer l’intégration</strong> dans un environnement Gradle réel grâce à des tests fonctionnels hermétiques.</p> </li> </ul> </div> <div class="paragraph"> <p>Cette base solide nous offre une grande confiance pour étendre notre plugin avec des fonctionnalités qui s’appuient sur cette configuration, tout en garantissant la maintenabilité et la robustesse du code. Le parsing YAML est désormais une fonctionnalité fiable et testée de notre plugin <code>site-baker</code>.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0090_TDD_gradle_plugin_post.html Wed, 24 Sep 2025 00:00:00 +0000 blog/2025/0090_TDD_gradle_plugin_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_1_linitialisation_du_projet">1. 1. L’Initialisation du Projet</a></li> <li><a href="#_2_notre_premier_cycle_tdd_enregistrer_une_tâche">2. 2. Notre Premier Cycle TDD : Enregistrer une Tâche</a> <ul class="sectlevel2"> <li><a href="#_2_1_le_test_dabord_le_test_qui_échoue">2.1. 2.1. Le Test d’Abord (Le Test qui Échoue)</a></li> <li><a href="#_2_2_le_code_ensuite_faire_passer_le_test">2.2. 2.2. Le Code Ensuite (Faire Passer le Test)</a></li> </ul> </li> <li><a href="#_3_deuxième_cycle_tdd_ajouter_une_extension_dsl">3. 3. Deuxième Cycle TDD : Ajouter une Extension DSL</a> <ul class="sectlevel2"> <li><a href="#_3_1_le_test_dabord">3.1. 3.1. Le Test d’Abord</a></li> <li><a href="#_3_2_le_code_ensuite">3.2. 3.2. Le Code Ensuite</a></li> </ul> </li> <li><a href="#_4_le_test_fonctionnel_valider_lintégration">4. 4. Le Test Fonctionnel : Valider l’Intégration</a> <ul class="sectlevel2"> <li><a href="#_4_1_le_test_dintégration_créer_un_environnement_contrôlé">4.1. 4.1. Le Test d’Intégration : Créer un Environnement Contrôlé</a></li> <li><a href="#_4_2_finaliser_la_logique">4.2. 4.2. Finaliser la Logique</a></li> </ul> </li> <li><a href="#_conclusion">5. Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>Dans cet article, nous allons explorer comment mettre en place une base de développement solide pour un plugin Gradle en utilisant une approche de Développement Guidé par les Tests (TDD - Test-Driven Development). Cette méthode nous assure que notre code est robuste, maintenable et répond précisément aux exigences dès le départ.</p> </div> </div> </div> <div class="sect1"> <h2 id="_1_linitialisation_du_projet">1. 1. L’Initialisation du Projet</h2> <div class="sectionbody"> <div class="paragraph"> <p>Gradle facilite grandement la création d’un nouveau plugin grâce à la commande <code>gradle init</code>. En choisissant de créer un "Gradle Plugin" avec Kotlin, nous obtenons une structure de projet prête à l’emploi, incluant deux types de tests cruciaux :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Tests Unitaires :</strong> Situés dans <code>src/test</code>, ils permettent de valider des composants isolés de notre plugin, comme la logique interne d’une tâche ou la configuration d’une extension. Ils sont rapides et n’ont pas besoin d’une exécution complète de Gradle.</p> </li> <li> <p><strong>Tests Fonctionnels :</strong> Situés dans <code>src/functionalTest</code>, ils utilisent <code>GradleRunner</code> pour exécuter une build Gradle complète dans un projet de test temporaire. Cela nous permet de vérifier le comportement réel du plugin dans un environnement contrôlé.</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_2_notre_premier_cycle_tdd_enregistrer_une_tâche">2. 2. Notre Premier Cycle TDD : Enregistrer une Tâche</h2> <div class="sectionbody"> <div class="paragraph"> <p>Notre première exigence est simple : le plugin doit enregistrer une tâche nommée <code>printSiteConfig</code>.</p> </div> <div class="sect2"> <h3 id="_2_1_le_test_dabord_le_test_qui_échoue">2.1. 2.1. Le Test d’Abord (Le Test qui Échoue)</h3> <div class="paragraph"> <p>Conformément au TDD, nous écrivons d’abord un test qui vérifie l’existence de cette tâche. Dans <code>SiteBakerPluginTest.kt</code> (notre fichier de test unitaire), nous ajoutons :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `plugin registers task`() { // Créer un projet de test en mémoire val project = ProjectBuilder.builder().build() project.plugins.apply("com.cheroliv.site-baker") // Vérifier que la tâche a bien été enregistrée assertNotNull(project.tasks.findByName("printSiteConfig")) }</code></pre> </div> </div> <div class="paragraph"> <p>Ce test échoue, car nous n’avons encore écrit aucun code dans notre plugin.</p> </div> </div> <div class="sect2"> <h3 id="_2_2_le_code_ensuite_faire_passer_le_test">2.2. 2.2. Le Code Ensuite (Faire Passer le Test)</h3> <div class="paragraph"> <p>Maintenant, nous écrivons le minimum de code nécessaire dans <code>SiteBakerPlugin.kt</code> pour que le test passe :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class SiteBakerPlugin: Plugin<Project> { override fun apply(project: Project) { // Enregistrer une tâche simple project.tasks.register("printSiteConfig") { task -> // ... la logique de la tâche viendra plus tard } } }</code></pre> </div> </div> <div class="paragraph"> <p>Nous relançons les tests, et ils passent. Notre première fonctionnalité est validée.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_3_deuxième_cycle_tdd_ajouter_une_extension_dsl">3. 3. Deuxième Cycle TDD : Ajouter une Extension DSL</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’exigence suivante est de permettre aux utilisateurs de configurer notre plugin via un bloc DSL dans leur <code>build.gradle.kts</code>. Nous voulons un bloc <code>site { …​ }</code> où l’on peut spécifier un chemin de configuration.</p> </div> <div class="sect2"> <h3 id="_3_1_le_test_dabord">3.1. 3.1. Le Test d’Abord</h3> <div class="paragraph"> <p>Nous ajoutons un test pour vérifier que l’extension <code>site</code> est bien enregistrée et qu’on peut y affecter une valeur.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `plugin registers extension`() { val project = ProjectBuilder.builder().build() project.plugins.apply("com.cheroliv.site-baker") // Récupérer l'extension et lui affecter une valeur project.extensions .findByType(SiteExtension::class.java)!! .configPath .set("config.yml") // Vérifier que la valeur a bien été prise en compte assertEquals( "config.yml", project.extensions.findByType(SiteExtension::class.java)?.configPath?.get() ) }</code></pre> </div> </div> <div class="paragraph"> <p>Ce test échoue car ni la classe <code>SiteExtension</code> ni l’enregistrement de l’extension n’existent.</p> </div> </div> <div class="sect2"> <h3 id="_3_2_le_code_ensuite">3.2. 3.2. Le Code Ensuite</h3> <div class="paragraph"> <p>Nous créons la classe <code>SiteBakerExtension.kt</code> et mettons à jour <code>SiteBakerPlugin.kt</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// SiteBakerExtension.kt open class SiteExtension @Inject constructor(objects: ObjectFactory) { val configPath: Property<String> = objects.property(String::class.java) } // SiteBakerPlugin.kt class SiteBakerPlugin: Plugin<Project> { override fun apply(project: Project) { // Enregistrer l'extension val extension = project.extensions.create("site", SiteExtension::class.java) project.tasks.register("printSiteConfig") { task -> task.doLast { // On utilisera l'extension plus tard } } } }</code></pre> </div> </div> <div class="paragraph"> <p>Les tests passent à nouveau.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_4_le_test_fonctionnel_valider_lintégration">4. 4. Le Test Fonctionnel : Valider l’Intégration</h2> <div class="sectionbody"> <div class="paragraph"> <p>Maintenant que les unités sont testées, nous devons nous assurer que tout fonctionne ensemble dans une vraie build. C’est le rôle du test fonctionnel dans <code>SiteBakerPluginFunctionalTest.kt</code>.</p> </div> <div class="sect2"> <h3 id="_4_1_le_test_dintégration_créer_un_environnement_contrôlé">4.1. 4.1. Le Test d’Intégration : Créer un Environnement Contrôlé</h3> <div class="paragraph"> <p>Ce test va simuler un vrai projet utilisant notre plugin. Pour qu’il soit fiable, il doit être <strong>hermétique</strong>, c’est-à-dire qu’il ne doit pas dépendre de fichiers existants sur le système. Il doit créer lui-même toutes les conditions nécessaires à son exécution.</p> </div> <div class="paragraph"> <p>Le test va donc : 1. Créer un <code>build.gradle.kts</code> de test qui utilise notre plugin et son DSL. 2. <strong>Créer le fichier de configuration</strong> (<code>managed-jbake-context.yml</code>) que le plugin est censé lire. C’est une étape cruciale pour la robustesse du test. 3. Exécuter la tâche <code>printSiteConfig</code> via <code>GradleRunner</code>. 4. Vérifier que la sortie de la build est correcte.</p> </div> <div class="paragraph"> <p>En copiant ou créant ce fichier de configuration à chaque exécution, nous nous assurons que le test est <strong>reproductible</strong> et ne dépend pas d’un état externe. Cela sécurise nos tests contre les régressions qui pourraient être liées à la lecture du fichier.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `can run task with DSL`() { // 1. Créer un build.gradle.kts de test buildFile.writeText(""" plugins { id("com.cheroliv.site-baker") } site { configPath = "managed-jbake-context.yml" } """.trimIndent()) // 2. Créer le fichier de configuration pour un test contrôlé val configFile = File(projectDir, "managed-jbake-context.yml") configFile.writeText("site: { title: 'Mon Site de Test' }") // Contenu YAML simple // 3. Exécuter la build val runner = GradleRunner.create() runner.withPluginClasspath() runner.withArguments("printSiteConfig") runner.withProjectDir(projectDir) // Spécifier le répertoire du projet de test val result = runner.build() // 4. Vérifier la sortie assertTrue(result.output.contains("Site config path: managed-jbake-context.yml")) }</code></pre> </div> </div> <div class="paragraph"> <p>Ce test échouera tant que la tâche <code>printSiteConfig</code> n’utilisera pas réellement la valeur de l’extension.</p> </div> </div> <div class="sect2"> <h3 id="_4_2_finaliser_la_logique">4.2. 4.2. Finaliser la Logique</h3> <div class="paragraph"> <p>Nous mettons à jour la tâche dans <code>SiteBakerPlugin.kt</code> pour qu’elle affiche la valeur configurée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">project.tasks.register("printSiteConfig") { task -> task.doLast { println("Site config path: ${extension.configPath.get()}") } }</code></pre> </div> </div> <div class="paragraph"> <p>Tous les tests, unitaires et fonctionnels, passent désormais.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">5. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>En suivant une approche TDD, nous avons construit un plugin de manière incrémentale et sécurisée. Chaque petite fonctionnalité est immédiatement validée par un test, des tests unitaires rapides aux tests fonctionnels qui valident l’intégration complète.</p> </div> <div class="paragraph"> <p>En prenant soin de rendre nos tests fonctionnels <strong>hermétiques</strong> — notamment en créant programmatiquement les fichiers de configuration nécessaires — nous bâtissons un filet de sécurité extrêmement robuste. Cette rigueur nous protège efficacement contre les régressions et nous donne une grande confiance pour ajouter des fonctionnalités plus complexes par la suite, comme le parsing du fichier de configuration YAML.</p> </div> <div class="paragraph"> <p>Cette base de tests solides est l’atout le plus précieux pour la maintenance et l’évolution future du plugin.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0089_creation_projet_plugin_gradle_post.html Tue, 23 Sep 2025 00:00:00 +0000 blog/2025/0089_creation_projet_plugin_gradle_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_étape_1_lancer_lassistant_de_projet">2. Étape 1 : Lancer l’assistant de projet</a></li> <li><a href="#_étape_2_comprendre_la_structure_générée">3. Étape 2 : Comprendre la structure générée</a> <ul class="sectlevel2"> <li><a href="#_fichiers_et_dossiers_clés">3.1. Fichiers et dossiers clés</a></li> </ul> </li> <li><a href="#_étape_3_construire_et_tester_le_plugin">4. Étape 3 : Construire et tester le plugin</a> <ul class="sectlevel2"> <li><a href="#_tâches_de_base">4.1. Tâches de base</a></li> </ul> </li> <li><a href="#_conclusion">5. Conclusion</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <div class="title">Public cible : Développeur débutant à intermédiaire avec Gradle.</div> <p>Démarrer un nouveau projet de plugin Gradle peut sembler intimidant. Heureusement, Gradle fournit un assistant interactif puissant, la tâche <code>init</code>, qui génère une structure de projet complète, propre et prête à l’emploi. Ce guide vous montrera comment utiliser cet outil pour créer une base de plugin saine, en expliquera la structure et vous montrera comment lancer les premières tâches de build.</p> </div> </div> </div> <div class="sect1"> <h2 id="_étape_1_lancer_lassistant_de_projet">2. Étape 1 : Lancer l’assistant de projet</h2> <div class="sectionbody"> <div class="paragraph"> <p>La commande <code>gradle init</code> est le point de départ. Elle lance un assistant en ligne de commande qui vous pose une série de questions pour configurer le projet.</p> </div> <div class="paragraph"> <p>Ouvrez votre terminal dans un dossier vide et lancez :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">gradle init</code></pre> </div> </div> <div class="paragraph"> <p>L’assistant vous guidera. Voici les choix à faire pour un plugin Gradle écrit en Kotlin :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Select type of project to generate:</strong> Choisissez <code>Gradle plugin</code>.</p> </li> <li> <p><strong>Select implementation language:</strong> Choisissez <code>Kotlin</code>.</p> </li> <li> <p><strong>Select build script DSL:</strong> Choisissez <code>Kotlin</code>.</p> </li> <li> <p><strong>Project name:</strong> Entrez un nom pour votre projet (ex: <code>site-baker</code>).</p> </li> <li> <p><strong>Plugin id:</strong> Donnez un identifiant unique à votre plugin (ex: <code>com.cheroliv.site-baker</code>).</p> </li> <li> <p><strong>Plugin class:</strong> Spécifiez le nom de la classe d’implémentation (ex: <code>com.cheroliv.SiteBakerPlugin</code>).</p> </li> </ol> </div> <div class="paragraph"> <p>Une fois terminé, Gradle génère une arborescence de fichiers complète.</p> </div> <div class="imageblock"> <div class="content"> <img src="init-gradle.svg" alt="init gradle" width="193" height="406"> </div> <div class="title">Figure 1. Diagramme du processus d’initialisation</div> </div> </div> </div> <div class="sect1"> <h2 id="_étape_2_comprendre_la_structure_générée">3. Étape 2 : Comprendre la structure générée</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’assistant crée une structure de projet multi-modules, séparant le projet racine du code source du plugin lui-même.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">. ├── gradle/ │ └── wrapper/ │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew ├── gradlew.bat ├── plugin/ │ ├── build.gradle.kts │ └── src/ │ ├── main/ │ │ └── kotlin/ │ │ └── com/cheroliv/SiteBakerPlugin.kt │ ├── test/ │ │ └── kotlin/ │ │ └── com/cheroliv/SiteBakerPluginTest.kt │ └── functionalTest/ │ └── kotlin/ │ └── com/cheroliv/SiteBakerPluginFunctionalTest.kt └── settings.gradle.kts</code></pre> </div> </div> <div class="sect2"> <h3 id="_fichiers_et_dossiers_clés">3.1. Fichiers et dossiers clés</h3> <div class="ulist"> <ul> <li> <p><code>settings.gradle.kts</code> : Ce fichier à la racine définit les modules inclus dans le build. Ici, il inclut le sous-projet <code>plugin</code>. [source,kotlin] ---- rootProject.name = "site-baker" include("plugin") ----</p> </li> <li> <p><code>plugin/build.gradle.kts</code> : C’est le cœur de la configuration de votre plugin. Il applique le plugin <code>java-gradle-plugin</code>, déclare les dépendances et configure les métadonnées du plugin. [source,kotlin] ---- plugins { <code>java-gradle-plugin</code> alias(libs.plugins.kotlin.jvm) }</p> <div class="literalblock"> <div class="content"> <pre> gradlePlugin { val siteBaker by plugins.creating { id = "com.cheroliv.site-baker" implementationClass = "com.cheroliv.SiteBakerPlugin" } } ---- * `src/main/` : Contient le code source de votre plugin. * `src/test/` : Contient les tests unitaires. Ils s'exécutent rapidement et en isolation. * `src/functionalTest/` : Contient les tests fonctionnels. Ces tests utilisent `GradleRunner` pour exécuter une version complète de Gradle sur un projet de test, simulant ainsi une utilisation réelle de votre plugin.</pre> </div> </div> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_étape_3_construire_et_tester_le_plugin">4. Étape 3 : Construire et tester le plugin</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le projet généré inclut le <strong>Gradle Wrapper</strong> (<code>gradlew</code>). C’est la manière recommandée d’exécuter Gradle, car elle garantit que tous les développeurs utilisent la même version, assurant des builds reproductibles.</p> </div> <div class="sect2"> <h3 id="_tâches_de_base">4.1. Tâches de base</h3> <div class="ulist"> <ul> <li> <p><strong>Construire le projet :</strong> Cette commande compile votre code, exécute tous les tests (unitaires et fonctionnels) et assemble le JAR de votre plugin. [source,bash] ---- ./gradlew build ----</p> </li> <li> <p><strong>Lancer toutes les vérifications :</strong> La tâche <code>check</code> est un alias qui exécute toutes les tâches de vérification, y compris <code>test</code> et <code>functionalTest</code>. [source,bash] ---- ./gradlew check ----</p> </li> <li> <p><strong>Exécuter uniquement les tests unitaires :</strong> Pour un feedback rapide pendant le développement. [source,bash] ---- ./gradlew test ----</p> </li> </ul> </div> <div class="exampleblock"> <div class="content"> <div class="paragraph"> <p>La commande <code>./gradlew :test</code>, qui cible explicitement le projet racine, échouera car ce dernier ne contient pas de tests. En revanche : * <code>./gradlew test</code> fonctionne car Gradle exécute la tâche <code>test</code> sur tous les sous-projets qui la possèdent (ici, le module <code>plugin</code>). * <code>./gradlew :plugin:test</code> est la commande la plus explicite pour lancer les tests du module <code>plugin</code> uniquement.</p> </div> </div> </div> <div class="ulist"> <ul> <li> <p><strong>Exécuter uniquement les tests fonctionnels :</strong> Plus lents, ils sont utiles pour valider le comportement global. [source,bash] ---- ./gradlew functionalTest ----</p> </li> </ul> </div> <div class="paragraph"> <p>Le résultat des tests est généré dans le dossier <code>plugin/build/reports/tests/</code>. Vous pouvez ouvrir le fichier <code>index.html</code> dans votre navigateur pour un rapport détaillé.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">5. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>En quelques minutes, <code>gradle init</code> vous a fourni une base de projet solide, moderne et complète pour le développement de votre plugin. Vous disposez d’une structure claire, de tests unitaires et fonctionnels préconfigurés, et d’un système de build reproductible grâce au Gradle Wrapper.</p> </div> <div class="paragraph"> <p>Vous êtes maintenant prêt à ouvrir le fichier <code>SiteBakerPlugin.kt</code> et à commencer à y ajouter la logique métier de votre plugin !</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0088_environnement_plugin_gradle_post.html Mon, 22 Sep 2025 00:00:00 +0000 blog/2025/0088_environnement_plugin_gradle_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_1_le_jdk_le_moteur_de_gradle">2. 1. Le JDK : Le moteur de Gradle</a> <ul class="sectlevel2"> <li><a href="#_quelle_version_choisir">2.1. Quelle version choisir ?</a></li> <li><a href="#_installation_via_sdkman_recommandé">2.2. Installation via SDKMAN! (Recommandé)</a> <ul class="sectlevel3"> <li><a href="#_installer_sdkman">2.2.1. <strong>Installer SDKMAN!</strong></a></li> <li><a href="#_installer_une_version_du_jdk">2.2.2. <strong>Installer une version du JDK</strong></a></li> <li><a href="#_vérifier_linstallation">2.2.3. <strong>Vérifier l’installation</strong></a></li> </ul> </li> </ul> </li> <li><a href="#_2_lide_intellij_idea">3. 2. L’IDE : IntelliJ IDEA</a></li> <li><a href="#_3_gradle_loutil_de_build">4. 3. Gradle : L’outil de build</a> <ul class="sectlevel2"> <li><a href="#_installation_via_sdkman">4.1. Installation via SDKMAN!</a> <ul class="sectlevel3"> <li><a href="#_installer_gradle">4.1.1. <strong>Installer Gradle</strong></a></li> <li><a href="#_vérifier_linstallation_2">4.1.2. <strong>Vérifier l’installation</strong></a></li> </ul> </li> </ul> </li> <li><a href="#_4_jbake_le_générateur_de_site_statique">5. 4. JBake : Le générateur de site statique</a> <ul class="sectlevel2"> <li><a href="#_installation_via_sdkman_2">5.1. Installation via SDKMAN!</a> <ul class="sectlevel3"> <li><a href="#_installer_jbake">5.1.1. <strong>Installer JBake</strong></a></li> <li><a href="#_vérifier_linstallation_3">5.1.2. <strong>Vérifier l’installation</strong></a></li> </ul> </li> </ul> </li> <li><a href="#_5_le_gradle_wrapper_la_bonne_pratique_absolue">6. 5. Le Gradle Wrapper : La bonne pratique absolue</a></li> <li><a href="#_6_docker_et_portainer_pour_des_builds_reproductibles_optionnel">7. 6. Docker et Portainer : Pour des Builds Reproductibles (Optionnel)</a> <ul class="sectlevel2"> <li><a href="#_installation_de_docker_engine">7.1. Installation de Docker Engine</a> <ul class="sectlevel3"> <li><a href="#_installer_docker_via_le_script_officiel">7.1.1. <strong>Installer Docker via le script officiel :</strong></a></li> <li><a href="#_gérer_docker_sans_sudo_recommandé">7.1.2. <strong>Gérer Docker sans <code>sudo</code> (recommandé) :</strong></a></li> <li><a href="#_vous_devez_vous_déconnecter_et_vous_reconnecter_pour_que_ce_changement_soit_pris_en_compte">Vous devez vous déconnecter et vous reconnecter pour que ce changement soit pris en compte.</a></li> <li><a href="#_3_vérifier_linstallation">7.1.3. 3. <strong>Vérifier l’installation :</strong></a></li> </ul> </li> <li><a href="#_gérer_docker_avec_portainer_gui">7.2. Gérer Docker avec Portainer (GUI)</a> <ul class="sectlevel3"> <li><a href="#_créer_un_volume_pour_les_données_de_portainer">7.2.1. <strong>Créer un volume pour les données de Portainer :</strong></a></li> <li><a href="#_lancer_le_conteneur_portainer">7.2.2. <strong>Lancer le conteneur Portainer :</strong></a></li> </ul> </li> </ul> </li> <li><a href="#_conclusion">8. Conclusion</a></li> </ul> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <div class="title">Public cible : Développeurs souhaitant se lancer dans la création de plugins Gradle.</div> <p>Pour développer des plugins Gradle efficacement, un environnement de développement bien configuré est indispensable. Un bon setup vous fera gagner du temps, réduira les frustrations et assurera la cohérence de vos builds.</p> </div> <div class="olist arabic"> <div class="title">Ce guide se concentre sur quatre piliers essentiels :</div> <ol class="arabic"> <li> <p>Le <strong>JDK</strong> (Java Development Kit), car Gradle et JBake s’exécutent sur la JVM.</p> </li> <li> <p>Un <strong>IDE</strong> moderne (IntelliJ IDEA) avec un bon support de Kotlin et Gradle.</p> </li> <li> <p><strong>Gradle</strong> lui-même, pour initialiser les projets.</p> </li> <li> <p><strong>JBake</strong>, le moteur de notre site statique.</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="images/gradle-env.svg" alt="gradle env" width="492" height="213"> </div> <div class="title">Figure 1. Composants de l’environnement de développement</div> </div> </div> </div> <div class="sect1"> <h2 id="_1_le_jdk_le_moteur_de_gradle">2. 1. Le JDK : Le moteur de Gradle</h2> <div class="sectionbody"> <div class="paragraph"> <p>Gradle est une application qui s’exécute sur la Java Virtual Machine (JVM). Par conséquent, l’installation d’un JDK est un prérequis absolu.</p> </div> <div class="sect2"> <h3 id="_quelle_version_choisir">2.1. Quelle version choisir ?</h3> <div class="paragraph"> <p>Il est recommandé d’utiliser une version LTS (Long-Term Support) de Java. À l’heure actuelle, <strong>JDK 17</strong> ou <strong>JDK 21</strong> sont d’excellents choix.</p> </div> </div> <div class="sect2"> <h3 id="_installation_via_sdkman_recommandé">2.2. Installation via SDKMAN! (Recommandé)</h3> <div class="paragraph"> <p>SDKMAN! est un outil formidable pour gérer les versions de nombreux SDK, y compris Java et Gradle.</p> </div> <div class="sect3"> <h4 id="_installer_sdkman">2.2.1. <strong>Installer SDKMAN!</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">curl -s "https://get.sdkman.io" | bash source "$HOME/.sdkman/bin/sdkman-init.sh"</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_installer_une_version_du_jdk">2.2.2. <strong>Installer une version du JDK</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Pour lister les versions de Java disponibles sdk list java # Pour installer Java 17 (par exemple, la distribution Temurin) sdk install java 17.0.8-tem</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_vérifier_linstallation">2.2.3. <strong>Vérifier l’installation</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">java -version</code></pre> </div> </div> <div class="paragraph"> <p>Vous devriez voir la version que vous venez d’installer s’afficher.</p> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_2_lide_intellij_idea">3. 2. L’IDE : IntelliJ IDEA</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour le développement de plugins Gradle avec le DSL Kotlin, <strong>IntelliJ IDEA</strong> est l’outil de choix. Son intégration avec Gradle et Kotlin est inégalée.</p> </div> <div class="ulist"> <ul> <li> <p><strong>Community Edition :</strong> Gratuite et largement suffisante pour commencer.</p> </li> <li> <p><strong>Ultimate Edition :</strong> Payante, elle offre des fonctionnalités avancées pour le développement web et base de données.</p> </li> </ul> </div> <div class="paragraph"> <p>Téléchargez la version qui vous convient depuis le site de JetBrains : <a href="https://www.jetbrains.com/idea/download/" class="bare">https://www.jetbrains.com/idea/download/</a></p> </div> <div class="paragraph"> <p>L’IDE détectera automatiquement vos fichiers <code>build.gradle.kts</code> et <code>settings.gradle.kts</code>, vous offrant une autocomplétion puissante, la navigation dans le code et des outils de débogage intégrés.</p> </div> </div> </div> <div class="sect1"> <h2 id="_3_gradle_loutil_de_build">4. 3. Gradle : L’outil de build</h2> <div class="sectionbody"> <div class="paragraph"> <p>Même si chaque projet utilisera sa propre version de Gradle via le Gradle Wrapper, il est utile d’avoir une installation globale de Gradle pour des tâches comme l’initialisation de nouveaux projets (<code>gradle init</code>).</p> </div> <div class="sect2"> <h3 id="_installation_via_sdkman">4.1. Installation via SDKMAN!</h3> <div class="paragraph"> <p>Tout comme pour le JDK, SDKMAN! simplifie l’installation de Gradle.</p> </div> <div class="sect3"> <h4 id="_installer_gradle">4.1.1. <strong>Installer Gradle</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sdk install gradle</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_vérifier_linstallation_2">4.1.2. <strong>Vérifier l’installation</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">gradle -v</code></pre> </div> </div> <div class="paragraph"> <p>Cette commande affichera les versions de Gradle, Kotlin, Groovy et du JDK utilisées.</p> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_4_jbake_le_générateur_de_site_statique">5. 4. JBake : Le générateur de site statique</h2> <div class="sectionbody"> <div class="paragraph"> <p>JBake est l’outil que nous utiliserons pour transformer nos fichiers sources (comme celui-ci) en un site web statique. Avoir une installation locale est pratique pour prévisualiser les changements.</p> </div> <div class="sect2"> <h3 id="_installation_via_sdkman_2">5.1. Installation via SDKMAN!</h3> <div class="paragraph"> <p>Comme pour les autres outils, SDKMAN! est la méthode la plus simple.</p> </div> <div class="sect3"> <h4 id="_installer_jbake">5.1.1. <strong>Installer JBake</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sdk install jbake</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_vérifier_linstallation_3">5.1.2. <strong>Vérifier l’installation</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">jbake -v</code></pre> </div> </div> <div class="paragraph"> <p>Cette commande affichera la version de JBake et les informations de l’environnement Java qu’il utilise.</p> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_5_le_gradle_wrapper_la_bonne_pratique_absolue">6. 5. Le Gradle Wrapper : La bonne pratique absolue</h2> <div class="sectionbody"> <div class="paragraph"> <p>Une fois votre projet créé (ce que nous verrons dans l’article suivant), vous ne devriez plus utiliser la commande globale <code>gradle</code>. À la place, vous utiliserez le <strong>Gradle Wrapper</strong> (<code>./gradlew</code>), un script inclus dans votre projet.</p> </div> <div class="paragraph"> <p>Pourquoi ? * <strong>Reproductibilité :</strong> Le Wrapper garantit que chaque personne travaillant sur le projet (y compris votre serveur de CI/CD) utilise exactement la <strong>même version de Gradle</strong>, éliminant ainsi les erreurs de build dues à des environnements différents. * <strong>Simplicité :</strong> Pas besoin d’installer Gradle manuellement pour contribuer à un projet. Il suffit de cloner le dépôt et de lancer <code>./gradlew</code>.</p> </div> <div class="paragraph"> <p>Une commande typique ressemblera à ceci :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash"># Ne pas faire : gradle build # À faire : ./gradlew build</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_6_docker_et_portainer_pour_des_builds_reproductibles_optionnel">7. 6. Docker et Portainer : Pour des Builds Reproductibles (Optionnel)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Bien que non strictement nécessaires pour écrire un plugin, Docker et Portainer sont des outils DevOps modernes qui facilitent grandement la création de builds reproductibles et la gestion de votre environnement.</p> </div> <div class="sect2"> <h3 id="_installation_de_docker_engine">7.1. Installation de Docker Engine</h3> <div class="paragraph"> <p>Docker vous permet d’empaqueter votre application et ses dépendances dans un conteneur.</p> </div> <div class="sect3"> <h4 id="_installer_docker_via_le_script_officiel">7.1.1. <strong>Installer Docker via le script officiel :</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_gérer_docker_sans_sudo_recommandé">7.1.2. <strong>Gérer Docker sans <code>sudo</code> (recommandé) :</strong></h4> <div class="paragraph"> <p>Ajoutez votre utilisateur au groupe <code>docker</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo usod -aG docker $USER</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_vous_devez_vous_déconnecter_et_vous_reconnecter_pour_que_ce_changement_soit_pris_en_compte">Vous devez vous déconnecter et vous reconnecter pour que ce changement soit pris en compte.</h4> </div> <div class="sect3"> <h4 id="_3_vérifier_linstallation">7.1.3. 3. <strong>Vérifier l’installation :</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">docker run hello-world</code></pre> </div> </div> </div> </div> <div class="sect2"> <h3 id="_gérer_docker_avec_portainer_gui">7.2. Gérer Docker avec Portainer (GUI)</h3> <div class="paragraph"> <p>Portainer est une interface web légère pour gérer vos conteneurs Docker.</p> </div> <div class="sect3"> <h4 id="_créer_un_volume_pour_les_données_de_portainer">7.2.1. <strong>Créer un volume pour les données de Portainer :</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">docker volume create portainer_data</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_lancer_le_conteneur_portainer">7.2.2. <strong>Lancer le conteneur Portainer :</strong></h4> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest</code></pre> </div> </div> <div class="paragraph"> <p>Vous pouvez maintenant accéder à l’interface de Portainer sur <code><a href="https://localhost:9443" class="bare">https://localhost:9443</a></code>.</p> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">8. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Votre environnement est maintenant prêt ! Vous disposez d’un JDK, de l’IDE le plus adapté, de Gradle et de JBake. Avec l’ajout de Docker, vous êtes également paré pour créer des builds conteneurisés et reproductibles. Cette base solide vous permettra de vous concentrer sur l’essentiel : le développement de plugins puissants et utiles.</p> </div> <div class="paragraph"> <p>Dans le prochain article, nous utiliserons la commande <code>gradle init</code> pour générer la structure de notre premier projet de plugin.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0087_pypi_cicd_part_3_post.html Sat, 19 Jul 2025 00:00:00 +0000 blog/2025/0087_pypi_cicd_part_3_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_intégration_avec_poetry">Intégration avec Poetry</a> <ul class="sectlevel2"> <li><a href="#_installation_de_poetry">Installation de Poetry</a></li> <li><a href="#_initialisation_du_projet">Initialisation du projet</a></li> <li><a href="#_ajout_et_installation_de_dépendances">Ajout et installation de dépendances</a></li> <li><a href="#_publication_avec_poetry">Publication avec Poetry</a></li> </ul> </li> <li><a href="#_builds_reproductibles_avec_docker">Builds reproductibles avec Docker</a> <ul class="sectlevel2"> <li><a href="#_exemple_de_dockerfile">Exemple de Dockerfile</a></li> <li><a href="#_intégration_dans_github_actions">Intégration dans GitHub Actions</a></li> </ul> </li> <li><a href="#_publication_conditionnelle">Publication conditionnelle</a></li> <li><a href="#_automatisation_des_dépendances_avec_renovate_et_dependabot">Automatisation des dépendances avec Renovate et Dependabot</a> <ul class="sectlevel2"> <li><a href="#_dependabot">Dependabot</a></li> <li><a href="#_renovate">Renovate</a></li> </ul> </li> <li><a href="#_diagrammes_plantuml">Diagrammes PlantUML</a> <ul class="sectlevel2"> <li><a href="#_cas_dusage_cicd_avancé">Cas d’Usage – CI/CD avancé</a></li> <li><a href="#_séquence_publication_conditionnelle">Séquence – Publication conditionnelle</a></li> <li><a href="#_états_pipeline_cicd">États – Pipeline CI/CD</a></li> <li><a href="#_déploiement_architecture_cicd">Déploiement – Architecture CI/CD</a></li> </ul> </li> <li><a href="#_conclusion">Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>Dans les deux premières parties de cette série, nous avons : - Établi un pipeline CI/CD fonctionnel pour une application Python avec GitHub Actions et PyPI. - Industrialisé ce pipeline avec des tests multi-versions, une publication progressive via Test PyPI, et des outils de qualité et de sécurité.</p> </div> <div class="paragraph"> <p>Dans cette troisième partie, nous allons aller <strong>au-delà de la simple publication sur PyPI</strong> pour construire une chaîne de CI/CD complète, robuste et professionnelle avec : - <strong>Poetry</strong> pour un packaging moderne et une gestion optimisée des dépendances. - <strong>Docker</strong> pour créer des builds reproductibles et multi-plateformes. - <strong>Publication conditionnelle</strong> pour gérer des scénarios comme les release candidates. - <strong>Outils d’automatisation</strong> (Renovate, Dependabot) pour maintenir le pipeline à jour sans effort.</p> </div> </div> </div> <div class="sect1"> <h2 id="_intégration_avec_poetry">Intégration avec Poetry</h2> <div class="sectionbody"> <div class="paragraph"> <p>Poetry remplace les anciens outils de packaging (setup.py, requirements.txt) en centralisant la gestion des dépendances et du build dans <code>pyproject.toml</code>.</p> </div> <div class="sect2"> <h3 id="_installation_de_poetry">Installation de Poetry</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="shell"># Installer Poetry curl -sSL https://install.python-poetry.org | python3 - # Vérifier la version poetry --version</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_initialisation_du_projet">Initialisation du projet</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="shell"># Initialiser un nouveau projet avec Poetry poetry init # Suivre l'assistant pour renseigner : nom, version, description, licence, dépendances.</code></pre> </div> </div> <div class="paragraph"> <p>Cela génère un fichier <code>pyproject.toml</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="toml">[tool.poetry] name = "playlist-downloader" version = "0.1.0" description = "CLI tool for managing YouTube playlists" authors = ["Christophe Hérolivier <cheroliv@example.com>"] [tool.poetry.dependencies] python = ">=3.8" typer = "^0.9.0" yt-dlp = "^2023.7.6" google-api-python-client = "^2.0.0" google-auth-oauthlib = "^1.0.0" [tool.poetry.group.dev.dependencies] pytest = "^7.0" mypy = "^1.0" bandit = "^1.7" safety = "^2.3" black = "^23.0" ruff = "^0.1"</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_ajout_et_installation_de_dépendances">Ajout et installation de dépendances</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="shell">poetry add typer yt-dlp google-api-python-client google-auth-oauthlib poetry add --group dev pytest mypy black bandit safety ruff</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_publication_avec_poetry">Publication avec Poetry</h3> <div class="paragraph"> <p>Poetry gère nativement la publication :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="shell"># Publication sur Test PyPI poetry publish --build --repository test-pypi # Publication sur PyPI poetry publish --build</code></pre> </div> </div> <div class="paragraph"> <p>Cette commande utilise automatiquement les informations présentes dans <code>pyproject.toml</code>.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_builds_reproductibles_avec_docker">Builds reproductibles avec Docker</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour assurer des exécutions identiques en développement, CI/CD et production, Docker s’intègre parfaitement avec Poetry.</p> </div> <div class="sect2"> <h3 id="_exemple_de_dockerfile">Exemple de Dockerfile</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="dockerfile">FROM python:3.11-slim WORKDIR /app COPY pyproject.toml poetry.lock ./ RUN pip install poetry RUN poetry install --no-root --only main COPY . . CMD ["poetry", "run", "python", "cli.py"]</code></pre> </div> </div> <div class="paragraph"> <p>Cela garantit : - Un environnement Python figé. - Des dépendances verrouillées via <code>poetry.lock</code>. - Une image exécutable sur tout système supportant Docker.</p> </div> </div> <div class="sect2"> <h3 id="_intégration_dans_github_actions">Intégration dans GitHub Actions</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">name: Docker Build on: push: branches: [main] jobs: build-docker: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build Docker image run: docker build -t ghcr.io/${{ github.repository }}:latest . - name: Push Docker image run: docker push ghcr.io/${{ github.repository }}:latest</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_publication_conditionnelle">Publication conditionnelle</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans un pipeline professionnel, il faut pouvoir publier uniquement dans certains cas : - Release candidates vers Test PyPI. - Versions stables vers PyPI. - Builds Docker déclenchés uniquement pour <code>main</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Publish to Test PyPI if: contains(github.ref, '-rc') run: poetry publish --build --repository test-pypi - name: Publish to PyPI if: startsWith(github.ref, 'refs/tags/v') run: poetry publish --build</code></pre> </div> </div> <div class="paragraph"> <p>Cette approche évite les publications accidentelles.</p> </div> </div> </div> <div class="sect1"> <h2 id="_automatisation_des_dépendances_avec_renovate_et_dependabot">Automatisation des dépendances avec Renovate et Dependabot</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour éviter que vos dépendances deviennent obsolètes, intégrez des outils de mise à jour automatique.</p> </div> <div class="sect2"> <h3 id="_dependabot">Dependabot</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">version: 2 updates: - package-ecosystem: "pip" directory: "/" schedule: interval: "weekly" - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly"</code></pre> </div> </div> <div class="paragraph"> <p>Dependabot ouvre des PR chaque semaine pour mettre à jour les dépendances Python et GitHub Actions.</p> </div> </div> <div class="sect2"> <h3 id="_renovate">Renovate</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="json">{ "extends": ["config:base"], "packageRules": [ { "matchManagers": ["pip"], "groupName": "python-dependencies", "schedule": ["before 6am on monday"] } ] }</code></pre> </div> </div> <div class="paragraph"> <p>Renovate permet un contrôle plus fin : regroupement de dépendances, planification, et règles avancées.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_diagrammes_plantuml">Diagrammes PlantUML</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_cas_dusage_cicd_avancé">Cas d’Usage – CI/CD avancé</h3> <div class="imageblock"> <div class="content"> <img src="images/usecase-cicd.svg" alt="usecase cicd" width="819" height="317"> </div> </div> </div> <div class="sect2"> <h3 id="_séquence_publication_conditionnelle">Séquence – Publication conditionnelle</h3> <div class="imageblock"> <div class="content"> <img src="images/sequence-cicd.svg" alt="sequence cicd" width="275" height="571"> </div> </div> </div> <div class="sect2"> <h3 id="_états_pipeline_cicd">États – Pipeline CI/CD</h3> <div class="imageblock"> <div class="content"> <img src="images/states-cicd.svg" alt="states cicd" width="284" height="608"> </div> </div> </div> <div class="sect2"> <h3 id="_déploiement_architecture_cicd">Déploiement – Architecture CI/CD</h3> <div class="imageblock"> <div class="content"> <img src="images/deployment-cicd.svg" alt="deployment cicd" width="535" height="288"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans cette troisième partie, nous avons vu comment : - Moderniser le packaging Python avec Poetry. - Garantir des builds reproductibles via Docker. - Mettre en place une publication conditionnelle. - Automatiser la mise à jour des dépendances.</p> </div> <div class="paragraph"> <p>Vous disposez désormais d’un pipeline CI/CD <strong>complet, industrialisé et sécurisé</strong>, prêt à évoluer avec vos projets.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0086_pypi_cicd_part_2_post.html Fri, 18 Jul 2025 00:00:00 +0000 blog/2025/0086_pypi_cicd_part_2_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_architecture_du_pipeline_cicd">2. Architecture du Pipeline CI/CD</a></li> <li><a href="#_structure_du_projet">3. Structure du Projet</a></li> <li><a href="#_configuration_du_package_avec_pyproject_toml">4. Configuration du Package avec pyproject.toml</a></li> <li><a href="#_workflow_de_cicd_tests_et_qualité">5. Workflow de CI/CD - Tests et Qualité</a></li> <li><a href="#_workflow_de_release_et_déploiement">6. Workflow de Release et Déploiement</a></li> <li><a href="#_diagrammes_darchitecture">7. Diagrammes d’Architecture</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_séquence_processus_de_release">7.1. Diagramme de Séquence - Processus de Release</a></li> <li><a href="#_diagramme_détats_cycle_de_vie_du_package">7.2. Diagramme d’États - Cycle de Vie du Package</a></li> <li><a href="#_diagramme_de_déploiement_infrastructure_cicd">7.3. Diagramme de Déploiement - Infrastructure CI/CD</a></li> </ul> </li> <li><a href="#_objets_et_modèles_du_pipeline">8. Objets et Modèles du Pipeline</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_classes_modèles_cicd">8.1. Diagramme de Classes - Modèles CI/CD</a></li> </ul> </li> <li><a href="#_configuration_des_secrets">9. Configuration des Secrets</a> <ul class="sectlevel2"> <li><a href="#_secrets_github_actions">9.1. Secrets GitHub Actions</a></li> <li><a href="#_génération_des_tokens_pypi">9.2. Génération des Tokens PyPI</a></li> </ul> </li> <li><a href="#_scripts_de_développement_local">10. Scripts de Développement Local</a> <ul class="sectlevel2"> <li><a href="#_makefile">10.1. Makefile</a></li> <li><a href="#_script_de_version">10.2. Script de Version</a></li> </ul> </li> <li><a href="#_bonnes_pratiques_et_recommandations">11. Bonnes Pratiques et Recommandations</a> <ul class="sectlevel2"> <li><a href="#_versioning_sémantique">11.1. Versioning Sémantique</a></li> <li><a href="#_stratégie_de_branching">11.2. Stratégie de Branching</a></li> <li><a href="#_tests_et_couverture">11.3. Tests et Couverture</a></li> <li><a href="#_sécurité">11.4. Sécurité</a></li> </ul> </li> <li><a href="#_monitoring_et_observabilité">12. Monitoring et Observabilité</a> <ul class="sectlevel2"> <li><a href="#_métriques_de_pipeline">12.1. Métriques de Pipeline</a></li> <li><a href="#_notifications">12.2. Notifications</a></li> </ul> </li> <li><a href="#_conclusion">13. Conclusion</a></li> <li><a href="#_ressources_complémentaires">14. Ressources Complémentaires</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title">Objectif :</div> <p>Transformer un pipeline simple en pipeline industriel robuste, respectant les standards modernes du packaging et de l’ingénierie logicielle.</p> </div> </div> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans la première partie de cette série, nous avons construit un pipeline CI/CD simple mais efficace pour automatiser les tests et la publication d’un package Python sur PyPI.</p> </div> <div class="paragraph"> <p>Il est maintenant temps de professionnaliser ce pipeline. Dans cette seconde partie, nous allons :</p> </div> <div class="ulist"> <ul> <li> <p>Migrer vers le standard moderne pyproject.toml,</p> </li> <li> <p>Ajouter des outils de qualité et de sécurité (Black, Mypy, Bandit, Safety),</p> </li> <li> <p>Mettre en place des tests multi-versions,</p> </li> <li> <p>Intégrer un déploiement progressif via Test PyPI,</p> </li> <li> <p>Automatiser le versioning et améliorer la surveillance du pipeline.</p> </li> </ul> </div> <div class="paragraph"> <p>Préparez-vous à passer d’un pipeline fonctionnel à une infrastructure CI/CD professionnelle.</p> </div> <div class="paragraph"> <p>Déployer une application Python sur PyPI nécessite un pipeline CI/CD robuste qui automatise les tests, la construction et la publication des packages. Cet article détaille la mise en place d’un pipeline complet utilisant GitHub Actions pour une application CLI Python, en s’appuyant sur les bonnes pratiques de l’écosystème Python moderne.</p> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_du_pipeline_cicd">2. Architecture du Pipeline CI/CD</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le pipeline que nous allons construire suit une approche en plusieurs étapes :</p> </div> <div class="imageblock"> <div class="content"> <img src="images/diag-plantuml-md5-7c661f88b9476d6adca6ed0f09d1f513.png" alt="Diagram" width="865" height="604"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_structure_du_projet">3. Structure du Projet</h2> <div class="sectionbody"> <div class="paragraph"> <p>Une application CLI Python prête pour la distribution doit respecter une structure standardisée :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="text">playlist-downloader/ ├── .github/ │ └── workflows/ │ ├── ci.yml │ ├── release.yml │ └── security.yml ├── src/ │ └── playlist_downloader/ │ ├── __init__.py │ ├── cli.py │ ├── core/ │ └── adapters/ ├── tests/ │ ├── unit/ │ ├── integration/ │ └── conftest.py ├── docs/ ├── pyproject.toml ├── requirements.txt ├── requirements-dev.txt ├── MANIFEST.in ├── README.md ├── LICENSE └── CHANGELOG.md</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_du_package_avec_pyproject_toml">4. Configuration du Package avec pyproject.toml</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le fichier <code>pyproject.toml</code> est le standard moderne pour configurer les packages Python :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="toml">[build-system] requires = ["setuptools>=45", "wheel", "setuptools_scm>=6.2"] build-backend = "setuptools.build_meta" [project] name = "playlist-downloader" authors = [ {name = "Christophe Hérolivier", email = "cheroliv@example.com"}, ] description = "CLI tool for YouTube playlist management" readme = "README.md" requires-python = ">=3.8" keywords = ["youtube", "playlist", "cli", "downloader"] license = {text = "MIT"} classifiers = [ "Development Status :: 4 - Beta", "Environment :: Console", "Intended Audience :: End Users/Desktop", "License :: OSI Approved :: MIT License", "Operating System :: OS Independent", "Programming Language :: Python :: 3", "Programming Language :: Python :: 3.8", "Programming Language :: Python :: 3.9", "Programming Language :: Python :: 3.10", "Programming Language :: Python :: 3.11", "Topic :: Multimedia :: Sound/Audio", "Topic :: Utilities", ] dependencies = [ "typer>=0.9.0", "yt-dlp>=2023.7.6", "google-api-python-client>=2.0.0", "google-auth-oauthlib>=1.0.0", "pyyaml>=6.0", "rich>=13.0.0", ] dynamic = ["version"] [project.optional-dependencies] dev = [ "pytest>=7.0.0", "pytest-cov>=4.0.0", "pytest-mock>=3.10.0", "black>=23.0.0", "flake8>=6.0.0", "mypy>=1.0.0", "pre-commit>=3.0.0", "tox>=4.0.0", ] test = [ "pytest>=7.0.0", "pytest-cov>=4.0.0", "pytest-mock>=3.10.0", ] [project.urls] Homepage = "https://github.com/cheroliv/playlist-downloader" Documentation = "https://github.com/cheroliv/playlist-downloader#readme" Repository = "https://github.com/cheroliv/playlist-downloader.git" "Bug Tracker" = "https://github.com/cheroliv/playlist-downloader/issues" [project.scripts] playlist-downloader = "playlist_downloader.cli:main" [tool.setuptools_scm] write_to = "src/playlist_downloader/_version.py" [tool.setuptools.packages.find] where = ["src"] [tool.pytest.ini_options] testpaths = ["tests"] python_files = ["test_*.py"] python_classes = ["Test*"] python_functions = ["test_*"] addopts = [ "--cov=src/playlist_downloader", "--cov-report=html", "--cov-report=term-missing", "--cov-fail-under=85", ] [tool.black] line-length = 88 target-version = ['py38'] include = '\.pyi?$' extend-exclude = ''' /( \.eggs | \.git | \.hg | \.mypy_cache | \.tox | \.venv | _build | buck-out | build | dist )/ ''' [tool.mypy] python_version = "3.8" warn_return_any = true warn_unused_configs = true disallow_untyped_defs = true disallow_incomplete_defs = true check_untyped_defs = true disallow_untyped_decorators = true no_implicit_optional = true warn_redundant_casts = true warn_unused_ignores = true warn_no_return = true warn_unreachable = true strict_equality = true [[tool.mypy.overrides]] module = [ "yt_dlp.*", "googleapiclient.*", "google_auth_oauthlib.*", ] ignore_missing_imports = true</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_workflow_de_cicd_tests_et_qualité">5. Workflow de CI/CD - Tests et Qualité</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le workflow principal (<code>ci.yml</code>) exécute les tests sur plusieurs versions de Python :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">name: CI on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest strategy: matrix: python-version: ["3.8", "3.9", "3.10", "3.11"] steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v4 with: python-version: ${{ matrix.python-version }} - name: Cache dependencies uses: actions/cache@v3 with: path: | ~/.cache/pip ~/.cache/pre-commit key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements*.txt') }} restore-keys: | ${{ runner.os }}-pip- - name: Install dependencies run: | python -m pip install --upgrade pip pip install -e ".[dev]" - name: Lint with flake8 run: | flake8 src tests --count --select=E9,F63,F7,F82 --show-source --statistics flake8 src tests --count --exit-zero --max-complexity=10 --max-line-length=88 --statistics - name: Check code formatting with Black run: black --check src tests - name: Type checking with mypy run: mypy src - name: Run tests with pytest run: | pytest tests/ -v --cov=src/playlist_downloader \ --cov-report=xml --cov-report=term-missing - name: Upload coverage to Codecov uses: codecov/codecov-action@v3 if: matrix.python-version == '3.11' with: file: ./coverage.xml flags: unittests name: codecov-umbrella security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v4 with: python-version: "3.11" - name: Install dependencies run: | python -m pip install --upgrade pip pip install bandit[toml] safety - name: Run security checks with bandit run: bandit -r src/ -f json -o bandit-report.json - name: Check dependencies with safety run: safety check --json --output safety-report.json - name: Upload security reports uses: actions/upload-artifact@v3 if: always() with: name: security-reports path: | bandit-report.json safety-report.json build: needs: [test, security] runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up Python uses: actions/setup-python@v4 with: python-version: "3.11" - name: Install build dependencies run: | python -m pip install --upgrade pip pip install build twine - name: Build package run: python -m build - name: Check package with twine run: twine check dist/* - name: Upload build artifacts uses: actions/upload-artifact@v3 with: name: dist path: dist/</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_workflow_de_release_et_déploiement">6. Workflow de Release et Déploiement</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le workflow de release (<code>release.yml</code>) gère la publication automatique sur PyPI :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">name: Release on: push: tags: - 'v*.*.*' workflow_dispatch: inputs: environment: description: 'Deployment environment' required: true default: 'test' type: choice options: - test - production env: PYTHON_VERSION: "3.11" jobs: release: runs-on: ubuntu-latest environment: name: ${{ github.event.inputs.environment || (startsWith(github.ref, 'refs/tags/') && 'production' || 'test') }} steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up Python uses: actions/setup-python@v4 with: python-version: ${{ env.PYTHON_VERSION }} - name: Install dependencies run: | python -m pip install --upgrade pip pip install build twine - name: Build package run: python -m build - name: Check package run: twine check dist/* - name: Publish to Test PyPI if: github.event.inputs.environment == 'test' || (startsWith(github.ref, 'refs/tags/') && contains(github.ref, 'rc')) env: TWINE_USERNAME: __token__ TWINE_PASSWORD: ${{ secrets.TEST_PYPI_API_TOKEN }} run: | twine upload --repository testpypi dist/* - name: Publish to PyPI if: github.event.inputs.environment == 'production' || (startsWith(github.ref, 'refs/tags/') && !contains(github.ref, 'rc')) env: TWINE_USERNAME: __token__ TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }} run: | twine upload dist/* - name: Create GitHub Release if: startsWith(github.ref, 'refs/tags/') uses: actions/create-release@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ github.ref }} release_name: Release ${{ github.ref }} draft: false prerelease: ${{ contains(github.ref, 'rc') }} post-release: needs: release runs-on: ubuntu-latest if: startsWith(github.ref, 'refs/tags/') steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v4 with: python-version: ${{ env.PYTHON_VERSION }} - name: Test installation from PyPI run: | sleep 60 # Attendre la propagation sur PyPI pip install playlist-downloader playlist-downloader --version - name: Update documentation run: | # Script pour mettre à jour la documentation echo "Documentation updated for version ${GITHUB_REF#refs/tags/}"</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_diagrammes_darchitecture">7. Diagrammes d’Architecture</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_diagramme_de_séquence_processus_de_release">7.1. Diagramme de Séquence - Processus de Release</h3> <div class="imageblock"> <div class="content"> <img src="images/diag-plantuml-md5-8e5219ce8920793948bdafac8a3427ec.png" alt="Diagram" width="942" height="832"> </div> </div> </div> <div class="sect2"> <h3 id="_diagramme_détats_cycle_de_vie_du_package">7.2. Diagramme d’États - Cycle de Vie du Package</h3> <div class="imageblock"> <div class="content"> <img src="images/diag-plantuml-md5-2d132096cb63b0042bccf620fc284f91.png" alt="Diagram" width="525" height="740"> </div> </div> </div> <div class="sect2"> <h3 id="_diagramme_de_déploiement_infrastructure_cicd">7.3. Diagramme de Déploiement - Infrastructure CI/CD</h3> <div class="imageblock"> <div class="content"> <img src="images/diag-plantuml-md5-590851667decb6042a455cb888cc4200.png" alt="Diagram" width="682" height="604"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_objets_et_modèles_du_pipeline">8. Objets et Modèles du Pipeline</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_diagramme_de_classes_modèles_cicd">8.1. Diagramme de Classes - Modèles CI/CD</h3> <div class="imageblock"> <div class="content"> <img src="images/diag-plantuml-md5-510e3cb608857126a0dcae824abe3148.png" alt="Diagram" width="814" height="635"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_des_secrets">9. Configuration des Secrets</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour que le pipeline fonctionne, vous devez configurer les secrets suivants dans GitHub :</p> </div> <div class="sect2"> <h3 id="_secrets_github_actions">9.1. Secrets GitHub Actions</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="bash"># Dans Settings > Secrets and variables > Actions # Token PyPI pour la production PYPI_API_TOKEN=pypi-... # Token Test PyPI pour les pré-releases TEST_PYPI_API_TOKEN=pypi-... # Token GitHub pour créer les releases GITHUB_TOKEN=(automatiquement fourni) # Token Codecov (optionnel) CODECOV_TOKEN=...</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_génération_des_tokens_pypi">9.2. Génération des Tokens PyPI</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="bash"># 1. Créer un compte sur PyPI et Test PyPI # 2. Aller dans Account Settings > API tokens # 3. Créer un token avec scope "Entire account" ou spécifique au projet # 4. Format du token : pypi-AgEIcHlwaS5vcmc...</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_scripts_de_développement_local">10. Scripts de Développement Local</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour faciliter le développement, créez des scripts utilitaires :</p> </div> <div class="sect2"> <h3 id="_makefile">10.1. Makefile</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="makefile">.PHONY: install test lint format security build clean release-test release-prod install: pip install -e ".[dev]" test: pytest tests/ -v --cov=src/playlist_downloader lint: flake8 src tests mypy src format: black src tests security: bandit -r src/ safety check build: python -m build twine check dist/* clean: rm -rf build/ dist/ *.egg-info/ find . -type d -name __pycache__ -delete find . -name "*.pyc" -delete release-test: clean build twine upload --repository testpypi dist/* release-prod: clean build twine upload dist/* pre-commit: format lint test security @echo "✅ Prêt pour commit"</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_script_de_version">10.2. Script de Version</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="python">#!/usr/bin/env python3 """Script pour gérer les versions du projet.""" import sys import subprocess from pathlib import Path def get_current_version(): """Récupère la version actuelle depuis git.""" try: result = subprocess.run( ["git", "describe", "--tags", "--abbrev=0"], capture_output=True, text=True, check=True ) return result.stdout.strip() except subprocess.CalledProcessError: return "0.0.0" def create_version_tag(version, message=None): """Crée un tag de version.""" if not version.startswith('v'): version = f'v{version}' tag_message = message or f"Release {version}" subprocess.run(["git", "tag", "-a", version, "-m", tag_message], check=True) print(f"✅ Tag {version} créé") # Push le tag subprocess.run(["git", "push", "origin", version], check=True) print(f"✅ Tag {version} poussé vers origin") if __name__ == "__main__": if len(sys.argv) < 2: current = get_current_version() print(f"Version actuelle: {current}") print("Usage: python version.py <new_version> [message]") sys.exit(1) new_version = sys.argv[1] message = sys.argv[2] if len(sys.argv) > 2 else None create_version_tag(new_version, message)</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_bonnes_pratiques_et_recommandations">11. Bonnes Pratiques et Recommandations</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_versioning_sémantique">11.1. Versioning Sémantique</h3> <div class="paragraph"> <p>Utilisez le versioning sémantique (SemVer) :</p> </div> <div class="ulist"> <ul> <li> <p><code>MAJOR.MINOR.PATCH</code> (ex: 1.2.3)</p> </li> <li> <p><code>MAJOR</code> : changements incompatibles</p> </li> <li> <p><code>MINOR</code> : nouvelles fonctionnalités compatibles</p> </li> <li> <p><code>PATCH</code> : corrections de bugs compatibles</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_stratégie_de_branching">11.2. Stratégie de Branching</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="text">main ──●──●──●──●──●────●── (releases stables) / / / develop ──●──●──●──●──●──●──●──●── (développement) / / / feature/xxx ●──●──●──●──●──/ (fonctionnalités)</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_tests_et_couverture">11.3. Tests et Couverture</h3> <div class="ulist"> <ul> <li> <p>Couverture de code minimum : 85%</p> </li> <li> <p>Tests unitaires pour la logique métier</p> </li> <li> <p>Tests d’intégration pour les adapters</p> </li> <li> <p>Tests de bout en bout pour les CLI</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_sécurité">11.4. Sécurité</h3> <div class="ulist"> <ul> <li> <p>Scan automatique des dépendances (Safety)</p> </li> <li> <p>Analyse statique du code (Bandit)</p> </li> <li> <p>Secrets jamais dans le code</p> </li> <li> <p>Utilisation de tokens PyPI spécifiques</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_monitoring_et_observabilité">12. Monitoring et Observabilité</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_métriques_de_pipeline">12.1. Métriques de Pipeline</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml"># .github/workflows/metrics.yml name: Pipeline Metrics on: workflow_run: workflows: ["CI", "Release"] types: [completed] jobs: metrics: runs-on: ubuntu-latest steps: - name: Collect metrics run: | echo "Pipeline: ${{ github.event.workflow_run.name }}" echo "Status: ${{ github.event.workflow_run.conclusion }}" echo "Duration: ${{ github.event.workflow_run.updated_at - github.event.workflow_run.created_at }}" # Envoyer vers système de monitoring</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_notifications">12.2. Notifications</h3> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml"># Ajout dans les workflows pour notifications - name: Notify on failure if: failure() uses: 8398a7/action-slack@v3 with: status: failure text: "❌ Pipeline failed for ${{ github.repository }}" env: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">13. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce pipeline CI/CD complet pour Python offre :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Automatisation complète</strong> : de la validation du code à la publication</p> </li> <li> <p><strong>Sécurité</strong> : scans automatiques et gestion sécurisée des secrets</p> </li> <li> <p><strong>Qualité</strong> : tests multi-versions, linting et couverture de code</p> </li> <li> <p><strong>Fiabilité</strong> : déploiement progressif via Test PyPI</p> </li> <li> <p><strong>Traçabilité</strong> : artifacts, rapports et releases GitHub</p> </li> </ul> </div> <div class="paragraph"> <p>L’adoption de ces pratiques garantit un processus de livraison robuste et professionnel pour vos applications Python CLI, facilitant la maintenance et l’évolution de vos projets sur le long terme.</p> </div> </div> </div> <div class="sect1"> <h2 id="_ressources_complémentaires">14. Ressources Complémentaires</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://packaging.python.org/">Python Packaging User Guide</a></p> </li> <li> <p><a href="https://docs.github.com/en/actions">GitHub Actions Documentation</a></p> </li> <li> <p><a href="https://pypi.org/help/">PyPI Help Documentation</a></p> </li> <li> <p><a href="https://semver.org/">Semantic Versioning Specification</a></p> </li> <li> <p><a href="https://keepachangelog.com/">Keep a Changelog</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2025/0085_pypi_cicd_part_1_post.html Thu, 17 Jul 2025 00:00:00 +0000 blog/2025/0085_pypi_cicd_part_1_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_architecture_du_pipeline">2. Architecture du Pipeline</a></li> <li><a href="#_configuration_du_pipeline_dintégration_continue_ci">3. Configuration du Pipeline d’Intégration Continue (CI)</a> <ul class="sectlevel2"> <li><a href="#_structure_du_workflow_ci">3.1. Structure du Workflow CI</a></li> <li><a href="#_analyse_des_étapes_ci">3.2. Analyse des Étapes CI</a> <ul class="sectlevel3"> <li><a href="#_1_déclencheurs_on">3.2.1. 1. Déclencheurs (<code>on</code>)</a></li> <li><a href="#_2_environnement_dexécution">3.2.2. 2. Environnement d’Exécution</a></li> <li><a href="#_3_checkout_du_code">3.2.3. 3. Checkout du Code</a></li> <li><a href="#_4_configuration_python">3.2.4. 4. Configuration Python</a></li> <li><a href="#_5_installation_des_dépendances">3.2.5. 5. Installation des Dépendances</a></li> <li><a href="#_6_linting_avec_ruff">3.2.6. 6. Linting avec Ruff</a></li> <li><a href="#_7_exécution_des_tests">3.2.7. 7. Exécution des Tests</a></li> </ul> </li> </ul> </li> <li><a href="#_configuration_du_pipeline_de_déploiement_cd">4. Configuration du Pipeline de Déploiement (CD)</a> <ul class="sectlevel2"> <li><a href="#_structure_du_workflow_cd">4.1. Structure du Workflow CD</a></li> <li><a href="#_analyse_des_étapes_cd">4.2. Analyse des Étapes CD</a> <ul class="sectlevel3"> <li><a href="#_1_déclencheur_release">4.2.1. 1. Déclencheur Release</a></li> <li><a href="#_2_installation_des_outils_de_build">4.2.2. 2. Installation des Outils de Build</a></li> <li><a href="#_3_configuration_de_lauthentification">4.2.3. 3. Configuration de l’Authentification</a></li> <li><a href="#_4_build_et_publication">4.2.4. 4. Build et Publication</a></li> </ul> </li> </ul> </li> <li><a href="#_configuration_du_package_python">5. Configuration du Package Python</a> <ul class="sectlevel2"> <li><a href="#_structure_du_setup_py">5.1. Structure du setup.py</a></li> <li><a href="#_points_clés_du_setup_py">5.2. Points Clés du setup.py</a></li> </ul> </li> <li><a href="#_sécurisation_avec_les_github_secrets">6. Sécurisation avec les GitHub Secrets</a> <ul class="sectlevel2"> <li><a href="#_configuration_du_token_pypi">6.1. Configuration du Token PyPI</a></li> </ul> </li> <li><a href="#_workflow_de_déploiement_complet">7. Workflow de Déploiement Complet</a> <ul class="sectlevel2"> <li><a href="#_séquence_de_déploiement">7.1. Séquence de Déploiement</a></li> <li><a href="#_états_du_pipeline">7.2. États du Pipeline</a></li> </ul> </li> <li><a href="#_bonnes_pratiques_et_optimisations">8. Bonnes Pratiques et Optimisations</a> <ul class="sectlevel2"> <li><a href="#_1_gestion_des_versions">8.1. 1. Gestion des Versions</a></li> <li><a href="#_2_tests_de_matrice">8.2. 2. Tests de Matrice</a></li> <li><a href="#_3_cache_des_dépendances">8.3. 3. Cache des Dépendances</a></li> <li><a href="#_4_environnements_de_déploiement">8.4. 4. Environnements de Déploiement</a></li> </ul> </li> <li><a href="#_cas_dusage_et_architecture">9. Cas d’Usage et Architecture</a> <ul class="sectlevel2"> <li><a href="#_diagramme_de_cas_dusage">9.1. Diagramme de Cas d’Usage</a></li> <li><a href="#_architecture_du_déploiement">9.2. Architecture du Déploiement</a></li> </ul> </li> <li><a href="#_surveillance_et_debugging">10. Surveillance et Debugging</a> <ul class="sectlevel2"> <li><a href="#_logs_et_monitoring">10.1. Logs et Monitoring</a></li> <li><a href="#_notifications">10.2. Notifications</a></li> </ul> </li> <li><a href="#_conclusion">11. Conclusion</a></li> <li><a href="#_ressources_complémentaires">12. Ressources Complémentaires</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title">Objectif :</div> <p>Accompagner le lecteur dans la mise en place d’un pipeline CI/CD minimaliste mais fonctionnel pour une application Python, avec un déploiement automatique sur PyPI.</p> </div> </div> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’automatisation des processus de développement est devenue incontournable dans les projets modernes. Un pipeline CI/CD bien conçu permet non seulement de détecter les régressions tôt dans le cycle de développement, mais aussi d’automatiser entièrement le processus de déploiement.</p> </div> <div class="paragraph"> <p>Dans cet article, nous allons explorer comment mettre en place un pipeline complet avec GitHub Actions pour une application Python, de l’intégration continue (CI) au déploiement continu (CD) sur PyPI.</p> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_du_pipeline">2. Architecture du Pipeline</h2> <div class="sectionbody"> <div class="paragraph"> <p>Notre pipeline se compose de deux workflows distincts :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>CI Pipeline</strong> : Exécuté sur chaque push et pull request</p> </li> <li> <p><strong>CD Pipeline</strong> : Déclenché uniquement lors des releases GitHub</p> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="images/ci-cd-overview.svg" alt="ci cd overview" width="394" height="648"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_du_pipeline_dintégration_continue_ci">3. Configuration du Pipeline d’Intégration Continue (CI)</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_structure_du_workflow_ci">3.1. Structure du Workflow CI</h3> <div class="paragraph"> <p>Le workflow CI est conçu pour valider chaque contribution au code. Voici sa configuration complète :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">name: CI/CD Pipeline on: push: branches: - main pull_request: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.x' - name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt pip install ruff pytest pytest-mock - name: Run Linting (Ruff) run: ruff check . - name: Run Tests (Pytest) run: pytest</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_analyse_des_étapes_ci">3.2. Analyse des Étapes CI</h3> <div class="sect3"> <h4 id="_1_déclencheurs_on">3.2.1. 1. Déclencheurs (<code>on</code>)</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">on: push: branches: - main pull_request: branches: - main</code></pre> </div> </div> <div class="paragraph"> <p>Le pipeline se déclenche sur : - Chaque push sur la branche <code>main</code> - Chaque pull request vers <code>main</code></p> </div> <div class="paragraph"> <p>Cette approche garantit que le code principal reste stable et que toute contribution est validée avant intégration.</p> </div> </div> <div class="sect3"> <h4 id="_2_environnement_dexécution">3.2.2. 2. Environnement d’Exécution</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">runs-on: ubuntu-latest</code></pre> </div> </div> <div class="paragraph"> <p>Ubuntu Latest offre un bon compromis entre performance, coût et compatibilité pour la plupart des projets Python.</p> </div> </div> <div class="sect3"> <h4 id="_3_checkout_du_code">3.2.3. 3. Checkout du Code</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Checkout code uses: actions/checkout@v4</code></pre> </div> </div> <div class="paragraph"> <p>L’action <code>checkout@v4</code> récupère le code source du repository. La version v4 apporte des améliorations de performance et de sécurité.</p> </div> </div> <div class="sect3"> <h4 id="_4_configuration_python">3.2.4. 4. Configuration Python</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.x'</code></pre> </div> </div> <div class="paragraph"> <p>L’utilisation de <code>'3.x'</code> permet d’automatiquement utiliser la dernière version stable de Python 3, simplifiant la maintenance.</p> </div> </div> <div class="sect3"> <h4 id="_5_installation_des_dépendances">3.2.5. 5. Installation des Dépendances</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt pip install ruff pytest pytest-mock</code></pre> </div> </div> <div class="paragraph"> <p>Cette étape : - Met à jour pip vers la dernière version - Installe les dépendances du projet - Ajoute les outils de développement (linting et tests)</p> </div> </div> <div class="sect3"> <h4 id="_6_linting_avec_ruff">3.2.6. 6. Linting avec Ruff</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Run Linting (Ruff) run: ruff check .</code></pre> </div> </div> <div class="paragraph"> <p><strong>Ruff</strong> est un linter Python ultra-rapide écrit en Rust. Il combine les fonctionnalités de plusieurs outils (Flake8, Black, isort) en un seul outil performant.</p> </div> </div> <div class="sect3"> <h4 id="_7_exécution_des_tests">3.2.7. 7. Exécution des Tests</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Run Tests (Pytest) run: pytest</code></pre> </div> </div> <div class="paragraph"> <p>Pytest exécute l’ensemble de la suite de tests, garantissant que les modifications n’introduisent pas de régressions.</p> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_du_pipeline_de_déploiement_cd">4. Configuration du Pipeline de Déploiement (CD)</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_structure_du_workflow_cd">4.1. Structure du Workflow CD</h3> <div class="paragraph"> <p>Le workflow CD se déclenche uniquement lors des releases GitHub et automatise la publication sur PyPI :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">name: Publish to PyPI on: release: types: - published jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.x' - name: Install dependencies run: | python -m pip install --upgrade pip pip install setuptools wheel twine - name: Build and publish env: TWINE_USERNAME: __token__ TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }} run: | python setup.py sdist bdist_wheel twine upload dist/*</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_analyse_des_étapes_cd">4.2. Analyse des Étapes CD</h3> <div class="sect3"> <h4 id="_1_déclencheur_release">4.2.1. 1. Déclencheur Release</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">on: release: types: - published</code></pre> </div> </div> <div class="paragraph"> <p>Le pipeline CD ne se déclenche que lors de la publication d’une release GitHub. Cette approche assure un contrôle précis des déploiements.</p> </div> </div> <div class="sect3"> <h4 id="_2_installation_des_outils_de_build">4.2.2. 2. Installation des Outils de Build</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">pip install setuptools wheel twine</code></pre> </div> </div> <div class="ulist"> <ul> <li> <p><strong>setuptools</strong> : Outils de packaging Python</p> </li> <li> <p><strong>wheel</strong> : Format de distribution Python moderne</p> </li> <li> <p><strong>twine</strong> : Outil sécurisé pour uploader vers PyPI</p> </li> </ul> </div> </div> <div class="sect3"> <h4 id="_3_configuration_de_lauthentification">4.2.3. 3. Configuration de l’Authentification</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">env: TWINE_USERNAME: __token__ TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }}</code></pre> </div> </div> <div class="paragraph"> <p>L’authentification utilise un token API PyPI stocké comme secret GitHub, plus sécurisé que les identifiants classiques.</p> </div> </div> <div class="sect3"> <h4 id="_4_build_et_publication">4.2.4. 4. Build et Publication</h4> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">run: | python setup.py sdist bdist_wheel twine upload dist/*</code></pre> </div> </div> <div class="ulist"> <ul> <li> <p><code>sdist</code> : Crée une distribution source</p> </li> <li> <p><code>bdist_wheel</code> : Crée une wheel (distribution binaire)</p> </li> <li> <p><code>twine upload</code> : Publie les distributions sur PyPI</p> </li> </ul> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_du_package_python">5. Configuration du Package Python</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_structure_du_setup_py">5.1. Structure du setup.py</h3> <div class="paragraph"> <p>Pour que le pipeline fonctionne, votre projet doit inclure un fichier <code>setup.py</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="python">from setuptools import setup, find_packages with open("README.adoc", "r", encoding="utf-8") as fh: long_description = fh.read() setup( name="playlist-downloader", version="1.0.0", author="Votre Nom", author_email="votre.email@example.com", description="CLI tool for managing YouTube playlists", long_description=long_description, long_description_content_type="text/plain", url="https://github.com/cheroliv/playlist-downloader", packages=find_packages(), classifiers=[ "Development Status :: 4 - Beta", "Intended Audience :: Developers", "License :: OSI Approved :: MIT License", "Operating System :: OS Independent", "Programming Language :: Python :: 3", "Programming Language :: Python :: 3.8", "Programming Language :: Python :: 3.9", "Programming Language :: Python :: 3.10", "Programming Language :: Python :: 3.11", ], python_requires=">=3.8", install_requires=[ "typer>=0.9.0", "yt-dlp>=2023.1.6", "google-api-python-client>=2.70.0", "google-auth-oauthlib>=0.7.1", "pymonad>=2.4.0", "pyyaml>=6.0", ], entry_points={ "console_scripts": [ "playlist-downloader=cli:app", ], }, )</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_points_clés_du_setup_py">5.2. Points Clés du setup.py</h3> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Métadonnées</strong> : Nom, version, auteur, description</p> </li> <li> <p><strong>Dépendances</strong> : Liste des packages requis</p> </li> <li> <p><strong>Entry Points</strong> : Commandes CLI exposées</p> </li> <li> <p><strong>Classifiers</strong> : Métadonnées pour PyPI</p> </li> </ol> </div> </div> </div> </div> <div class="sect1"> <h2 id="_sécurisation_avec_les_github_secrets">6. Sécurisation avec les GitHub Secrets</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_configuration_du_token_pypi">6.1. Configuration du Token PyPI</h3> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Créer un token API sur PyPI</strong> :</p> <div class="ulist"> <ul> <li> <p>Connectez-vous à PyPI</p> </li> <li> <p>Allez dans Account Settings > API tokens</p> </li> <li> <p>Créez un nouveau token avec les permissions appropriées</p> </li> </ul> </div> </li> <li> <p><strong>Ajouter le secret dans GitHub</strong> :</p> <div class="ulist"> <ul> <li> <p>Repository Settings > Secrets and variables > Actions</p> </li> <li> <p>Créez un nouveau secret nommé <code>PYPI_API_TOKEN</code></p> </li> <li> <p>Collez votre token PyPI</p> </li> </ul> </div> </li> </ol> </div> <div class="imageblock"> <div class="content"> <img src="images/secrets-flow.svg" alt="secrets flow" width="899" height="405"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_workflow_de_déploiement_complet">7. Workflow de Déploiement Complet</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_séquence_de_déploiement">7.1. Séquence de Déploiement</h3> <div class="imageblock"> <div class="content"> <img src="images/deployment-sequence.svg" alt="deployment sequence" width="961" height="648"> </div> </div> </div> <div class="sect2"> <h3 id="_états_du_pipeline">7.2. États du Pipeline</h3> <div class="imageblock"> <div class="content"> <img src="images/pipeline-states.svg" alt="pipeline states" width="962" height="346"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_bonnes_pratiques_et_optimisations">8. Bonnes Pratiques et Optimisations</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_1_gestion_des_versions">8.1. 1. Gestion des Versions</h3> <div class="paragraph"> <p>Utilisez des tags Git sémantiques :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="bash">git tag -a v1.2.3 -m "Release version 1.2.3" git push origin v1.2.3</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_2_tests_de_matrice">8.2. 2. Tests de Matrice</h3> <div class="paragraph"> <p>Pour tester sur plusieurs versions Python :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">strategy: matrix: python-version: [3.8, 3.9, "3.10", "3.11"]</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_3_cache_des_dépendances">8.3. 3. Cache des Dépendances</h3> <div class="paragraph"> <p>Accélérez les builds avec le cache :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Cache pip dependencies uses: actions/cache@v3 with: path: ~/.cache/pip key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_4_environnements_de_déploiement">8.4. 4. Environnements de Déploiement</h3> <div class="paragraph"> <p>Utilisez les environnements GitHub pour des déploiements contrôlés :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">jobs: deploy: environment: production runs-on: ubuntu-latest</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_cas_dusage_et_architecture">9. Cas d’Usage et Architecture</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_diagramme_de_cas_dusage">9.1. Diagramme de Cas d’Usage</h3> <div class="imageblock"> <div class="content"> <img src="images/use-cases.svg" alt="use cases" width="449" height="370"> </div> </div> </div> <div class="sect2"> <h3 id="_architecture_du_déploiement">9.2. Architecture du Déploiement</h3> <div class="imageblock"> <div class="content"> <img src="images/deployment-architecture.svg" alt="deployment architecture" width="650" height="700"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_surveillance_et_debugging">10. Surveillance et Debugging</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_logs_et_monitoring">10.1. Logs et Monitoring</h3> <div class="paragraph"> <p>GitHub Actions fournit des logs détaillés pour chaque étape. Pour débugger :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Examinez les logs</strong> de chaque step</p> </li> <li> <p><strong>Activez le debug</strong> avec <code>ACTIONS_STEP_DEBUG</code></p> </li> <li> <p><strong>Utilisez des artifacts</strong> pour sauvegarder les fichiers de build</p> </li> </ol> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Upload build artifacts uses: actions/upload-artifact@v3 if: failure() with: name: build-logs path: build/</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_notifications">10.2. Notifications</h3> <div class="paragraph"> <p>Ajoutez des notifications Slack ou email :</p> </div> <div class="listingblock"> <div class="content"> <pre class="pygments highlight"><code data-lang="yaml">- name: Notify on failure if: failure() uses: 8398a7/action-slack@v3 with: status: ${{ job.status }} webhook_url: ${{ secrets.SLACK_WEBHOOK }}</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">11. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>La mise en place d’un pipeline CI/CD robuste avec GitHub Actions transforme radicalement l’expérience de développement. En automatisant le linting, les tests et le déploiement, vous :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Réduisez les erreurs</strong> en production</p> </li> <li> <p><strong>Accélérez les cycles</strong> de développement</p> </li> <li> <p><strong>Améliorez la confiance</strong> dans vos releases</p> </li> <li> <p><strong>Facilitez la collaboration</strong> en équipe</p> </li> </ul> </div> <div class="paragraph"> <p>Ce pipeline peut être adapté à différents types de projets Python en ajustant les outils de linting, les frameworks de test, ou les destinations de déploiement.</p> </div> <div class="paragraph"> <p>L’investissement initial dans la configuration de ces workflows est rapidement rentabilisé par le gain de temps et la réduction des erreurs manuelles lors des déploiements.</p> </div> </div> </div> <div class="sect1"> <h2 id="_ressources_complémentaires">12. Ressources Complémentaires</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><a href="https://docs.github.com/en/actions">Documentation GitHub Actions</a></p> </li> <li> <p><a href="https://packaging.python.org/">Python Packaging Guide</a></p> </li> <li> <p><a href="https://docs.pytest.org/">Documentation Pytest</a></p> </li> <li> <p><a href="https://docs.astral.sh/ruff/">Documentation Ruff</a></p> </li> <li> <p><a href="https://twine.readthedocs.io/">Documentation Twine</a></p> </li> </ul> </div> <div class="paragraph"> <p>✅ Pipeline fonctionnel atteint ! Vous avez désormais un pipeline CI/CD simple qui vous permet d’automatiser vos tests et de publier votre package Python sur PyPI directement depuis GitHub Actions.</p> </div> <div class="paragraph"> <p>Cependant, ce pipeline reste volontairement minimaliste. Il ne couvre pas encore certains aspects indispensables dans un contexte professionnel :</p> </div> <div class="literalblock"> <div class="content"> <pre>Tests multi-versions de Python,</pre> </div> </div> <div class="literalblock"> <div class="content"> <pre>Analyse de sécurité automatique,</pre> </div> </div> <div class="literalblock"> <div class="content"> <pre>Déploiement progressif via Test PyPI,</pre> </div> </div> <div class="literalblock"> <div class="content"> <pre>Surveillance et métriques du pipeline,</pre> </div> </div> <div class="literalblock"> <div class="content"> <pre>Automatisation du versioning et intégration des bonnes pratiques modernes (pyproject.toml).</pre> </div> </div> <div class="paragraph"> <p>Dans la prochaine partie, nous allons passer à l’étape supérieure. Vous apprendrez à transformer ce pipeline de base en une véritable chaîne de déploiement industrielle, robuste et sécurisée, prête pour des projets Python de production.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0084_disco_bot_discord_python_post.html Wed, 16 Jul 2025 00:00:00 +0000 blog/2025/0084_disco_bot_discord_python_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_contexte_et_défis_actuels">2. Contexte et Défis Actuels</a> <ul class="sectlevel2"> <li><a href="#_évolution_des_apis_musicales">2.1. Évolution des APIs Musicales</a></li> <li><a href="#_approche_log_driven_development">2.2. Approche Log Driven Development</a></li> </ul> </li> <li><a href="#_architecture_conceptuelle">3. Architecture Conceptuelle</a></li> <li><a href="#_stack_technique_et_paradigme_fonctionnel">4. Stack Technique et Paradigme Fonctionnel</a> <ul class="sectlevel2"> <li><a href="#_choix_technologiques">4.1. Choix Technologiques</a></li> <li><a href="#_principes_fonctionnels_appliqués">4.2. Principes Fonctionnels Appliqués</a></li> </ul> </li> <li><a href="#_méthodologie_agile_et_backlog">5. Méthodologie Agile et Backlog</a> <ul class="sectlevel2"> <li><a href="#_epic_principales">5.1. Epic Principales</a> <ul class="sectlevel3"> <li><a href="#_epic_1_infrastructure_bot_discord">5.1.1. Epic 1 : Infrastructure Bot Discord</a></li> <li><a href="#_epic_2_intégration_spotify">5.1.2. Epic 2 : Intégration Spotify</a></li> <li><a href="#_epic_3_intégration_youtube">5.1.3. Epic 3 : Intégration YouTube</a></li> <li><a href="#_epic_4_fonctionnalités_musicales">5.1.4. Epic 4 : Fonctionnalités Musicales</a></li> </ul> </li> <li><a href="#_user_stories_détaillées">5.2. User Stories Détaillées</a> <ul class="sectlevel3"> <li><a href="#_us1_1_initialisation_du_bot">5.2.1. US1.1 : Initialisation du Bot</a></li> <li><a href="#_us2_1_recherche_spotify_intelligente">5.2.2. US2.1 : Recherche Spotify Intelligente</a></li> <li><a href="#_us3_1_extraction_youtube_resiliente">5.2.3. US3.1 : Extraction YouTube Resiliente</a></li> </ul> </li> </ul> </li> <li><a href="#_approche_log_driven_development_2">6. Approche Log Driven Development</a> <ul class="sectlevel2"> <li><a href="#_stratégie_de_logging">6.1. Stratégie de Logging</a></li> <li><a href="#_structure_des_logs">6.2. Structure des Logs</a></li> <li><a href="#_exemple_de_log_design">6.3. Exemple de Log Design</a></li> </ul> </li> <li><a href="#_architecture_de_validation_avec_pydantic">7. Architecture de Validation avec Pydantic</a> <ul class="sectlevel2"> <li><a href="#_modèles_de_données">7.1. Modèles de Données</a></li> </ul> </li> <li><a href="#_gestion_des_erreurs_fonctionnelle">8. Gestion des Erreurs Fonctionnelle</a> <ul class="sectlevel2"> <li><a href="#_monades_et_error_handling">8.1. Monades et Error Handling</a></li> </ul> </li> <li><a href="#_stratégie_de_contournement_des_restrictions">9. Stratégie de Contournement des Restrictions</a> <ul class="sectlevel2"> <li><a href="#_approche_multi_source">9.1. Approche Multi-Source</a></li> </ul> </li> <li><a href="#_plan_de_développement_itératif">10. Plan de Développement Itératif</a> <ul class="sectlevel2"> <li><a href="#_sprint_planning">10.1. Sprint Planning</a></li> <li><a href="#_métriques_de_qualité">10.2. Métriques de Qualité</a></li> </ul> </li> <li><a href="#_déploiement_et_monitoring">11. Déploiement et Monitoring</a> <ul class="sectlevel2"> <li><a href="#_architecture_de_production">11.1. Architecture de Production</a></li> <li><a href="#_monitoring_proactif">11.2. Monitoring Proactif</a></li> </ul> </li> <li><a href="#_conclusion_et_perspectives">12. Conclusion et Perspectives</a> <ul class="sectlevel2"> <li><a href="#_prochaines_étapes">12.1. Prochaines Étapes</a></li> </ul> </li> </ul> </div> <div class="sect1"> <h2 id="_introduction"><a class="anchor" href="#_introduction"></a>1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le développement d’un bot Discord intégrant les APIs Spotify et YouTube représente un défi technique moderne, notamment face aux récentes restrictions et évolutions des plateformes. Cet article présente une approche méthodologique basée sur le <strong>Log Driven Development</strong> (LDD), une extension du Test Driven Development, appliquée dans un paradigme fonctionnel avec Python.</p> </div> <div class="paragraph"> <p>Notre objectif : créer un bot robuste, maintenable et évolutif, capable de naviguer les contraintes actuelles des APIs musicales tout en offrant une expérience utilisateur fluide sur Discord.</p> </div> </div> </div> <div class="sect1"> <h2 id="_contexte_et_défis_actuels"><a class="anchor" href="#_contexte_et_défis_actuels"></a>2. Contexte et Défis Actuels</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_évolution_des_apis_musicales"><a class="anchor" href="#_évolution_des_apis_musicales"></a>2.1. Évolution des APIs Musicales</h3> <div class="paragraph"> <p>Les plateformes musicales ont considérablement durci leurs politiques d’accès :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Spotify</strong> : Restrictions sur l’accès aux métadonnées, limitation des quotas</p> </li> <li> <p><strong>YouTube</strong> : Politique anti-bot renforcée, complexification de l’authentification</p> </li> <li> <p><strong>Discord</strong> : Nouvelles exigences de sécurité et de performance</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_approche_log_driven_development"><a class="anchor" href="#_approche_log_driven_development"></a>2.2. Approche Log Driven Development</h3> <div class="paragraph"> <p>Le LDD étend le TDD en plaçant les logs au cœur du développement :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Définition des logs</strong> avant l’implémentation</p> </li> <li> <p><strong>Validation par observation</strong> des comportements attendus</p> </li> <li> <p><strong>Traçabilité complète</strong> des flux de données</p> </li> <li> <p><strong>Debugging proactif</strong> par anticipation des erreurs</p> </li> </ol> </div> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_conceptuelle"><a class="anchor" href="#_architecture_conceptuelle"></a>3. Architecture Conceptuelle</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-086b9caf633e5b3a704d7962a864373a.png" alt="Diagram" width="777" height="618"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_stack_technique_et_paradigme_fonctionnel"><a class="anchor" href="#_stack_technique_et_paradigme_fonctionnel"></a>4. Stack Technique et Paradigme Fonctionnel</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_choix_technologiques"><a class="anchor" href="#_choix_technologiques"></a>4.1. Choix Technologiques</h3> <div class="paragraph"> <p>Notre stack s’articule autour de la programmation fonctionnelle :</p> </div> <div class="dlist"> <dl> <dt class="hdlist1"><strong>PyMonade</strong> </dt> <dd> <p>Gestion des effets de bord et composition de fonctions</p> </dd> <dt class="hdlist1"><strong>Pydantic</strong> </dt> <dd> <p>Validation de données type-safe et sérialisation</p> </dd> <dt class="hdlist1"><strong>Asyncio</strong> </dt> <dd> <p>Programmation asynchrone pour les APIs</p> </dd> <dt class="hdlist1"><strong>Structlog</strong> </dt> <dd> <p>Logging structuré pour le LDD</p> </dd> </dl> </div> </div> <div class="sect2"> <h3 id="_principes_fonctionnels_appliqués"><a class="anchor" href="#_principes_fonctionnels_appliqués"></a>4.2. Principes Fonctionnels Appliqués</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-430159f75aabab4ced1766bbd98cc2d0.png" alt="Diagram" width="701" height="554"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_méthodologie_agile_et_backlog"><a class="anchor" href="#_méthodologie_agile_et_backlog"></a>5. Méthodologie Agile et Backlog</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_epic_principales"><a class="anchor" href="#_epic_principales"></a>5.1. Epic Principales</h3> <div class="paragraph"> <p>Notre développement s’organise autour de 4 épics majeures :</p> </div> <div class="sect3"> <h4 id="_epic_1_infrastructure_bot_discord"><a class="anchor" href="#_epic_1_infrastructure_bot_discord"></a>5.1.1. Epic 1 : Infrastructure Bot Discord</h4> <div class="paragraph"> <p><strong>Valeur métier</strong> : Base solide et extensible</p> </div> <div class="paragraph"> <p><strong>Critères d’acceptation</strong> : - Connexion Discord stable avec gestion de reconnexion - Système de commandes modulaire - Logging structuré intégré - Gestion d’erreurs centralisée</p> </div> </div> <div class="sect3"> <h4 id="_epic_2_intégration_spotify"><a class="anchor" href="#_epic_2_intégration_spotify"></a>5.1.2. Epic 2 : Intégration Spotify</h4> <div class="paragraph"> <p><strong>Valeur métier</strong> : Accès aux métadonnées musicales</p> </div> <div class="paragraph"> <p><strong>Critères d’acceptation</strong> : - Authentification OAuth2 sécurisée - Recherche de tracks avec cache intelligent - Gestion des quotas API - Fallback sur erreurs réseau</p> </div> </div> <div class="sect3"> <h4 id="_epic_3_intégration_youtube"><a class="anchor" href="#_epic_3_intégration_youtube"></a>5.1.3. Epic 3 : Intégration YouTube</h4> <div class="paragraph"> <p><strong>Valeur métier</strong> : Accès au contenu audio</p> </div> <div class="paragraph"> <p><strong>Critères d’acceptation</strong> : - Contournement légal des restrictions - Extraction audio optimisée - Gestion des vidéos privées/supprimées - Respect des ToS YouTube</p> </div> </div> <div class="sect3"> <h4 id="_epic_4_fonctionnalités_musicales"><a class="anchor" href="#_epic_4_fonctionnalités_musicales"></a>5.1.4. Epic 4 : Fonctionnalités Musicales</h4> <div class="paragraph"> <p><strong>Valeur métier</strong> : Expérience utilisateur complète</p> </div> <div class="paragraph"> <p><strong>Critères d’acceptation</strong> : - Lecture audio haute qualité - Queue de lecture intelligente - Commandes vocales Discord - Synchronisation cross-platform</p> </div> </div> </div> <div class="sect2"> <h3 id="_user_stories_détaillées"><a class="anchor" href="#_user_stories_détaillées"></a>5.2. User Stories Détaillées</h3> <div class="sect3"> <h4 id="_us1_1_initialisation_du_bot"><a class="anchor" href="#_us1_1_initialisation_du_bot"></a>5.2.1. US1.1 : Initialisation du Bot</h4> <div class="paragraph"> <p><strong>En tant que</strong> développeur <strong>Je veux</strong> un bot Discord qui se connecte de manière fiable <strong>Afin de</strong> garantir la disponibilité du service</p> </div> <div class="paragraph"> <p><strong>DoD (Definition of Done)</strong> : - [ ] Bot se connecte automatiquement au démarrage - [ ] Logs structurés documentent chaque étape - [ ] Reconnexion automatique en cas de déconnexion - [ ] Tests d’intégration passent</p> </div> </div> <div class="sect3"> <h4 id="_us2_1_recherche_spotify_intelligente"><a class="anchor" href="#_us2_1_recherche_spotify_intelligente"></a>5.2.2. US2.1 : Recherche Spotify Intelligente</h4> <div class="paragraph"> <p><strong>En tant qu'</strong> utilisateur Discord <strong>Je veux</strong> rechercher des morceaux via Spotify <strong>Afin de</strong> découvrir et partager de la musique</p> </div> <div class="paragraph"> <p><strong>DoD</strong> : - [ ] Commande <code>/search</code> fonctionnelle - [ ] Résultats pertinents avec métadonnées - [ ] Cache local pour optimiser les requêtes - [ ] Gestion gracieuse des erreurs API</p> </div> </div> <div class="sect3"> <h4 id="_us3_1_extraction_youtube_resiliente"><a class="anchor" href="#_us3_1_extraction_youtube_resiliente"></a>5.2.3. US3.1 : Extraction YouTube Resiliente</h4> <div class="paragraph"> <p><strong>En tant que</strong> système <strong>Je veux</strong> extraire l’audio YouTube de manière fiable <strong>Afin de</strong> maintenir la continuité du service</p> </div> <div class="paragraph"> <p><strong>DoD</strong> : - [ ] Extraction sans violation des ToS - [ ] Qualité audio optimale - [ ] Gestion des restrictions géographiques - [ ] Logs détaillés des opérations</p> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_approche_log_driven_development_2"><a class="anchor" href="#_approche_log_driven_development_2"></a>6. Approche Log Driven Development</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_stratégie_de_logging"><a class="anchor" href="#_stratégie_de_logging"></a>6.1. Stratégie de Logging</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-79d957417244512294c169ebb2d6b88a.png" alt="Diagram" width="687" height="633"> </div> </div> </div> <div class="sect2"> <h3 id="_structure_des_logs"><a class="anchor" href="#_structure_des_logs"></a>6.2. Structure des Logs</h3> <div class="paragraph"> <p>Notre approche LDD utilise des logs structurés avec des niveaux sémantiques :</p> </div> <div class="dlist"> <dl> <dt class="hdlist1"><strong>TRACE</strong> </dt> <dd> <p>Flux de données détaillé</p> </dd> <dt class="hdlist1"><strong>DEBUG</strong> </dt> <dd> <p>États internes des fonctions</p> </dd> <dt class="hdlist1"><strong>INFO</strong> </dt> <dd> <p>Opérations métier réussies</p> </dd> <dt class="hdlist1"><strong>WARN</strong> </dt> <dd> <p>Situations dégradées mais gérées</p> </dd> <dt class="hdlist1"><strong>ERROR</strong> </dt> <dd> <p>Erreurs nécessitant intervention</p> </dd> <dt class="hdlist1"><strong>CRITICAL</strong> </dt> <dd> <p>Pannes système</p> </dd> </dl> </div> </div> <div class="sect2"> <h3 id="_exemple_de_log_design"><a class="anchor" href="#_exemple_de_log_design"></a>6.3. Exemple de Log Design</h3> <div class="paragraph"> <p>Avant d’implémenter la fonction de recherche Spotify, nous définissons ses logs :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">INFO: spotify.search.start query="bohemian rhapsody" user_id=123456 DEBUG: spotify.search.validation query_length=16 safe_chars=true DEBUG: spotify.search.api_call endpoint="/search" params={...} INFO: spotify.search.success results_count=15 duration_ms=340</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_de_validation_avec_pydantic"><a class="anchor" href="#_architecture_de_validation_avec_pydantic"></a>7. Architecture de Validation avec Pydantic</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_modèles_de_données"><a class="anchor" href="#_modèles_de_données"></a>7.1. Modèles de Données</h3> <div class="paragraph"> <p>Notre approche fonctionnelle privilégie la validation en amont :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-c6fae117aa98299175aac2f8bb11c734.png" alt="Diagram" width="696" height="339"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_gestion_des_erreurs_fonctionnelle"><a class="anchor" href="#_gestion_des_erreurs_fonctionnelle"></a>8. Gestion des Erreurs Fonctionnelle</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_monades_et_error_handling"><a class="anchor" href="#_monades_et_error_handling"></a>8.1. Monades et Error Handling</h3> <div class="paragraph"> <p>L’utilisation de PyMonade permet une gestion élégante des erreurs :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-d256bdb87b36125ca20f18b0f9756180.png" alt="Diagram" width="494" height="494"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_stratégie_de_contournement_des_restrictions"><a class="anchor" href="#_stratégie_de_contournement_des_restrictions"></a>9. Stratégie de Contournement des Restrictions</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_approche_multi_source"><a class="anchor" href="#_approche_multi_source"></a>9.1. Approche Multi-Source</h3> <div class="paragraph"> <p>Face aux restrictions des APIs, nous adoptons une stratégie de diversification :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-1631d63ee04755eae439c5d595af9534.png" alt="Diagram" width="665" height="744"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_plan_de_développement_itératif"><a class="anchor" href="#_plan_de_développement_itératif"></a>10. Plan de Développement Itératif</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_sprint_planning"><a class="anchor" href="#_sprint_planning"></a>10.1. Sprint Planning</h3> <div class="paragraph"> <p>Notre développement suit un cycle de sprints de 2 semaines :</p> </div> <div class="dlist"> <dl> <dt class="hdlist1"><strong>Sprint 1-2</strong> </dt> <dd> <p>Infrastructure et Discord Bot Core</p> </dd> <dt class="hdlist1"><strong>Sprint 3-4</strong> </dt> <dd> <p>Intégration Spotify avec LDD</p> </dd> <dt class="hdlist1"><strong>Sprint 5-6</strong> </dt> <dd> <p>Intégration YouTube et contournements</p> </dd> <dt class="hdlist1"><strong>Sprint 7-8</strong> </dt> <dd> <p>Features musicales avancées</p> </dd> <dt class="hdlist1"><strong>Sprint 9-10</strong> </dt> <dd> <p>Optimisation et production</p> </dd> </dl> </div> </div> <div class="sect2"> <h3 id="_métriques_de_qualité"><a class="anchor" href="#_métriques_de_qualité"></a>10.2. Métriques de Qualité</h3> <div class="paragraph"> <p>Chaque sprint est évalué sur :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Couverture de logs</strong> : >90% des chemins critiques</p> </li> <li> <p><strong>Fiabilité API</strong> : <1% d’erreurs non gérées</p> </li> <li> <p><strong>Performance</strong> : <500ms temps de réponse moyen</p> </li> <li> <p><strong>Maintenabilité</strong> : Complexité cyclomatique <10</p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_déploiement_et_monitoring"><a class="anchor" href="#_déploiement_et_monitoring"></a>11. Déploiement et Monitoring</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_architecture_de_production"><a class="anchor" href="#_architecture_de_production"></a>11.1. Architecture de Production</h3> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-2049b13cbdd9eed68076ed557f938d6d.png" alt="Diagram" width="938" height="381"> </div> </div> </div> <div class="sect2"> <h3 id="_monitoring_proactif"><a class="anchor" href="#_monitoring_proactif"></a>11.2. Monitoring Proactif</h3> <div class="paragraph"> <p>Le LDD facilite un monitoring intelligent :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Alertes basées sur les patterns de logs</strong></p> </li> <li> <p><strong>Détection d’anomalies comportementales</strong></p> </li> <li> <p><strong>Métriques métier en temps réel</strong></p> </li> <li> <p><strong>Debugging assisté par corrélation de logs</strong></p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion_et_perspectives"><a class="anchor" href="#_conclusion_et_perspectives"></a>12. Conclusion et Perspectives</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette approche méthodologique combine les bénéfices du paradigme fonctionnel avec la robustesse du Log Driven Development. Elle nous permet de :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Anticiper les problèmes</strong> grâce aux logs conçus en amont</p> </li> <li> <p><strong>Maintenir la qualité</strong> via la validation continue</p> </li> <li> <p><strong>Adapter rapidement</strong> aux changements d’APIs</p> </li> <li> <p><strong>Assurer la traçabilité</strong> complète des opérations</p> </li> </ol> </div> <div class="paragraph"> <p>Le développement itératif et l’architecture modulaire garantissent une évolutivité face aux contraintes changeantes des plateformes musicales.</p> </div> <div class="sect2"> <h3 id="_prochaines_étapes"><a class="anchor" href="#_prochaines_étapes"></a>12.1. Prochaines Étapes</h3> <div class="ulist"> <ul> <li> <p><strong>Phase 1</strong> : Implémentation du core avec PyMonade</p> </li> <li> <p><strong>Phase 2</strong> : Intégration Spotify avec cache intelligent</p> </li> <li> <p><strong>Phase 3</strong> : Solution YouTube résiliente</p> </li> <li> <p><strong>Phase 4</strong> : Features avancées et optimisation</p> </li> </ul> </div> <div class="paragraph"> <p>Cette fondation conceptuelle solide nous permettra de naviguer les défis techniques tout en livrant une expérience utilisateur exceptionnelle.</p> </div> <hr> <div class="paragraph"> <p><strong>Cet article sera suivi d’une série technique détaillant l’implémentation de chaque composant avec exemples de code et patterns fonctionnels.</strong></p> </div> </div> </div> </div> https://pages-content.github.io//blog/2025/0083_cold_computer_post.html Tue, 15 Jul 2025 00:00:00 +0000 blog/2025/0083_cold_computer_post.html <div id="toc" class="toc"> <div id="toctitle">Table of Contents</div> <ul class="sectlevel1"> <li><a href="#_objectif_de_ce_guide">1. Objectif de ce guide</a></li> <li><a href="#_prérequis">2. Prérequis</a></li> <li><a href="#_installer_et_configurer_les_outils">3. Installer et configurer les outils</a> <ul class="sectlevel2"> <li><a href="#_lm_sensors_pour_détecter_les_capteurs">3.1. <code>lm-sensors</code> pour détecter les capteurs</a></li> <li><a href="#_tlp_gestionnaire_dénergie_intelligent">3.2. <code>tlp</code> : gestionnaire d’énergie intelligent</a></li> <li><a href="#_cpufrequtils_limiter_les_fréquences_cpu">3.3. <code>cpufrequtils</code> : limiter les fréquences CPU</a></li> <li><a href="#_auto_cpufreq_gestion_dynamique_simplifiée">3.4. <code>auto-cpufreq</code> : gestion dynamique simplifiée</a></li> <li><a href="#_thermald_protection_thermique_automatique">3.5. <code>thermald</code> : protection thermique automatique</a></li> </ul> </li> <li><a href="#_surveillance_en_temps_réel">4. Surveillance en temps réel</a> <ul class="sectlevel2"> <li><a href="#_sensors_en_ligne_de_commande">4.1. <code>sensors</code> en ligne de commande</a></li> <li><a href="#_option_gui_psensor">4.2. Option GUI : <code>psensor</code></a></li> </ul> </li> <li><a href="#_astuces_supplémentaires">5. Astuces supplémentaires</a></li> <li><a href="#_nettoyer_le_système_pour_limiter_les_surcharges">6. Nettoyer le système pour limiter les surcharges</a></li> <li><a href="#_pour_aller_plus_loin">7. Pour aller plus loin</a></li> <li><a href="#_conclusion">8. 📚 Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>Vous sentez que votre ordinateur portable chauffe anormalement sous Ubuntu ? Cet article vous propose une démarche <strong>logicielle</strong> complète pour <strong>refroidir</strong>, <strong>surveiller</strong> et <strong>maîtriser la température</strong> de votre machine.</p> </div> </div> </div> <div class="sect1"> <h2 id="_objectif_de_ce_guide">1. Objectif de ce guide</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Réduire la température globale de l’ordinateur</p> </li> <li> <p>Optimiser la gestion d’énergie</p> </li> <li> <p>Surveiller les composants critiques (CPU, GPU, etc.)</p> </li> <li> <p>Éviter les ralentissements dus au <strong>thermal throttling</strong></p> </li> </ul> </div> <div class="imageblock"> <div class="content"> <img src="gestion_thermique.svg" alt="gestion thermique" width="392" height="298"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_prérequis">2. Prérequis</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Une machine Ubuntu (20.04 ou supérieure recommandée)</p> </li> <li> <p>Connexion Internet</p> </li> <li> <p>Compétence en ligne de commande (niveau débutant à intermédiaire)</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_installer_et_configurer_les_outils">3. Installer et configurer les outils</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_lm_sensors_pour_détecter_les_capteurs">3.1. <code>lm-sensors</code> pour détecter les capteurs</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install lm-sensors sudo sensors-detect sensors</code></pre> </div> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p>Répondez <code>YES</code> à toutes les questions de <code>sensors-detect</code> pour détecter les modules.</p> </div> </td> </tr> </table> </div> </div> <div class="sect2"> <h3 id="_tlp_gestionnaire_dénergie_intelligent">3.2. <code>tlp</code> : gestionnaire d’énergie intelligent</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install tlp tlp-rdw sudo systemctl enable tlp sudo systemctl start tlp</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="tlp_etat.svg" alt="tlp etat" width="363" height="390"> </div> </div> </div> <div class="sect2"> <h3 id="_cpufrequtils_limiter_les_fréquences_cpu">3.3. <code>cpufrequtils</code> : limiter les fréquences CPU</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install cpufrequtils cpufreq-info sudo cpufreq-set -g powersave</code></pre> </div> </div> <div class="ulist"> <ul> <li> <p><code>powersave</code> : limite les pics de fréquence</p> </li> <li> <p><code>performance</code> : favorise la puissance au détriment de la température</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_auto_cpufreq_gestion_dynamique_simplifiée">3.4. <code>auto-cpufreq</code> : gestion dynamique simplifiée</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">git clone https://github.com/AdnanHodzic/auto-cpufreq.git cd auto-cpufreq sudo ./auto-cpufreq-installer sudo auto-cpufreq --install</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="auto_cpufreq_cycle.svg" alt="auto cpufreq cycle" width="189" height="298"> </div> </div> </div> <div class="sect2"> <h3 id="_thermald_protection_thermique_automatique">3.5. <code>thermald</code> : protection thermique automatique</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install thermald sudo systemctl enable thermald sudo systemctl start thermald</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_surveillance_en_temps_réel">4. Surveillance en temps réel</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_sensors_en_ligne_de_commande">4.1. <code>sensors</code> en ligne de commande</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">watch -n 2 sensors</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_option_gui_psensor">4.2. Option GUI : <code>psensor</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install psensor</code></pre> </div> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Interface graphique simple pour CPU, GPU, ventilateurs.</p> </div> </blockquote> </div> </div> </div> </div> <div class="sect1"> <h2 id="_astuces_supplémentaires">5. Astuces supplémentaires</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Fermer les onglets et applications lourdes (ex: navigateurs)</p> </li> <li> <p>Éviter les utilisations intenses sur batterie</p> </li> <li> <p>Surveiller les processus via <code>htop</code> :</p> </li> </ul> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt install htop htop</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_nettoyer_le_système_pour_limiter_les_surcharges">6. Nettoyer le système pour limiter les surcharges</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">sudo apt autoremove sudo apt autoclean sudo journalctl --vacuum-time=3d</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_pour_aller_plus_loin">7. Pour aller plus loin</h2> <div class="sectionbody"> <div class="paragraph"> <p>Vous pouvez créer un service <code>systemd</code> personnalisé pour appliquer automatiquement certains réglages au démarrage. Souhaitez-vous un exemple dans un prochain article ? Faites-le moi savoir !</p> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">8. 📚 Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>En combinant ces outils simples, vous gagnerez :</p> </div> <div class="ulist"> <ul> <li> <p>Une température CPU maîtrisée</p> </li> <li> <p>Moins de bruit de ventilation</p> </li> <li> <p>Une meilleure autonomie</p> </li> </ul> </div> <div class="paragraph"> <p>N’oubliez pas de surveiller vos températures régulièrement pour prévenir toute surchauffe.</p> </div> <div class="quoteblock"> <blockquote> <div class="paragraph"> <p>Mieux vaut prévenir que fondre son CPU.</p> </div> </blockquote> <div class="attribution"> — cheroliv </div> </div> </div> </div> https://pages-content.github.io//blog/2025/0082_ui_struggle_post.html Mon, 14 Jul 2025 00:00:00 +0000 blog/2025/0082_ui_struggle_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_le_champ_de_bataille_une_maquette_trois_navigateurs_des_rendus_multiples">1. Le champ de bataille : une maquette, trois navigateurs, des rendus multiples</a></li> <li><a href="#_problème_1_la_carte_volante_de_la_section_hero">2. Problème 1 : La carte volante de la section "Hero"</a></li> <li><a href="#_problème_2_la_barre_de_navigation_cannibale">3. Problème 2 : La barre de navigation cannibale</a></li> <li><a href="#_problème_3_la_typographie_anarchique">4. Problème 3 : La typographie anarchique</a></li> <li><a href="#_problème_4_la_barre_de_navigation_qui_déborde">5. Problème 4 : La barre de navigation qui déborde</a></li> <li><a href="#_problème_5_le_menu_hamburger_invisible">6. Problème 5 : Le menu hamburger invisible</a></li> <li><a href="#_conclusion_les_leçons_dun_débogage_acharné">7. Conclusion : les leçons d’un débogage acharné</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <i class="fa icon-note" title="Note"></i> </td> <td class="content"> <div class="paragraph"> <p><strong>Temps de lecture :</strong> environ 7 minutes <strong>Niveau :</strong> Intermédiaire</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>Dans ce cas pratique détaillé, nous allons disséquer les problèmes de compatibilité navigateur les plus courants et parfois les plus frustrants rencontrés lors de la création d’une maquette UI avec Bootstrap 5.2. De la gestion Flexbox à la subtilité du rendu des polices, découvrez notre parcours de débogage pour transformer un design bancal sous Firefox en une expérience pixel-perfect sur tous les navigateurs.</p> </div> <hr> </div> </div> <div class="sect1"> <h2 id="_le_champ_de_bataille_une_maquette_trois_navigateurs_des_rendus_multiples">1. Le champ de bataille : une maquette, trois navigateurs, des rendus multiples</h2> <div class="sectionbody"> <div class="paragraph"> <p>Tout développeur front-end connaît ce sentiment. Après des heures de travail, la maquette est enfin parfaite. Les alignements sont nets, la typographie est élégante, les animations sont fluides. On pousse un soupir de satisfaction, on admire son travail sur Chrome (ou Brave, ou Edge), puis, par acquis de conscience, on ouvre le projet sur Firefox. Et là, c’est le drame. Des éléments qui débordent, des alignements brisés, des polices aux tailles anarchiques…​ la belle harmonie s’est envolée.</p> </div> <div class="paragraph"> <p>C’est précisément le scénario que nous avons affronté en développant une nouvelle interface de portfolio. Le cahier des charges était simple : une page d’accueil moderne, responsive, avec un sélecteur de thèmes (clair, sombre, et à fort contraste), en utilisant <strong>vanilla JavaScript</strong> et la dernière version de <strong>Bootstrap 5.2</strong>.</p> </div> <div class="paragraph"> <p>Cet article n’est pas une liste de solutions miracles. C’est le journal de bord de notre session de débogage, une plongée dans le "pourquoi" des différences de rendu entre les moteurs Blink (Chromium, Brave) et Gecko (Firefox), et la démonstration que des solutions robustes et modernes valent toujours mieux que des rustines à la hâte.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/usecase-debugging-firefox.svg" alt="usecase debugging firefox" width="1045" height="401"> </div> <div class="title">Figure 1. Diagramme de Cas d’Utilisation : Le processus de débogage</div> </div> <div class="imageblock"> <div class="content"> <img src="./images/components-solution-architecture.svg" alt="components solution architecture" width="1286" height="188"> </div> <div class="title">Figure 2. Diagramme de Composants : Architecture de la solution front-end</div> </div> </div> </div> <div class="sect1"> <h2 id="_problème_1_la_carte_volante_de_la_section_hero">2. Problème 1 : La carte volante de la section "Hero"</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le premier bug était aussi le plus visible. La section d’accueil ("hero") est composée de deux colonnes : à gauche, le titre principal ; à droite, une carte de présentation.</p> </div> <div class="ulist"> <ul> <li> <p><strong>Le symptôme :</strong> Sur Chrome et Brave, les deux colonnes étaient parfaitement centrées verticalement. Sur Firefox, la carte de droite chutait inexplicablement en dessous du texte de gauche.</p> </li> <li> <p><strong>L’investigation :</strong> Le code HTML semblait pourtant simple et correct, utilisant les classes standards de Bootstrap.</p> </li> </ul> </div> <div class="listingblock"> <div class="title">Structure HTML initiale de la section Hero</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><section id="home" class="hero-section"> <div class="container"> <!-- Cette ligne est la clé du problème --> <div class="row align-items-center min-vh-100"> <div class="col-lg-6"> <!-- Contenu de gauche --> </div> <div class="col-lg-6"> <!-- Carte de droite --> </div> </div> </div> </section></code></pre> </div> </div> <div class="paragraph"> <p>Notre CSS personnalisé pour <code>.hero-section</code> définissait <code>display: flex</code> et <code>align-items: center</code>, et la classe <code>min-vh-100</code> donnait bien une hauteur minimale à la ligne (<code>div.row</code>). Alors, pourquoi Firefox refusait-il de centrer les colonnes ?</p> </div> <div class="ulist"> <ul> <li> <p><strong>La cause profonde :</strong> C’est un cas d’école sur la manière dont les moteurs de rendu interprètent les hauteurs implicites. La <code><section></code> avait une <code>min-height</code>, mais pas de <code>height</code> explicite. Pour appliquer <code>align-items-center</code> à l’intérieur de <code>div.row</code>, Firefox a besoin de connaître la hauteur de référence de ce conteneur. Comme ses parents (<code>div.container</code> et la <code><section></code> elle-même) n’avaient pas de hauteur <strong>stricte</strong>, Firefox était perdu. Le moteur Blink, plus permissif, arrive à "deviner" l’intention et à centrer les éléments. Gecko, plus fidèle à la spécification, ne le fait pas.</p> </li> <li> <p><strong>La solution :</strong> Rendre la hauteur explicite. Nous avons forcé le <code>.container</code> et le <code>.row</code> à occuper 100% de la hauteur de leur parent respectif en utilisant la classe utilitaire <code>h-100</code> de Bootstrap.</p> </li> </ul> </div> <div class="listingblock"> <div class="title">Structure HTML corrigée</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><section id="home" class="hero-section"> <div class="container h-100"> <div class="row align-items-center min-vh-100 h-100"> <!-- ... --> </div> </div> </section></code></pre> </div> </div> <div class="admonitionblock tip"> <table> <tr> <td class="icon"> <i class="fa icon-tip" title="Tip"></i> </td> <td class="content"> <div class="paragraph"> <p>Lorsqu’un <code>align-items</code> Flexbox ne fonctionne pas comme prévu sur l’axe vertical, vérifiez toujours que le conteneur a une hauteur (<code>height</code> ou <code>min-height</code>) définie et, si le problème persiste (surtout sur Firefox), assurez-vous que les conteneurs parents intermédiaires propagent bien cette hauteur.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="_problème_2_la_barre_de_navigation_cannibale">3. Problème 2 : La barre de navigation cannibale</h2> <div class="sectionbody"> <div class="ulist"> <div class="title">Une fois la section "Hero" alignée, un autre problème est apparu : la barre de navigation, avec sa classe <code>fixed-top</code>, se superposait au titre. Un <code>padding-top: 80px</code> avait été appliqué à la section "Hero" en guise de solution.</div> <ul> <li> <p><strong>Le symptôme :</strong> Le <code>padding</code> était suffisant sur Chrome, mais pas sur Firefox, où le titre était toujours partiellement masqué.</p> </li> <li> <p><strong>La cause profonde :</strong> L’utilisation d’un "nombre magique" (<code>80px</code>) est une très mauvaise pratique. La hauteur d’un élément comme une barre de navigation peut varier de quelques pixels d’un navigateur à l’autre à cause de différences subtiles dans le rendu des polices, des espacements, ou même des options de l’utilisateur. Se fier à une valeur fixe est la recette pour un design fragile.</p> </li> <li> <p><strong>La solution :</strong> Une solution dynamique et infaillible en JavaScript. Nous avons écrit un petit script pour :</p> <div class="olist arabic"> <ol class="arabic"> <li> <p>Mesurer la hauteur <strong>réelle</strong> de la barre de navigation après le rendu de la page.</p> </li> <li> <p>Appliquer cette hauteur mesurée comme <code>padding-top</code> à la section "Hero".</p> </li> <li> <p>Ré-exécuter cette fonction à chaque redimensionnement de la fenêtre pour s’adapter aux changements (comme le passage au menu hamburger).</p> </li> </ol> </div> </li> </ul> </div> <div class="listingblock"> <div class="title">Fichier: script.js - La solution dynamique</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-javascript hljs" data-lang="javascript">document.addEventListener('DOMContentLoaded', function() { function adjustHeroPadding() { const navbar = document.querySelector('.navbar.fixed-top'); const heroSection = document.querySelector('.hero-section'); if (navbar && heroSection) { const navbarHeight = navbar.offsetHeight; heroSection.style.paddingTop = navbarHeight + 'px'; } } // Ajuster au chargement et au redimensionnement adjustHeroPadding(); window.addEventListener('resize', adjustHeroPadding); });</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/sequence-dynamic-padding.svg" alt="sequence dynamic padding" width="887" height="703"> </div> <div class="title">Figure 3. Diagramme de Séquence : Ajustement dynamique du padding</div> </div> <div class="paragraph"> <p>En parallèle, nous avons bien sûr supprimé la règle <code>padding-top: 80px;</code> de notre fichier <code>styles.css</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="_problème_3_la_typographie_anarchique">4. Problème 3 : La typographie anarchique</h2> <div class="sectionbody"> <div class="ulist"> <div class="title">Le souci suivant était le plus nuisible à l’image de marque : la taille du titre principal.</div> <ul> <li> <p><strong>Le symptôme :</strong> Sur Firefox, la police du titre "Développeur Formateur…​" était gigantesque, presque choquante, alors qu’elle était harmonieuse sur les autres navigateurs.</p> </li> <li> <p><strong>La cause profonde :</strong> Le titre utilisait une classe <code>display-4</code> de Bootstrap. Ces classes utilisent des tailles de police responsives, souvent basées sur l’unité <code>rem</code> et des media queries. Encore une fois, l’algorithme de rendu de Firefox, combiné à la police "Inter", aboutissait à un calcul de taille beaucoup plus grand sur notre résolution de 1920x1080.</p> </li> <li> <p><strong>La solution :</strong> Reprendre le contrôle avec la fonction CSS <code>clamp()</code>. Cette fonction est une révolution pour la typographie fluide. Elle permet de définir une taille de police avec trois valeurs : une taille minimale, une taille "préférée" (qui s’adapte à la largeur de la vue, <code>vw</code>), et une taille maximale.</p> </li> </ul> </div> <div class="listingblock"> <div class="title">Fichier: styles.css - Dompter la taille de la police</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">.hero-content h1 { color: var(--text-primary); line-height: 1.2; /* Min: 2rem Préférée: s'adapte à la vue Max: 2.5rem (40px) */ font-size: clamp(2rem, 1.2rem + 1.5vw, 2.5rem); }</code></pre> </div> </div> <div class="paragraph"> <p>Avec <code>clamp()</code>, nous avons pu dire au navigateur : "Fais grandir la police avec l’écran, mais ne dépasse <strong>jamais</strong> la limite de `2.5rem`". Cela a instantanément harmonisé le rendu sur tous les navigateurs, en nous donnant un contrôle absolu sur l’esthétique finale.</p> </div> </div> </div> <div class="sect1"> <h2 id="_problème_4_la_barre_de_navigation_qui_déborde">5. Problème 4 : La barre de navigation qui déborde</h2> <div class="sectionbody"> <div class="ulist"> <div class="title">C’est le problème qui nous a donné le plus de fil à retordre et qui a finalement révélé la nature profonde des micro-différences de rendu.</div> <ul> <li> <p><strong>Le symptôme :</strong> Sur un écran de 1920x1080, les derniers liens du menu ("Blog", "Contact") étaient poussés hors de l’écran sur la droite, mais uniquement sur Firefox.</p> </li> <li> <p><strong>La cause profonde :</strong> Après plusieurs tentatives infructueuses (changer les points de rupture de Bootstrap de <code>lg</code> à <code>xl</code> puis <code>xxl</code>), nous avons compris. La cause n’était pas la logique de Bootstrap, mais un simple calcul de largeur. Sur Firefox, la somme des largeurs de tous les liens, incluant leurs <code>padding</code> et <code>margin</code> au sub-pixel près, était <strong>légèrement</strong> supérieure à 1920 pixels. Sur Chrome, cette même somme était <strong>légèrement</strong> inférieure. Il nous manquait quelques pixels.</p> </li> <li> <p><strong>La solution :</strong> Une réduction chirurgicale des espacements. Puisqu’il était hors de question de cibler spécifiquement Firefox avec des "hacks" CSS obsolètes, la seule solution propre était de trouver un style commun qui fonctionne partout. Nous avons donc légèrement réduit les marges et le padding horizontaux de chaque lien de navigation.</p> </li> </ul> </div> <div class="listingblock"> <div class="title">Fichier: styles.css - Gagner les pixels manquants</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">/* La version finale, légèrement plus compacte */ .navbar-nav .nav-link { font-size: 0.9rem; /* 90% de la taille de base */ color: var(--text-primary) !important; font-weight: 500; margin: 0 0.2rem; padding: 0.5rem 0.5rem !important; border-radius: 0.375rem; transition: all 0.3s ease; }</code></pre> </div> </div> <div class="paragraph"> <p>Cette réduction, quasi invisible à l’œil nu sur un seul élément, nous a fait gagner collectivement l’espace nécessaire pour que tous les liens rentrent dans le cadre sur Firefox, tout en conservant une apparence quasi identique sur les autres navigateurs.</p> </div> </div> </div> <div class="sect1"> <h2 id="_problème_5_le_menu_hamburger_invisible">6. Problème 5 : Le menu hamburger invisible</h2> <div class="sectionbody"> <div class="ulist"> <div class="title">Le dernier problème, et non des moindres, concernait l’accessibilité sur mobile.</div> <ul> <li> <p><strong>Le symptôme :</strong> En mode responsive (menu "hamburger"), l’icône du menu était invisible sur les thèmes "dark" et "high-contrast".</p> </li> <li> <p><strong>La cause profonde :</strong> L’icône du menu de Bootstrap 5 est un <code>background-image</code> (un SVG encodé en URL). Par défaut, la couleur de son trait est foncée, optimisée pour un fond clair. Elle ne s’adapte pas automatiquement au changement de thème.</p> </li> <li> <p><strong>La solution :</strong> Utiliser les variables CSS de Bootstrap pour surcharger l’icône. Nous avons défini une nouvelle icône SVG, mais cette fois avec un trait blanc (<code>#ffffff</code>), et nous l’avons appliquée spécifiquement lorsque les thèmes <code>dark</code> ou <code>high-contrast</code> sont actifs.</p> </li> </ul> </div> <div class="listingblock"> <div class="title">Fichier: styles.css - Rendre l’icône visible</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-css hljs" data-lang="css">/* ====================== Fix pour l'icône du menu Burger (Blanc) ====================== */ [data-bs-theme="dark"] .navbar-toggler-icon, [data-bs-theme="high-contrast"] .navbar-toggler-icon { --bs-navbar-toggler-icon-bg: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 30 30'%3e%3cpath stroke='%23ffffff' stroke-linecap='round' stroke-miterlimit='10' stroke-width='2' d='M4 7h22M4 15h22M4 23h22'/%3e%3c/svg%3e"); }</code></pre> </div> </div> <div class="admonitionblock important"> <table> <tr> <td class="icon"> <i class="fa icon-important" title="Important"></i> </td> <td class="content"> <div class="paragraph"> <p>La personnalisation des composants de Bootstrap comme celui-ci se fait de plus en plus via la surcharge de variables CSS (<code>--bs-component-property</code>), qui est la méthode la plus propre et la plus pérenne.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion_les_leçons_dun_débogage_acharné">7. Conclusion : les leçons d’un débogage acharné</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce parcours, bien que parfois frustrant, est riche d’enseignements. Chaque problème résolu renforce une vérité fondamentale du développement web : <strong>rien ne remplace un test multi-navigateurs rigoureux</strong>.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/mindmap-debugging-summary.svg" alt="mindmap debugging summary" width="999" height="866"> </div> <div class="title">Figure 4. Mindmap : Synthèse du débogage et des leçons apprises</div> </div> <div class="olist arabic"> <div class="title">Voici les leçons que nous retenons :</div> <ol class="arabic"> <li> <p><strong>Firefox est un allié :</strong> Sa plus grande fidélité aux standards CSS nous force à écrire un code plus robuste et moins ambigu.</p> </li> <li> <p><strong>Fuyez les "nombres magiques" :</strong> Les valeurs fixes (comme <code>padding-top: 80px</code>) sont des bombes à retardement. Préférez toujours des solutions dynamiques (JavaScript) ou relatives (Flexbox, Grid).</p> </li> <li> <p><strong>Maîtrisez votre typographie :</strong> Utilisez <code>clamp()</code> pour un contrôle total sur la taille des polices responsives.</p> </li> <li> <p><strong>Pensez en "composants" :</strong> Pour personnaliser Bootstrap, surchargez ses variables CSS plutôt que de multiplier les règles qui écrasent le framework.</p> </li> <li> <p><strong>Ne ciblez pas un navigateur :</strong> La solution n’est presque jamais de faire un "hack" pour un navigateur spécifique, mais de trouver un style commun qui fonctionne partout.</p> </li> </ol> </div> <div class="paragraph"> <p>Au final, la maquette est maintenant solide, prévisible, et prête à être intégrée dans un système de templating. Chaque bug corrigé n’était pas un échec, mais une étape vers un code de meilleure qualité.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0081_TDD_Gradle_Properties_Fix_post.html Sun, 13 Jul 2025 00:00:00 +0000 blog/2025/0081_TDD_Gradle_Properties_Fix_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_le_problème_isoler_les_tests_unitaires_dun_plugin_gradle">1. Le Problème : Isoler les Tests Unitaires d’un Plugin Gradle</a> <ul class="sectlevel2"> <li><a href="#_architecture_du_problème">1.1. Architecture du Problème</a></li> <li><a href="#_la_tentation_dune_fausse_bonne_idée">1.2. La Tentation d’une Fausse Bonne Idée</a></li> </ul> </li> <li><a href="#_la_solution_simuler_la_propriété_avec_extrapropertiesextension">2. La Solution : Simuler la Propriété avec <code>ExtraPropertiesExtension</code></a> <ul class="sectlevel2"> <li><a href="#_étape_1_comprendre_extrapropertiesextension">2.1. Étape 1 : Comprendre ExtraPropertiesExtension</a></li> <li><a href="#_étape_2_mise_en_place_du_test_préparation">2.2. Étape 2 : Mise en Place du Test - Préparation</a></li> <li><a href="#_étape_3_injection_de_la_propriété">2.3. Étape 3 : Injection de la Propriété</a></li> <li><a href="#_étape_4_diagramme_de_flux_de_la_solution">2.4. Étape 4 : Diagramme de Flux de la Solution</a></li> <li><a href="#_étape_5_comparaison_avantaprès">2.5. Étape 5 : Comparaison Avant/Après</a></li> <li><a href="#_étape_6_gestion_des_cas_de_test_multiples">2.6. Étape 6 : Gestion des Cas de Test Multiples</a></li> <li><a href="#_architecture_finale_de_la_solution">2.7. Architecture Finale de la Solution</a></li> </ul> </li> <li><a href="#_les_avantages_de_cette_approche">3. Les Avantages de cette Approche</a></li> <li><a href="#_bonnes_pratiques_et_conseils">4. Bonnes Pratiques et Conseils</a> <ul class="sectlevel2"> <li><a href="#_créer_une_méthode_utilitaire">4.1. Créer une Méthode Utilitaire</a></li> <li><a href="#_validation_des_propriétés">4.2. Validation des Propriétés</a></li> </ul> </li> <li><a href="#_conclusion">5. Conclusion</a></li> </ul> </div> <div class="sect1"> <h2 id="_le_problème_isoler_les_tests_unitaires_dun_plugin_gradle">1. Le Problème : Isoler les Tests Unitaires d’un Plugin Gradle</h2> <div class="sectionbody"> <div class="paragraph"> <p>Lors de l’écriture de tests unitaires pour un plugin Gradle, un défi courant est de gérer les dépendances à la configuration du projet, comme les propriétés définies dans le fichier <code>gradle.properties</code>. Dans notre cas, le plugin <code>jbake.ghpages</code> devait lire une propriété <code>site_config_path</code> pour fonctionner correctement. Le test unitaire pour la tâche <code>initialize</code> devait vérifier le comportement du plugin en présence de cette propriété.</p> </div> <div class="paragraph"> <p>Le problème fondamental est que les tests unitaires, par conception, doivent être <strong>isolés</strong>. L’utilisation de <code>ProjectBuilder</code> de Gradle crée une instance de <code>Project</code> en mémoire, complètement déconnectée d’un véritable projet sur le système de fichiers. Par conséquent, cette instance de test ne lit pas automatiquement le fichier <code>gradle.properties</code> et n’a donc pas connaissance de la propriété <code>site_config_path</code>.</p> </div> <div class="sect2"> <h3 id="_architecture_du_problème">1.1. Architecture du Problème</h3> <div class="paragraph"> <p>Le diagramme suivant illustre la déconnexion entre l’environnement de test et le système de fichiers :</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/test-isolation-problem.svg" alt="test isolation problem" width="833" height="295"> </div> </div> </div> <div class="sect2"> <h3 id="_la_tentation_dune_fausse_bonne_idée">1.2. La Tentation d’une Fausse Bonne Idée</h3> <div class="paragraph"> <p>Une première approche pourrait être de créer un fichier <code>gradle.properties</code> factice dans les ressources du test.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-text hljs" data-lang="text">// src/test/resources/gradle.properties site_config_path=src/jbake/settings/site.yml</code></pre> </div> </div> <div class="paragraph"> <p>Cependant, cette méthode est vouée à l’échec car <code>ProjectBuilder</code> n’est pas conçu pour scanner le système de fichiers à la recherche de fichiers de configuration. Le test resterait isolé et ignorerait ce fichier.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_la_solution_simuler_la_propriété_avec_extrapropertiesextension">2. La Solution : Simuler la Propriété avec <code>ExtraPropertiesExtension</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>La solution élégante à ce problème n’est pas de <strong>lire</strong> le fichier, mais de <strong>simuler</strong> la présence de la propriété directement dans l’objet <code>Project</code> de test. Gradle fournit un mécanisme puissant pour cela : les <strong>propriétés supplémentaires</strong> (Extra Properties).</p> </div> <div class="sect2"> <h3 id="_étape_1_comprendre_extrapropertiesextension">2.1. Étape 1 : Comprendre ExtraPropertiesExtension</h3> <div class="paragraph"> <p><code>ExtraPropertiesExtension</code> est un conteneur clé-valeur attaché à chaque objet du modèle Gradle. Il permet d’ajouter des propriétés dynamiquement à un projet, une tâche, ou toute autre extension Gradle.</p> </div> <div class="imageblock"> <div class="content"> <img src="./images/extra-properties-architecture.svg" alt="extra properties architecture" width="533" height="436"> </div> </div> </div> <div class="sect2"> <h3 id="_étape_2_mise_en_place_du_test_préparation">2.2. Étape 2 : Mise en Place du Test - Préparation</h3> <div class="paragraph"> <p>Commençons par créer la structure de base de notre test unitaire :</p> </div> <div class="listingblock"> <div class="title">JbakeGhPagesPluginTest.kt - Structure de base</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class JbakeGhPagesPluginTest { @TempDir lateinit var testProjectDir: File @Test fun `check initialize and config yaml file if not existing`() { // Étape 1 : Créer un projet de test isolé val project = ProjectBuilder.builder() .withProjectDir(testProjectDir) .build() // Suite des étapes... } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_étape_3_injection_de_la_propriété">2.3. Étape 3 : Injection de la Propriété</h3> <div class="paragraph"> <p>Voici le processus détaillé pour injecter la propriété dans le projet de test :</p> </div> <div class="listingblock"> <div class="title">JbakeGhPagesPluginTest.kt - Injection complète</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `check initialize and config yaml file if not existing`() { // Étape 1 : Créer un projet de test isolé en mémoire val project = ProjectBuilder.builder() .withProjectDir(testProjectDir) .build() // Étape 2 : Récupérer le gestionnaire de propriétés supplémentaires val extra = project.extensions.getByType(ExtraPropertiesExtension::class.java) // Étape 3 : Définir la propriété requise pour ce test extra.set("site_config_path", "src/jbake/settings/site.yml") // Étape 4 : Vérifier que la propriété est bien injectée assertTrue(project.hasProperty("site_config_path")) // Étape 5 : Appliquer le plugin qui pourra maintenant accéder à la propriété project.plugins.apply("jbake.ghpages") // Étape 6 : Exécuter la tâche et vérifier son comportement val task: Task = project.tasks.findByName("initialize") .apply(::assertNotNull)!! // Étape 7 : Exécuter les actions de la tâche task.actions.forEach { it.execute(task) } // Étape 8 : Assertions finales assertEquals( "src/jbake/settings/site.yml", project.properties["site_config_path"], "La propriété devrait être accessible dans le projet" ) }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_étape_4_diagramme_de_flux_de_la_solution">2.4. Étape 4 : Diagramme de Flux de la Solution</h3> <div class="imageblock"> <div class="content"> <img src="./images/solution-flow.svg" alt="solution flow" width="242" height="807"> </div> </div> </div> <div class="sect2"> <h3 id="_étape_5_comparaison_avantaprès">2.5. Étape 5 : Comparaison Avant/Après</h3> <div class="imageblock"> <div class="content"> <img src="./images/before-after-comparison.svg" alt="before after comparison" width="1304" height="399"> </div> </div> </div> <div class="sect2"> <h3 id="_étape_6_gestion_des_cas_de_test_multiples">2.6. Étape 6 : Gestion des Cas de Test Multiples</h3> <div class="paragraph"> <p>Pour tester différents scénarios, créons plusieurs tests avec des configurations variées :</p> </div> <div class="listingblock"> <div class="title">Tests multiples avec configurations différentes</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class JbakeGhPagesPluginTest { @TempDir lateinit var testProjectDir: File private fun createProjectWithProperty(propertyValue: String?): Project { val project = ProjectBuilder.builder() .withProjectDir(testProjectDir) .build() // Injection conditionnelle de la propriété propertyValue?.let { value -> val extra = project.extensions.getByType(ExtraPropertiesExtension::class.java) extra.set("site_config_path", value) } return project } @Test fun `should work with valid property`() { val project = createProjectWithProperty("src/jbake/settings/site.yml") project.plugins.apply("jbake.ghpages") val task = project.tasks.findByName("initialize")!! task.actions.forEach { it.execute(task) } // Assertions pour le cas normal assertEquals("src/jbake/settings/site.yml", project.properties["site_config_path"]) } @Test fun `should handle missing property gracefully`() { val project = createProjectWithProperty(null) // Pas de propriété project.plugins.apply("jbake.ghpages") val task = project.tasks.findByName("initialize")!! // Le plugin devrait gérer l'absence de propriété assertDoesNotThrow { task.actions.forEach { it.execute(task) } } } @Test fun `should handle invalid property path`() { val project = createProjectWithProperty("invalid/path/to/config.yml") project.plugins.apply("jbake.ghpages") val task = project.tasks.findByName("initialize")!! // Test du comportement avec un chemin invalide assertThrows<FileNotFoundException> { task.actions.forEach { it.execute(task) } } } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_architecture_finale_de_la_solution">2.7. Architecture Finale de la Solution</h3> <div class="imageblock"> <div class="content"> <img src="./images/final-architecture.svg" alt="final architecture" width="754" height="631"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_les_avantages_de_cette_approche">3. Les Avantages de cette Approche</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p><strong>Isolation Complète</strong> : Le test ne dépend d’aucun fichier externe. Il est autonome et peut s’exécuter de manière fiable dans n’importe quel environnement (local, CI/CD, etc.).</p> </li> <li> <p><strong>Clarté et Intention</strong> : Le test déclare explicitement les conditions préalables à son exécution. Quiconque lit le test voit immédiatement que le plugin nécessite la propriété <code>site_config_path</code> pour fonctionner.</p> </li> <li> <p><strong>Maintenabilité</strong> : Si le nom de la propriété change, il suffit de le mettre à jour à un seul endroit dans le test, sans avoir à manipuler des fichiers de configuration de test.</p> </li> <li> <p><strong>Flexibilité</strong> : Il devient trivial de tester différents scénarios en changeant simplement la valeur de la propriété injectée dans chaque test (valeur valide, invalide, absente, etc.).</p> </li> <li> <p><strong>Performance</strong> : Pas de lecture de fichiers, tout se passe en mémoire, ce qui rend les tests plus rapides.</p> </li> <li> <p><strong>Reproductibilité</strong> : Les tests sont déterministes car ils ne dépendent pas de l’état du système de fichiers.</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_bonnes_pratiques_et_conseils">4. Bonnes Pratiques et Conseils</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_créer_une_méthode_utilitaire">4.1. Créer une Méthode Utilitaire</h3> <div class="listingblock"> <div class="title">Méthode utilitaire pour la réutilisation</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class GradleTestUtils { companion object { fun createProjectWithProperties( projectDir: File, properties: Map<String, String> ): Project { val project = ProjectBuilder.builder() .withProjectDir(projectDir) .build() val extra = project.extensions.getByType(ExtraPropertiesExtension::class.java) properties.forEach { (key, value) -> extra.set(key, value) } return project } } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_validation_des_propriétés">4.2. Validation des Propriétés</h3> <div class="listingblock"> <div class="title">Validation robuste</div> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">@Test fun `should validate property injection`() { val project = createProjectWithProperty("test-value") // Vérifications multiples assertTrue(project.hasProperty("site_config_path")) assertEquals("test-value", project.property("site_config_path")) assertNotNull(project.properties["site_config_path"]) // Vérification que la propriété est accessible par le plugin project.plugins.apply("jbake.ghpages") // ... reste du test }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">5. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Plutôt que de lutter pour faire lire des fichiers de configuration à un environnement de test unitaire, la meilleure pratique consiste à simuler l’état requis. L’utilisation de <code>ExtraPropertiesExtension</code> pour définir par programme les propriétés Gradle est la méthode la plus propre et la plus robuste pour réaliser des tests unitaires de plugins efficaces et fiables.</p> </div> <div class="paragraph"> <p>Cette technique transforme un problème de dépendance externe en une simple injection de dépendance, au cœur même de la philosophie du Test-Driven Development (TDD). Elle offre un contrôle total sur l’environnement de test tout en maintenant l’isolation nécessaire à des tests unitaires de qualité.</p> </div> <div class="paragraph"> <p>Les diagrammes et exemples présentés dans cet article montrent comment cette approche peut être mise en œuvre de manière progressive et méthodique, permettant de créer une suite de tests robuste et maintenable pour vos plugins Gradle.</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0079_gradle_tasks_tests_report_post.html Fri, 11 Jul 2025 00:00:00 +0000 blog/2025/0079_gradle_tasks_tests_report_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_centraliser_les_configurations_avec_allprojects_et_subprojects">1. Centraliser les Configurations avec <code>allprojects</code> et <code>subprojects</code></a></li> <li><a href="#_sourceplantuml">2. [source,plantuml]</a></li> <li><a href="#_enduml">3. @enduml</a></li> <li><a href="#_sourcekotlin">4. [source,kotlin]</a></li> <li><a href="#">5. }</a></li> <li><a href="#_sourcekotlin_2">6. [source,kotlin]</a></li> <li><a href="#_abstract_class_reportjbakefunctionalteststask_abstractjbakeexectask_init_description_opens_the_functional_test_report_in_firefox_reportrelativepath_buildreportstestsfunctionaltestindex_html">7. abstract class ReportJbakeFunctionalTestsTask : AbstractJbakeExecTask() { init { description = "Opens the functional test report in Firefox." reportRelativePath = "build/reports/tests/functionalTest/index.html" } }</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre>L'automatisation des tâches de build est cruciale pour tout projet logiciel, et Gradle, avec son DSL Kotlin, offre une flexibilité exceptionnelle. Au cours de notre conversation, nous avons exploré comment centraliser et réutiliser la logique de build, notamment pour les rapports de tests, en tirant parti de **allprojects**, **buildSrc**, et des tâches personnalisées en Kotlin.</pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_centraliser_les_configurations_avec_allprojects_et_subprojects">1. Centraliser les Configurations avec <code>allprojects</code> et <code>subprojects</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>Les blocs <code>allprojects</code> et <code>subprojects</code> dans votre <code>build.gradle.kts</code> racine sont fondamentaux pour appliquer des configurations communes à travers votre projet multi-modules.</p> </div> <div class="ulist"> <ul> <li> <p><code>allprojects { …​ }</code>: Applique la configuration au <strong>projet racine et à tous ses sous-projets</strong>. Idéal pour définir un <code>group</code>, une <code>version</code>, ou des <code>repositories</code> communs.</p> </li> <li> <p><code>subprojects { …​ }</code>: Applique la configuration <strong>uniquement aux sous-projets</strong>, excluant le projet racine. Parfait pour appliquer des plugins spécifiques aux modules (comme <code>java</code> ou <code>kotlin-jvm</code>) ou des dépendances communes à vos bibliothèques.</p> </li> </ul> </div> <div class="paragraph"> <p>Voici un exemple illustratif :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">// build.gradle.kts (projet racine) plugins { base // Appliqué au projet racine } allprojects { group = "com.example" version = "1.0.0" repositories { mavenCentral() } tasks.withType<org.gradle.api.tasks.testing.Test> { useJUnitPlatform() // Configuration commune des tests pour tous les projets } } subprojects { apply(plugin = "java") apply(plugin = "org.jetbrains.kotlin.jvm") dependencies { implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8") } }</code></pre> </div> </div> <div class="paragraph"> <p>\== <code>buildSrc</code>: Le Couteau Suisse de la Logique de Build</p> </div> <div class="paragraph"> <p>Lorsque la logique de vos tâches devient complexe ou doit être réutilisée, <strong>buildSrc</strong> est la solution privilégiée. C’est un module Gradle spécial qui est compilé avant les scripts de build principaux, rendant ses classes disponibles sur le classpath de l’ensemble de votre build.</p> </div> <div class="paragraph"> <p>\=== Pourquoi utiliser <code>buildSrc</code> pour les Tâches ?</p> </div> <div class="ulist"> <ul> <li> <p><strong>Réutilisabilité</strong>: Une tâche définie dans <code>buildSrc</code> peut être appliquée à n’importe quel projet du build.</p> </li> <li> <p><strong>Organisation</strong>: Centralise le code de build, le rendant plus propre et maintenable.</p> </li> <li> <p><strong>Type Safety et Autocomplétion</strong>: Le code Kotlin dans <code>buildSrc</code> est compilé, offrant la vérification des erreurs et l’autocomplétion de votre IDE, améliorant l’expérience de développement.</p> </li> </ul> </div> <div class="paragraph"> <p>\=== Diagramme de Flux <code>buildSrc</code> (Code PlantUML)</p> </div> <div class="paragraph"> <p>Pour générer ce diagramme, copiez le code ci-dessous et collez-le dans un outil supportant PlantUML.</p> </div> </div> </div> <div class="sect1"> <h2 id="_sourceplantuml">2. [source,plantuml]</h2> <div class="sectionbody"> <div class="paragraph"> <p>@startuml skinparam handwritten true skinparam monochrome true</p> </div> <div class="paragraph"> <p>rectangle "Gradle Build Process" { component "buildSrc" as BS { file "MyCustomTask.kt" as T file "MyConventionPlugin.kt" as P } component "Root Project" as RP component "Subproject A" as SA component "Subproject B" as SB }</p> </div> <div class="paragraph"> <p>T --\> P : "is defined in" P --\> RP : "is applied to" P --\> SA : "is applied to" P --\> SB : "is applied to"</p> </div> <div class="paragraph"> <p>RP --|\> SA : "contains" RP --|\> SB : "contains"</p> </div> <div class="paragraph"> <p>RP -up-\> BS : "depends on (for build logic)" SA -up-\> BS : "depends on (for build logic)" SB -up-\> BS : "depends on (for build logic)"</p> </div> <div class="paragraph"> <p>note right of T Classes de tâches personnalisées (ex: OpenTestReportTask) end note</p> </div> <div class="paragraph"> <p>note right of P Plugins de convention qui enregistrent les tâches end note</p> </div> </div> </div> <div class="sect1"> <h2 id="_enduml">3. @enduml</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre>\== Création de Tâches de Rapport Abstraites Pour gérer les rapports de tests, nous avons conçu une approche modulaire en utilisant une classe de tâche abstraite dans `buildSrc`. Selon vos besoins, cette classe peut hériter de `DefaultTask` ou de `Exec`. \=== Tâche Abstraite `OpenTestReportTask` (héritant de `DefaultTask`) Cette approche est recommandée si vous avez besoin d'une logique Kotlin personnalisée qui interagit avec le système de fichiers ou d'autres APIs Gradle, puis lance une commande externe. ## [source,kotlin] // buildSrc/src/main/kotlin/com/yourpackage/OpenTestReportTask.kt package com.yourpackage import org.gradle.api.DefaultTask import org.gradle.api.tasks.Input import org.gradle.api.tasks.TaskAction import java.io.File abstract class OpenTestReportTask : DefaultTask() { ``` init { group = "verification" description = "Opens a test report in Firefox." dependsOn("check") // Assure que les rapports sont générés } @get:Input abstract var reportPath: String @TaskAction fun openReport() { val separator = File.separator val reportFile = project.layout.projectDirectory.asFile.toPath() .resolve(reportPath.replace("/", separator)) .toAbsolutePath() .toFile() if (!reportFile.exists()) { logger.warn("Report file does not exist: $reportFile. Ensure 'check' ran.") return } project.exec { commandLine("firefox", "--new-tab", reportFile.absolutePath) } logger.lifecycle("Opened test report: ${reportFile.absolutePath}") } ``` ## } \=== Implémentations Concrètes Ces classes héritent de la tâche abstraite et définissent le chemin spécifique du rapport. ## [source,kotlin] // buildSrc/src/main/kotlin/com/yourpackage/ReportUnitTestsTask.kt package com.yourpackage abstract class ReportUnitTestsTask : OpenTestReportTask() { init { description = "Opens the unit test report in Firefox." reportPath = "build/reports/tests/test/index.html" } } // buildSrc/src/main/kotlin/com/yourpackage/ReportFunctionalTestsTask.kt package com.yourpackage ## abstract class ReportFunctionalTestsTask : OpenTestReportTask() { init { description = "Opens the functional test report in Firefox." reportPath = "build/reports/tests/functionalTest/index.html" } } \=== Enregistrement des Tâches Dans le `build.gradle.kts` de votre projet racine : ## [source,kotlin] // build.gradle.kts (au niveau de la racine du projet) ## tasks.register\<com.yourpackage.ReportUnitTestsTask\>("reportTests") {} tasks.register\<com.yourpackage.ReportFunctionalTestsTask\>("reportFunctionalTests") {} \=== Diagramme UML des Tâches de Rapport (Code PlantUML) Copiez le code ci-dessous et collez-le dans un outil supportant PlantUML. ## [source,plantuml] @startuml skinparam handwritten true skinparam monochrome true abstract class DefaultTask { } abstract class Exec { \+ commandLine(args: String...) \+ exec() } abstract class OpenTestReportTask extends DefaultTask { \+ group: String = "verification" \+ description: String \+ dependsOn("check") \+ abstract reportPath: String \+ openReport() : void } abstract class AbstractJbakeExecTask extends Exec { \+ group: String = "verification" \+ description: String \+ dependsOn("check") \+ abstract reportRelativePath: String \+ exec() : void } class ReportUnitTestsTask extends OpenTestReportTask { \+ reportPath: String = "build/reports/tests/test/index.html" } class ReportFunctionalTestsTask extends OpenTestReportTask { \+ reportPath: String = "build/reports/tests/functionalTest/index.html" } class ReportJbakeTestsTask extends AbstractJbakeExecTask { \+ reportRelativePath: String = "build/reports/tests/test/index.html" } class ReportJbakeFunctionalTestsTask extends AbstractJbakeExecTask { \+ reportRelativePath: String = "build/reports/tests/functionalTest/index.html" } OpenTestReportTask \<-- ReportUnitTestsTask OpenTestReportTask \<-- ReportFunctionalTestsTask AbstractJbakeExecTask \<-- ReportJbakeTestsTask AbstractJbakeExecTask \<-- ReportJbakeFunctionalTestsTask DefaultTask \<|-- OpenTestReportTask Exec \<|-- AbstractJbakeExecTask DefaultTask \<|-- Exec ## @enduml</pre> </div> </div> <div class="paragraph"> <p>\== Tâche Abstraite <code>AbstractJbakeExecTask</code> (héritant de <code>Exec</code>)</p> </div> <div class="paragraph"> <p>Si votre tâche se résume principalement à exécuter une commande externe avec des arguments variables, hériter directement de <strong>Exec</strong> est plus direct.</p> </div> </div> </div> <div class="sect1"> <h2 id="_sourcekotlin">4. [source,kotlin]</h2> <div class="sectionbody"> <div class="paragraph"> <p>package com.yourpackage</p> </div> <div class="paragraph"> <p>import org.gradle.api.tasks.Exec import org.gradle.api.tasks.Input import java.io.File</p> </div> <div class="paragraph"> <p>abstract class AbstractJbakeExecTask : Exec() {</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-none hljs">init { group = "verification" description = "Opens a Jbake project report in Firefox." dependsOn("check") } @get:Input abstract var reportRelativePath: String override fun exec() { val separator = File.separator val reportFile = project.layout.projectDirectory.asFile.toPath() .resolve(reportRelativePath.replace("/", separator)) .toAbsolutePath() .toFile() if (!reportFile.exists()) { logger.warn("Report file does not exist: $reportFile. Ensure 'check' ran.") return } commandLine("firefox", "--new-tab", reportFile.absolutePath) logger.lifecycle("Attempting to open report: ${reportFile.absolutePath}") super.exec() // Appelle la méthode exec() de la super-classe Exec }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="">5. }</h2> <div class="sectionbody"> <div class="paragraph"> <p>\=== Implémentations Concrètes pour <code>Exec</code></p> </div> </div> </div> <div class="sect1"> <h2 id="_sourcekotlin_2">6. [source,kotlin]</h2> <div class="sectionbody"> <div class="paragraph"> <p>package com.yourpackage</p> </div> <div class="paragraph"> <p>abstract class ReportJbakeTestsTask : AbstractJbakeExecTask() { init { description = "Opens the Jbake unit test report in Firefox." reportRelativePath = "build/reports/tests/test/index.html" } }</p> </div> <div class="paragraph"> <p>package com.yourpackage</p> </div> </div> </div> <div class="sect1"> <h2 id="_abstract_class_reportjbakefunctionalteststask_abstractjbakeexectask_init_description_opens_the_functional_test_report_in_firefox_reportrelativepath_buildreportstestsfunctionaltestindex_html">7. abstract class ReportJbakeFunctionalTestsTask : AbstractJbakeExecTask() { init { description = "Opens the functional test report in Firefox." reportRelativePath = "build/reports/tests/functionalTest/index.html" } }</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre>\== Visibilité des Tâches `buildSrc` Les tâches et classes que vous définissez dans **buildSrc** sont : * **Visibles et utilisables** par tous les projets de votre build principal (racine et sous-projets). C'est pourquoi vous pouvez utiliser `com.yourpackage.ReportUnitTestsTask` dans `allprojects { ... }`. * **Non exécutables** directement en tant que tâches de buildSrc (par exemple, `gradle :buildSrc:reportTests` ne fonctionnerait pas si la tâche n'est pas enregistrée spécifiquement dans `buildSrc/build.gradle.kts`). `buildSrc` est un module de compilation, pas un module d'application exécutable pour ces tâches du build principal. \=== Exécuter un rapport pour les tests de `buildSrc` lui-même Si `buildSrc` a ses propres tests et génère des rapports, vous pouvez enregistrer une tâche de rapport directement dans `buildSrc/build.gradle.kts` : ## [source,kotlin] // buildSrc/build.gradle.kts plugins { `kotlin-jvm` } repositories { mavenCentral() } tasks.withType\<Test\> { useJUnitPlatform() reports.html.outputLocation.set(layout.buildDirectory.dir("reports/tests")) } import com.yourpackage.ReportJbakeTestsTask // Importez votre classe de tâche ## tasks.register\<ReportJbakeTestsTask\>("reportBuildSrcTests") { // Le chemin est déjà défini dans la classe, il pointera vers les rapports de buildSrc } Vous pourrez ensuite exécuter : `./gradlew :buildSrc:test` suivi de `./gradlew :buildSrc:reportBuildSrcTests`.</pre> </div> </div> <div class="paragraph"> <p>En adoptant ces pratiques, vous construirez des systèmes de build Gradle en Kotlin DSL qui sont non seulement puissants, mais aussi incroyablement modulaires, maintenables et faciles à comprendre.</p> </div> <div class="listingblock"> <div class="content"> <pre></pre> </div> </div> </div> </div> https://pages-content.github.io//blog/2025/0078_jbake_gradle_plugin_syntaxe_post.html Wed, 9 Jul 2025 00:00:00 +0000 blog/2025/0078_jbake_gradle_plugin_syntaxe_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_objectif">1. Objectif</a></li> <li><a href="#_configuration_déclarative">2. Configuration déclarative</a></li> <li><a href="#_architecture_du_plugin">3. Architecture du plugin</a></li> <li><a href="#_définition_de_lextension_dsl">4. Définition de l’extension DSL</a></li> <li><a href="#_définition_de_la_tâche_personnalisée">5. Définition de la tâche personnalisée</a></li> <li><a href="#_interface_gitadapter">6. Interface GitAdapter</a></li> <li><a href="#_implémentation_concrète_avec_jgit">7. Implémentation concrète avec JGit</a></li> <li><a href="#_configuration_dsl_kotlin">8. Configuration DSL Kotlin</a></li> <li><a href="#_tests_unitaires_avec_mockito">9. Tests unitaires avec Mockito</a> <ul class="sectlevel2"> <li><a href="#_dépendances">9.1. Dépendances</a></li> <li><a href="#_test_du_comportement_git">9.2. Test du comportement Git</a></li> </ul> </li> <li><a href="#_conclusion">10. Conclusion</a></li> <li><a href="#_prochaines_étapes">11. Prochaines étapes</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>Ce billet présente la démarche complète de conception et de tests (TDD) d’un plugin Gradle écrit en Kotlin DSL. Ce plugin automatise la génération de sites statiques avec <strong>JBake</strong> et le <strong>déploiement Git</strong> via <strong>JGit</strong>, le tout à partir d’un fichier YAML de configuration.</p> </div> </div> </div> <div class="sect1"> <h2 id="_objectif">1. Objectif</h2> <div class="sectionbody"> <div class="paragraph"> <p>Créer un plugin Gradle :</p> </div> <div class="ulist"> <ul> <li> <p>configurable en Kotlin DSL ;</p> </li> <li> <p>capable de :</p> <div class="ulist"> <ul> <li> <p>générer un site statique à partir de JBake ;</p> </li> <li> <p>déployer sur un dépôt Git distant via JGit ;</p> </li> </ul> </div> </li> <li> <p>intégrable dans un workflow CI/CD ;</p> </li> <li> <p>testé selon une démarche TDD.</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_déclarative">2. Configuration déclarative</h2> <div class="sectionbody"> <div class="paragraph"> <p>Voici un exemple de configuration YAML à modéliser dans notre DSL :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-yaml hljs" data-lang="yaml">bake: srcPath: "./site/jbake" destDirPath: "bake" pushPage: from: "bake" to: "cvs" repo: name: "trainings" repository: "https://github.com/pages-content/trainings.git" credentials: username: "USERNAME" password: "SECRET_TOKEN" branch: "main" message: "cheroliv.com"</code></pre> </div> </div> <div class="paragraph"> <p>Cette configuration est représentée via une extension Gradle déclarable en Kotlin DSL.</p> </div> </div> </div> <div class="sect1"> <h2 id="_architecture_du_plugin">3. Architecture du plugin</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="./images/jbake-asciidoctor-class-diagram.png" alt="jbake asciidoctor class diagram" width="568" height="261"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_définition_de_lextension_dsl">4. Définition de l’extension DSL</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">open class WorkspaceEngineExtension { var outputDir: String = "build/site" var template: String = "freemarker" var repoUrl: String = "" var branch: String = "main" var message: String = "Generated by engine" }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_définition_de_la_tâche_personnalisée">5. Définition de la tâche personnalisée</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">abstract class GenerateSiteTask : DefaultTask() { lateinit var gitAdapter: GitAdapter @get:Input abstract val repoUrl: Property<String> @get:InputDirectory abstract val outputDir: DirectoryProperty @get:Input abstract val branch: Property<String> @get:Input abstract val message: Property<String> @TaskAction fun run() { val repo = gitAdapter.cloneRepository(repoUrl.get(), outputDir.get().asFile) gitAdapter.commitAndPush(repo, branch.get(), message.get()) } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_interface_gitadapter">6. Interface GitAdapter</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">interface GitAdapter { fun cloneRepository(uri: String, directory: File): Repository fun commitAndPush(repo: Repository, branch: String, message: String) }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_implémentation_concrète_avec_jgit">7. Implémentation concrète avec JGit</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class JGitAdapter : GitAdapter { override fun cloneRepository(uri: String, directory: File): Repository { return Git.cloneRepository() .setURI(uri) .setDirectory(directory) .call() .repository } override fun commitAndPush(repo: Repository, branch: String, message: String) { Git(repo).use { it.add().addFilepattern(".").call() it.commit().setMessage(message).call() it.push().call() } } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_configuration_dsl_kotlin">8. Configuration DSL Kotlin</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">workspaceEngine { outputDir = "build/out" template = "freemarker" repoUrl = "https://github.com/cheroliv/trainings.git" branch = "main" message = "deploy from plugin" }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_tests_unitaires_avec_mockito">9. Tests unitaires avec Mockito</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_dépendances">9.1. Dépendances</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">testImplementation("org.mockito:mockito-core:5.12.0") testImplementation("org.mockito.kotlin:mockito-kotlin:5.2.1") testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_test_du_comportement_git">9.2. Test du comportement Git</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-kotlin hljs" data-lang="kotlin">class GenerateSiteTaskMockitoTest { @TempDir lateinit var tempDir: File @Test fun `task should call clone and commitAndPush`() { val project = ProjectBuilder.builder().build() val task = project.tasks.create("generateSite", GenerateSiteTask::class.java) val mockGitAdapter = mock<GitAdapter>() val mockRepo = mock<Repository>() whenever(mockGitAdapter.cloneRepository(any(), any())).thenReturn(mockRepo) task.gitAdapter = mockGitAdapter task.repoUrl.set("https://github.com/cheroliv/test.git") task.outputDir.set(project.layout.projectDirectory.dir(tempDir.name)) task.branch.set("main") task.message.set("test commit") task.run() verify(mockGitAdapter).cloneRepository(eq("https://github.com/cheroliv/test.git"), any()) verify(mockGitAdapter).commitAndPush(eq(mockRepo), eq("main"), eq("test commit")) } }</code></pre> </div> </div> <div class="imageblock"> <div class="content"> <img src="./images/jbake-asciidoctor-sequence-diagram.png" alt="jbake asciidoctor sequence diagram" width="783" height="326"> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">10. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>La séparation des responsabilités via <code>GitAdapter</code> permet d’appliquer pleinement le TDD dans le développement de plugin Gradle :</p> </div> <div class="ulist"> <ul> <li> <p>les appels Git sont abstraits et testables ;</p> </li> <li> <p>la configuration DSL est propre et claire ;</p> </li> <li> <p>le plugin reste agnostique de l’implémentation réelle.</p> </li> </ul> </div> <div class="paragraph"> <p>Cette approche assure une haute testabilité et extensibilité (vers GitHub API, GitLab, etc.).</p> </div> </div> </div> <div class="sect1"> <h2 id="_prochaines_étapes">11. Prochaines étapes</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Intégrer la génération JBake comme un <code>BakeAdapter</code></p> </li> <li> <p>Ajouter des tests d’intégration avec <code>GradleRunner</code></p> </li> <li> <p>Supporter le chargement automatique de fichiers <code>site.yml</code> via SnakeYAML</p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2025/0077_asciidoc_syntaxe_post.html Fri, 20 Jun 2025 00:00:00 +0000 blog/2025/0077_asciidoc_syntaxe_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_quest_ce_quasciidoc">2. Qu’est-ce qu’AsciiDoc ?</a> <ul class="sectlevel2"> <li><a href="#_pourquoi_choisir_asciidoc">2.1. Pourquoi choisir AsciiDoc ?</a></li> </ul> </li> <li><a href="#_diagramme_de_cas_dutilisation_use_case">3. Diagramme de cas d’utilisation (Use Case)</a></li> <li><a href="#_diagramme_mind_map">4. Diagramme Mind Map</a></li> <li><a href="#_diagramme_de_flow_flux">5. Diagramme de Flow (flux)</a></li> <li><a href="#_structure_de_base_dun_fichier_asciidoc">6. Structure de base d’un fichier AsciiDoc</a></li> <li><a href="#_syntaxe_fondamentale">7. Syntaxe fondamentale</a> <ul class="sectlevel2"> <li><a href="#_titres_et_sections">7.1. Titres et sections</a></li> <li><a href="#_texte_en_gras_italique_et_monospace">7.2. Texte en gras, italique et monospace</a></li> <li><a href="#_listes_à_puces_et_numérotées">7.3. Listes à puces et numérotées</a></li> <li><a href="#_liens_et_images">7.4. Liens et images</a></li> <li><a href="#_blocs_de_code">7.5. Blocs de code</a></li> <li><a href="#_tableaux">7.6. Tableaux</a></li> <li><a href="#_notes_et_admonitions">7.7. Notes et admonitions</a></li> </ul> </li> <li><a href="#_utilisation_dattributs_et_variables">8. Utilisation d’attributs et variables</a></li> <li><a href="#_cas_dutilisation_courants">9. Cas d’utilisation courants</a></li> <li><a href="#_bonnes_pratiques">10. Bonnes pratiques</a></li> <li><a href="#_conclusion">11. Conclusion</a></li> <li><a href="#_pour_aller_plus_loin">12. Pour aller plus loin</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title"><em>Temps de lecture :</em></div> <p>8 à 12 minutes.</p> </div> <div class="paragraph"> <div class="title"><em>Public cible :</em></div> <p>Développeurs, rédacteurs techniques, et toute personne souhaitant rédiger de la documentation technique ou des articles riches.</p> </div> </div> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>AsciiDoc est un langage de balisage léger, conçu pour rédiger des documents techniques structurés, des articles, des livres, ou encore des présentations. Il se distingue par sa lisibilité, sa richesse syntaxique et sa capacité à générer divers formats (HTML, PDF, DocBook, etc.). Dans cet article, nous allons explorer la syntaxe essentielle d’AsciiDoc et proposer des astuces pour une prise en main rapide.</p> </div> </div> </div> <div class="sect1"> <h2 id="_quest_ce_quasciidoc">2. Qu’est-ce qu’AsciiDoc ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>AsciiDoc est un langage de description de documents, similaire à Markdown mais plus puissant. Il permet de structurer efficacement textes, titres, listes, tableaux, blocs de code, et bien plus encore. Sa polyvalence en fait un choix populaire pour la documentation de projets open source, la rédaction de livres et la publication web.</p> </div> <div class="sect2"> <h3 id="_pourquoi_choisir_asciidoc">2.1. Pourquoi choisir AsciiDoc ?</h3> <div class="olist arabic"> <ol class="arabic"> <li> <p>Syntaxe lisible et intuitive.</p> </li> <li> <p>Support natif de structures complexes (tableaux, notes, admonitions, etc.).</p> </li> <li> <p>Génération multi-formats (HTML, PDF, ePub, DocBook…).</p> </li> <li> <p>Intégration facile avec des générateurs de sites statiques comme JBake ou Antora.</p> </li> <li> <p>Personnalisation avancée avec les attributs et extensions.</p> </li> </ol> </div> </div> </div> </div> <div class="sect1"> <h2 id="_diagramme_de_cas_dutilisation_use_case">3. Diagramme de cas d’utilisation (Use Case)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Un diagramme de cas d’utilisation permet de présenter les interactions principales entre les utilisateurs et le système. Voici un exemple simple pour un système de documentation :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-381f40e6e0660c0c53433ff054330b76.png" alt="Diagram" width="423" height="258"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_diagramme_mind_map">4. Diagramme Mind Map</h2> <div class="sectionbody"> <div class="paragraph"> <p>Le mind map (carte mentale) est idéal pour explorer les concepts liés à AsciiDoc et leurs relations :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-e1560e9cc014158b6fbeed1e5ad8e138.png" alt="Diagram" width="394" height="527"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_diagramme_de_flow_flux">5. Diagramme de Flow (flux)</h2> <div class="sectionbody"> <div class="paragraph"> <p>Un diagramme de flow permet de décrire le processus de génération d’un document AsciiDoc :</p> </div> <div class="imageblock"> <div class="content"> <img src="diag-plantuml-md5-51318d77b9e18062d3a9b751587670ae.png" alt="Diagram" width="299" height="361"> </div> </div> </div> </div> <div class="sect1"> <h2 id="_structure_de_base_dun_fichier_asciidoc">6. Structure de base d’un fichier AsciiDoc</h2> <div class="sectionbody"> <div class="paragraph"> <p>Un fichier AsciiDoc commence généralement par un titre, des attributs optionnels, puis le contenu structuré. Voici un exemple minimal :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">= Titre Principal Auteur 2024-09-03 :toc: :icons: font Votre contenu commence ici...</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_syntaxe_fondamentale">7. Syntaxe fondamentale</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_titres_et_sections">7.1. Titres et sections</h3> <div class="paragraph"> <p>AsciiDoc supporte plusieurs niveaux de titres :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">= Titre de niveau 1 == Titre de niveau 2 === Titre de niveau 3 ==== Titre de niveau 4</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_texte_en_gras_italique_et_monospace">7.2. Texte en gras, italique et monospace</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">*gras* _italique_ `monospace`</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_listes_à_puces_et_numérotées">7.3. Listes à puces et numérotées</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">* Élément 1 * Élément 2 . Premier . Deuxième . Troisième</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_liens_et_images">7.4. Liens et images</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">Lien standard : https://asciidoc.org[AsciiDoc] Image : image::images/logo.png[AsciiDoc Logo]</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_blocs_de_code">7.5. Blocs de code</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">[source,python]</code></pre> </div> </div> <div class="paragraph"> <p>def hello(): print("Bonjour AsciiDoc !")</p> </div> <div class="listingblock"> <div class="content"> <pre></pre> </div> </div> </div> <div class="sect2"> <h3 id="_tableaux">7.6. Tableaux</h3> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">|=== | Colonne 1 | Colonne 2 | Valeur A | Valeur B | Valeur C | Valeur D |===</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_notes_et_admonitions">7.7. Notes et admonitions</h3> <div class="paragraph"> <p>AsciiDoc propose des blocs d’information visuelle :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">NOTE: Ceci est une note importante. TIP: Conseil utile pour l’utilisateur. WARNING: Attention à ce point.</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_utilisation_dattributs_et_variables">8. Utilisation d’attributs et variables</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les attributs personnalisés permettent de réutiliser des valeurs ou de configurer des comportements :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-asciidoc hljs" data-lang="asciidoc">:project-name: AsciiDoc Explorer Le projet s’appelle {project-name}.</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_cas_dutilisation_courants">9. Cas d’utilisation courants</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Documentation projet open source (README, guides techniques)</p> </li> <li> <p>Rédaction de livres et ebooks</p> </li> <li> <p>Génération automatique de sites web statiques (JBake, Antora)</p> </li> <li> <p>Présentations techniques</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_bonnes_pratiques">10. Bonnes pratiques</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Utilisez des titres cohérents et un sommaire automatique (:toc:).</p> </li> <li> <p>Privilégiez les admonitions pour attirer l’attention sur des points clés.</p> </li> <li> <p>Structurez vos fichiers pour faciliter la maintenance.</p> </li> <li> <p>Profitez des blocs de code annotés pour illustrer des exemples.</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">11. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>AsciiDoc est un outil puissant et accessible pour rédiger toute documentation technique ou article structuré. Sa syntaxe riche, combinée à la génération multi-formats, en fait un allié de choix pour les développeurs et rédacteurs exigeants. Essayez AsciiDoc dans votre prochain projet et découvrez la différence !</p> </div> </div> </div> <div class="sect1"> <h2 id="_pour_aller_plus_loin">12. Pour aller plus loin</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Documentation officielle : <a href="https://asciidoc.org" class="bare">https://asciidoc.org</a></p> </li> <li> <p>Asciidoctor : <a href="https://asciidoctor.org" class="bare">https://asciidoctor.org</a></p> </li> <li> <p>JBake et AsciiDoc : <a href="https://jbake.org/docs/2.6.4/#asciidoc_support" class="bare">https://jbake.org/docs/2.6.4/#asciidoc_support</a></p> </li> </ul> </div> <div class="paragraph"> <p>Partagez vos expériences et astuces en commentaire !</p> </div> </div> </div> https://pages-content.github.io//blog/2025/0076_port_forwarding_post.html Wed, 28 May 2025 00:00:00 +0000 blog/2025/0076_port_forwarding_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_le_problème_nat_et_adresses_privées">1. Le problème : NAT et adresses privées</a></li> <li><a href="#_étape_1_identifier_votre_adresse_ip_publique">2. Étape 1 : Identifier votre adresse IP publique</a></li> <li><a href="#_étape_2_connaître_ladresse_ip_locale_de_votre_machine_ubuntu">3. Étape 2 : Connaître l’adresse IP locale de votre machine Ubuntu</a></li> <li><a href="#_étape_3_configurer_le_port_forwarding_sur_votre_box">4. Étape 3 : Configurer le port forwarding sur votre box</a> <ul class="sectlevel2"> <li><a href="#_accès_à_linterface_dadministration">4.1. Accès à l’interface d’administration</a></li> <li><a href="#_configuration_de_la_redirection">4.2. Configuration de la redirection</a></li> </ul> </li> <li><a href="#_étape_4_configuration_du_service_sur_ubuntu">5. Étape 4 : Configuration du service sur Ubuntu</a></li> <li><a href="#_étape_5_configuration_du_pare_feu_ubuntu">6. Étape 5 : Configuration du pare-feu Ubuntu</a></li> <li><a href="#_étape_6_test_et_validation">7. Étape 6 : Test et validation</a> <ul class="sectlevel2"> <li><a href="#_test_depuis_le_réseau_local">7.1. Test depuis le réseau local</a></li> <li><a href="#_test_depuis_lextérieur">7.2. Test depuis l’extérieur</a></li> </ul> </li> <li><a href="#_bonnes_pratiques_et_sécurité">8. Bonnes pratiques et sécurité</a> <ul class="sectlevel2"> <li><a href="#_sécurisation_de_base">8.1. Sécurisation de base</a></li> <li><a href="#_monitoring_des_connexions">8.2. Monitoring des connexions</a></li> <li><a href="#_utilisation_dun_reverse_proxy">8.3. Utilisation d’un reverse proxy</a></li> </ul> </li> <li><a href="#_alternatives_au_port_forwarding">9. Alternatives au port forwarding</a> <ul class="sectlevel2"> <li><a href="#_solutions_cloud">9.1. Solutions cloud</a></li> <li><a href="#_vps_et_reverse_proxy">9.2. VPS et reverse proxy</a></li> </ul> </li> <li><a href="#_troubleshooting">10. Troubleshooting</a> <ul class="sectlevel2"> <li><a href="#_problèmes_courants">10.1. Problèmes courants</a></li> <li><a href="#_debug_réseau">10.2. Debug réseau</a></li> </ul> </li> <li><a href="#_conclusion">11. Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="ulist"> <div class="title">Public cible : Intermédiaire</div> <ul> <li> <p><strong>Prérequis assumés</strong> : connaissance de base d’Ubuntu, du terminal, concepts réseau de base</p> </li> <li> <p><strong>Concepts techniques</strong> : NAT, port forwarding, pare-feu, reverse proxy</p> </li> <li> <p><strong>Commandes système</strong> : utilisation du terminal, configuration réseau</p> </li> <li> <p><strong>Sections avancées</strong> : monitoring, sécurité, alternatives cloud</p> </li> </ul> </div> <div class="paragraph"> <div class="title">Problématique :</div> <p>Vous développez une application web sur votre machine Ubuntu et souhaitez la rendre accessible depuis l’extérieur de votre réseau domestique ? Vous êtes au bon endroit ! Dans cet article, nous allons voir comment exposer un service local (par exemple sur le port 8080) vers Internet en configurant le port forwarding sur votre box internet.</p> </div> </div> </div> <div class="sect1"> <h2 id="_le_problème_nat_et_adresses_privées">1. Le problème : NAT et adresses privées</h2> <div class="sectionbody"> <div class="paragraph"> <p>Par défaut, votre box internet utilise le NAT (Network Address Translation) pour partager une seule adresse IP publique entre tous les appareils de votre réseau domestique. Vos machines locales utilisent des adresses IP privées (192.168.x.x, 10.x.x.x, etc.) qui ne sont pas routables sur Internet.</p> </div> <div class="paragraph"> <p>Lorsque vous lancez un service sur votre machine Ubuntu (par exemple un serveur web sur le port 8080), celui-ci n’est accessible que depuis votre réseau local. Pour le rendre accessible depuis Internet, nous devons configurer une redirection de port.</p> </div> </div> </div> <div class="sect1"> <h2 id="_étape_1_identifier_votre_adresse_ip_publique">2. Étape 1 : Identifier votre adresse IP publique</h2> <div class="sectionbody"> <div class="paragraph"> <p>Avant tout, récupérons l’adresse IP publique de votre connexion Internet :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Plusieurs méthodes au choix curl ifconfig.me curl ipecho.net/plain wget -qO- http://ipecho.net/plain # Ou encore curl -s checkip.amazonaws.com</code></pre> </div> </div> <div class="paragraph"> <p>Cette adresse IP est celle que les internautes utiliseront pour accéder à votre service.</p> </div> </div> </div> <div class="sect1"> <h2 id="_étape_2_connaître_ladresse_ip_locale_de_votre_machine_ubuntu">3. Étape 2 : Connaître l’adresse IP locale de votre machine Ubuntu</h2> <div class="sectionbody"> <div class="paragraph"> <p>Votre machine Ubuntu a une adresse IP privée sur votre réseau local. Pour la connaître :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Afficher toutes les interfaces réseau ip addr show # Ou plus spécifiquement pour l'interface principale ip route get 1.1.1.1 | awk '{print $7; exit}' # Alternative avec hostname hostname -I | awk '{print $1}'</code></pre> </div> </div> <div class="paragraph"> <p>Notez cette adresse (par exemple <code>192.168.1.100</code>), nous en aurons besoin pour la configuration.</p> </div> </div> </div> <div class="sect1"> <h2 id="_étape_3_configurer_le_port_forwarding_sur_votre_box">4. Étape 3 : Configurer le port forwarding sur votre box</h2> <div class="sectionbody"> <div class="paragraph"> <p>La configuration varie selon le modèle de votre box, mais le principe reste le même :</p> </div> <div class="sect2"> <h3 id="_accès_à_linterface_dadministration">4.1. Accès à l’interface d’administration</h3> <div class="paragraph"> <p>Ouvrez votre navigateur et rendez-vous sur l’interface web de votre box :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Freebox</strong> : <code>192.168.1.1</code> ou <code>mafreebox.freebox.fr</code></p> </li> <li> <p><strong>Livebox Orange</strong> : <code>192.168.1.1</code></p> </li> <li> <p><strong>SFR Box</strong> : <code>192.168.1.1</code></p> </li> <li> <p><strong>Bbox Bouygues</strong> : <code>192.168.1.254</code></p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_configuration_de_la_redirection">4.2. Configuration de la redirection</h3> <div class="paragraph"> <p>Cherchez la section dédiée au port forwarding (les noms varient) :</p> </div> <div class="ulist"> <ul> <li> <p>"Redirection de ports"</p> </li> <li> <p>"NAT/PAT"</p> </li> <li> <p>"Port Forwarding"</p> </li> <li> <p>"Serveurs de jeux"</p> </li> </ul> </div> <div class="paragraph"> <p>Créez une nouvelle règle avec ces paramètres :</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 25%;"> <col style="width: 75%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Champ</th> <th class="tableblock halign-left valign-top">Valeur</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Nom/Description</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">"Service Web Ubuntu" (ou autre nom explicite)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Port externe (ou port public)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8080</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Adresse IP interne</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">L’IP de votre machine Ubuntu (ex: 192.168.1.100)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Port interne (ou port privé)</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">8080</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Protocole</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">TCP</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">État</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Activé</p></td> </tr> </tbody> </table> </div> </div> </div> <div class="sect1"> <h2 id="_étape_4_configuration_du_service_sur_ubuntu">5. Étape 4 : Configuration du service sur Ubuntu</h2> <div class="sectionbody"> <div class="paragraph"> <p>Assurez-vous que votre service écoute sur toutes les interfaces, pas seulement sur localhost :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># ✅ Correct : écoute sur toutes les interfaces python3 -m http.server 8080 --bind 0.0.0.0 # ❌ Incorrect : écoute seulement en local python3 -m http.server 8080 --bind 127.0.0.1</code></pre> </div> </div> <div class="paragraph"> <p>Pour vérifier que votre service écoute correctement :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Vérifier les ports en écoute sudo netstat -tlnp | grep :8080 # ou avec ss (plus moderne) sudo ss -tlnp | grep :8080</code></pre> </div> </div> <div class="paragraph"> <p>Vous devriez voir quelque chose comme <code>0.0.0.0:8080</code> et non <code>127.0.0.1:8080</code>.</p> </div> </div> </div> <div class="sect1"> <h2 id="_étape_5_configuration_du_pare_feu_ubuntu">6. Étape 5 : Configuration du pare-feu Ubuntu</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ubuntu utilise UFW (Uncomplicated Firewall) par défaut. Vérifiez son statut et autorisez le port si nécessaire :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Vérifier le statut du pare-feu sudo ufw status # Si le pare-feu est actif, autoriser le port 8080 sudo ufw allow 8080/tcp # Ou plus spécifiquement pour un service web sudo ufw allow 'Apache' # si vous utilisez Apache sudo ufw allow 'Nginx Full' # si vous utilisez Nginx</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_étape_6_test_et_validation">7. Étape 6 : Test et validation</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_test_depuis_le_réseau_local">7.1. Test depuis le réseau local</h3> <div class="paragraph"> <p>D’abord, testez l’accès depuis une autre machine de votre réseau local :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Remplacez par l'IP locale de votre machine Ubuntu curl http://192.168.1.100:8080</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_test_depuis_lextérieur">7.2. Test depuis l’extérieur</h3> <div class="paragraph"> <p>Maintenant, testez depuis Internet en utilisant votre IP publique :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Remplacez par votre IP publique curl http://VOTRE_IP_PUBLIQUE:8080</code></pre> </div> </div> <div class="paragraph"> <p>Vous pouvez également utiliser des outils en ligne comme :</p> </div> <div class="ulist"> <ul> <li> <p><a href="https://www.yougetsignal.com/tools/open-ports/" class="bare">https://www.yougetsignal.com/tools/open-ports/</a></p> </li> <li> <p><a href="https://canyouseeme.org/" class="bare">https://canyouseeme.org/</a></p> </li> </ul> </div> </div> </div> </div> <div class="sect1"> <h2 id="_bonnes_pratiques_et_sécurité">8. Bonnes pratiques et sécurité</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_sécurisation_de_base">8.1. Sécurisation de base</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Configurer fail2ban pour protéger contre les attaques par force brute sudo apt update && sudo apt install fail2ban # Limiter l'accès avec UFW (exemple : autoriser seulement certaines IP) sudo ufw allow from 203.0.113.0/24 to any port 8080</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_monitoring_des_connexions">8.2. Monitoring des connexions</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Surveiller les connexions en temps réel sudo netstat -an | grep :8080 # Logs des connexions (selon votre application) sudo tail -f /var/log/nginx/access.log # pour Nginx sudo journalctl -f -u your-service # pour un service systemd</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_utilisation_dun_reverse_proxy">8.3. Utilisation d’un reverse proxy</h3> <div class="paragraph"> <p>Pour une meilleure sécurité et flexibilité, considérez l’utilisation d’un reverse proxy comme Nginx :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-nginx" data-lang="nginx">server { listen 80; server_name votre-domaine.com; location / { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_alternatives_au_port_forwarding">9. Alternatives au port forwarding</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_solutions_cloud">9.1. Solutions cloud</h3> <div class="ulist"> <ul> <li> <p><strong>ngrok</strong> : tunnel sécurisé temporaire</p> </li> <li> <p><strong>Cloudflare Tunnel</strong> : solution gratuite et sécurisée</p> </li> <li> <p><strong>serveo.net</strong> : tunnel SSH simple</p> </li> </ul> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Exemple avec ngrok ngrok http 8080 # Exemple avec serveo ssh -R 80:localhost:8080 serveo.net</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_vps_et_reverse_proxy">9.2. VPS et reverse proxy</h3> <div class="paragraph"> <p>Pour un usage professionnel, considérez l’utilisation d’un VPS avec un reverse proxy pointant vers votre infrastructure locale via VPN.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_troubleshooting">10. Troubleshooting</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_problèmes_courants">10.1. Problèmes courants</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 40%;"> <col style="width: 60%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Problème</th> <th class="tableblock halign-left valign-top">Solution</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Service inaccessible depuis l’extérieur</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Vérifiez la configuration du port forwarding et que le service écoute sur 0.0.0.0</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">"Connection refused"</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Le service n’est pas démarré ou écoute sur 127.0.0.1 uniquement</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">"Connection timeout"</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Problème de pare-feu (box ou Ubuntu) ou port forwarding mal configuré</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">IP publique change régulièrement</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Configurez un DNS dynamique (DynDNS, No-IP, etc.)</p></td> </tr> </tbody> </table> </div> <div class="sect2"> <h3 id="_debug_réseau">10.2. Debug réseau</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash"># Tester la connectivité locale telnet localhost 8080 # Tester depuis une autre machine du réseau telnet 192.168.1.100 8080 # Vérifier les routes réseau ip route show # Analyser le trafic réseau sudo tcpdump -i any port 8080</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">11. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Exposer un service local sur Internet nécessite une configuration soigneuse du port forwarding, de la sécurité et du monitoring. Bien que cette approche soit parfaite pour du développement ou des projets personnels, pensez aux alternatives plus robustes (VPS, CDN, services cloud) pour un usage en production.</p> </div> <div class="paragraph"> <p>L’important est de toujours garder la sécurité à l’esprit : utilisez des mots de passe forts, mettez à jour régulièrement votre système, et surveillez les accès à vos services exposés.</p> </div> <div class="paragraph"> <p>N’hésitez pas à partager vos expériences et questions dans les commentaires !</p> </div> </div> </div> https://pages-content.github.io//blog/2024/0075_kotlin_arrow-traverse_right_and_left_post.html Tue, 24 Sep 2024 00:00:00 +0000 blog/2024/0075_kotlin_arrow-traverse_right_and_left_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_quest_ce_que_la_monade_either">2. Qu’est-ce que la monade Either ?</a> <ul class="sectlevel2"> <li><a href="#_pourquoi_utiliser_either">2.1. Pourquoi utiliser Either ?</a></li> </ul> </li> <li><a href="#_contexte">3. Contexte</a></li> <li><a href="#_les_différentes_approches">4. Les différentes approches</a> <ul class="sectlevel2"> <li><a href="#_lapproche_classique_avec_when">4.1. L’approche classique avec <code>when</code></a></li> <li><a href="#_utilisation_de_fold_pour_une_approche_plus_concise">4.2. Utilisation de <code>fold</code> pour une approche plus concise</a></li> <li><a href="#_transformation_avec_map_et_mapleft">4.3. Transformation avec <code>map</code> et <code>mapLeft</code></a></li> <li><a href="#_gestion_des_erreurs_avec_getorelse">4.4. Gestion des erreurs avec <code>getOrElse</code></a></li> <li><a href="#_actions_latérales_avec_onleft_et_onright">4.5. Actions latérales avec <code>onLeft</code> et <code>onRight</code></a></li> <li><a href="#_chaînage_dopérations_avec_flatmap">4.6. Chaînage d’opérations avec <code>flatMap</code></a></li> <li><a href="#_transformation_bidirectionnelle_avec_bimap">4.7. Transformation bidirectionnelle avec <code>bimap</code></a></li> <li><a href="#_inversion_des_côtés_avec_swap">4.8. Inversion des côtés avec <code>swap</code></a></li> <li><a href="#_utilisation_de_tap_et_tapleft">4.9. Utilisation de <code>tap</code> et <code>tapLeft</code> :</a></li> <li><a href="#_utilisation_de_recover">4.10. Utilisation de <code>recover</code> :</a></li> </ul> </li> <li><a href="#_cas_dutilisation_pratiques">5. Cas d’utilisation pratiques</a></li> <li><a href="#_conclusion">6. Conclusion</a></li> <li><a href="#_pour_aller_plus_loin">7. Pour aller plus loin</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title"><em>Temps de lecture :</em></div> <p>12 à 15 minutes.</p> </div> <div class="paragraph"> <div class="title"><em>Public cible :</em></div> <p>Développeurs Kotlin de niveau intermédiaire à avancé.</p> </div> </div> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans le monde de la programmation fonctionnelle en Kotlin, la bibliothèque Arrow offre des outils puissants pour gérer les erreurs et les cas alternatifs. Parmi ces outils, la monade <code>Either</code> se distingue par sa capacité à représenter deux états possibles : succès (Right) ou échec (Left). Mais comment naviguer efficacement entre ces deux états ? C’est ce que nous allons explorer dans cet article.</p> </div> </div> </div> <div class="sect1"> <h2 id="_quest_ce_que_la_monade_either">2. Qu’est-ce que la monade Either ?</h2> <div class="sectionbody"> <div class="paragraph"> <p>La monade <code>Either</code> est une structure de données qui représente deux possibilités mutuellement exclusives. En Kotlin avec Arrow, elle est souvent utilisée pour gérer les cas de succès et d’échec d’une opération, offrant une alternative élégante aux exceptions traditionnelles.</p> </div> <div class="sect2"> <h3 id="_pourquoi_utiliser_either">2.1. Pourquoi utiliser Either ?</h3> <div class="olist arabic"> <ol class="arabic"> <li> <p>Gestion explicite des erreurs : Force le développeur à considérer les cas d’échec.</p> </li> <li> <p>Composition fonctionnelle : Facilite le chaînage d’opérations qui peuvent échouer.</p> </li> <li> <p>Type-safety : Les erreurs sont typées, ce qui aide à les gérer de manière plus précise.</p> </li> <li> <p>Pas d’exceptions : Évite les effets de bord et les interruptions inattendues du flux d’exécution.</p> </li> </ol> </div> </div> </div> </div> <div class="sect1"> <h2 id="_contexte">3. Contexte</h2> <div class="sectionbody"> <div class="paragraph"> <p>Imaginons que vous développez une API REST avec <a href="https://spring.io/projects/spring-boot/">Spring Boot</a> et <a href="https://kotlinlang.org/">Kotlin</a>, en utilisant la bibliothèque <a href="https://arrow-kt.io/">Arrow</a>. Vous avez une fonction <code>findOneUserByEmail</code> qui renvoie un <code>Either<Throwable, User></code>. Comment pouvez-vous traiter ce résultat de manière élégante et fonctionnelle ?</p> </div> <div class="paragraph"> <p>Nous avons une classe User :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">@file:Suppress( "RemoveRedundantQualifierName", "MemberVisibilityCanBePrivate", "SqlNoDataSourceInspection" ) package webapp.users import arrow.core.Either import arrow.core.left import arrow.core.right import com.fasterxml.jackson.annotation.JsonIgnore import com.fasterxml.jackson.databind.ObjectMapper import jakarta.validation.constraints.NotNull import jakarta.validation.constraints.Pattern import jakarta.validation.constraints.Size import org.springframework.beans.factory.getBean import org.springframework.context.ApplicationContext import org.springframework.data.r2dbc.core.R2dbcEntityTemplate import org.springframework.r2dbc.core.DatabaseClient import org.springframework.r2dbc.core.awaitOne import org.springframework.r2dbc.core.awaitRowsUpdated import webapp.core.property.ANONYMOUS_USER import webapp.core.property.EMPTY_STRING import webapp.core.utils.AppUtils.cleanField import webapp.users.EntityModel.Companion.ID_MEMBER import webapp.users.User.UserDao.Attributes.EMAIL_ATTR import webapp.users.User.UserDao.Attributes.ID_ATTR import webapp.users.User.UserDao.Attributes.LANG_KEY_ATTR import webapp.users.User.UserDao.Attributes.LOGIN_ATTR import webapp.users.User.UserDao.Attributes.PASSWORD_ATTR import webapp.users.User.UserDao.Attributes.VERSION_ATTR import webapp.users.User.UserDao.Constraints.LOGIN_REGEX import webapp.users.User.UserDao.Fields.EMAIL_FIELD import webapp.users.User.UserDao.Fields.ID_FIELD import webapp.users.User.UserDao.Fields.LANG_KEY_FIELD import webapp.users.User.UserDao.Fields.LOGIN_FIELD import webapp.users.User.UserDao.Fields.PASSWORD_FIELD import webapp.users.User.UserDao.Fields.VERSION_FIELD import webapp.users.User.UserDao.Relations.INSERT import webapp.users.security.Role import webapp.users.security.Role.RoleDao import webapp.users.security.UserRole.UserRoleDao import java.util.* import jakarta.validation.constraints.Email as EmailConstraint data class User( override val id: UUID? = null, @field:NotNull @field:Pattern(regexp = LOGIN_REGEX) @field:Size(min = 1, max = 50) val login: String, @JsonIgnore @field:NotNull @field:Size(min = 60, max = 60) val password: String = EMPTY_STRING, @field:EmailConstraint @field:Size(min = 5, max = 254) val email: String = EMPTY_STRING, @JsonIgnore val roles: MutableSet<Role> = mutableSetOf(Role(ANONYMOUS_USER)), @field:Size(min = 2, max = 10) val langKey: String = EMPTY_STRING, @JsonIgnore val version: Long = -1, ) : EntityModel<UUID>() { companion object { @JvmStatic fun main(args: Array<String>) = println(UserDao.Relations.sqlScript) } object UserDao { object Constraints { // Regex for acceptable logins const val LOGIN_REGEX = "^(?>[a-zA-Z0-9!$&*+=?^_`{|}~.-]+@[a-zA-Z0-9-]+(?:\\.[a-zA-Z0-9-]+)*)|(?>[_.@A-Za-z0-9-]+)$" const val PASSWORD_MIN: Int = 4 const val PASSWORD_MAX: Int = 16 const val IMAGE_URL_DEFAULT = "https://placehold.it/50x50" const val PHONE_REGEX = "^(\\+|00)?[1-9]\\d{0,49}\$" } object Members { const val PASSWORD_MEMBER = "password" const val ROLES_MEMBER = "roles" } object Fields { const val ID_FIELD = "`id`" const val LOGIN_FIELD = "`login`" const val PASSWORD_FIELD = "`password`" const val EMAIL_FIELD = "`email`" const val LANG_KEY_FIELD = "`lang_key`" const val VERSION_FIELD = "`version`" } object Attributes { val ID_ATTR = ID_FIELD.cleanField() val LOGIN_ATTR = LOGIN_FIELD.cleanField() val PASSWORD_ATTR = PASSWORD_FIELD.cleanField() val EMAIL_ATTR = EMAIL_FIELD.cleanField() const val LANG_KEY_ATTR = "langKey" val VERSION_ATTR = VERSION_FIELD.cleanField() } object Relations { const val TABLE_NAME = "`user`" const val SQL_SCRIPT = """ CREATE TABLE IF NOT EXISTS $TABLE_NAME ( $ID_FIELD UUID default random_uuid() PRIMARY KEY, $LOGIN_FIELD VARCHAR, $PASSWORD_FIELD VARCHAR, $EMAIL_FIELD VARCHAR, $LANG_KEY_FIELD VARCHAR, $VERSION_FIELD bigint ); CREATE UNIQUE INDEX IF NOT EXISTS `uniq_idx_user_login` ON $TABLE_NAME ($LOGIN_FIELD); CREATE UNIQUE INDEX IF NOT EXISTS `uniq_idx_user_email` ON $TABLE_NAME ($EMAIL_FIELD); """ @Suppress("SqlDialectInspection") const val INSERT = """ insert into $TABLE_NAME ( $LOGIN_FIELD, $EMAIL_FIELD, $PASSWORD_FIELD, $LANG_KEY_FIELD, $VERSION_FIELD ) values ( :login, :email, :password, :langKey, :version)""" @JvmStatic val sqlScript: String get() = setOf( UserDao.Relations.SQL_SCRIPT, RoleDao.Relations.SQL_SCRIPT, UserRoleDao.Relations.SQL_SCRIPT ).joinToString("") .trimMargin() } object Dao { val Pair<User, ApplicationContext>.toJson: String get() = second.getBean<ObjectMapper>().writeValueAsString(first) suspend fun Pair<User, ApplicationContext>.save(): Either<Throwable, Long> = try { second.getBean<R2dbcEntityTemplate>() .databaseClient .sql(INSERT) .bind(LOGIN_ATTR, first.login) .bind(EMAIL_ATTR, first.email) .bind(PASSWORD_ATTR, first.password) .bind(LANG_KEY_ATTR, first.langKey) .bind(VERSION_ATTR, first.version) .fetch() .awaitRowsUpdated() .right() } catch (e: Throwable) { e.left() } suspend fun ApplicationContext.findOneUserByEmail( email: String ): Either<Throwable, User> = try { getBean<DatabaseClient>() .sql("SELECT * FROM `user` WHERE LOWER(email) = LOWER(:email)") .bind("email", email) .fetch() .awaitOne() .let { row -> User( id = row[ID_ATTR] as UUID?, login = row[LOGIN_ATTR] as String, password = row[PASSWORD_ATTR] as String, email = row[EMAIL_ATTR] as String, langKey = row[LANG_KEY_ATTR] as String, version = row[VERSION_ATTR] as Long ) }.right() } catch (e: Throwable) { e.left() } } } /** Account REST API URIs */ object UserRestApis { const val API_AUTHORITY = "/api/authorities" const val API_USERS = "/api/users" const val API_SIGNUP = "/signup" const val API_SIGNUP_PATH = "$API_USERS$API_SIGNUP" const val API_ACTIVATE = "/activate" const val API_ACTIVATE_PATH = "$API_USERS$API_ACTIVATE?key=" const val API_ACTIVATE_PARAM = "{activationKey}" const val API_ACTIVATE_KEY = "key" const val API_RESET_INIT = "/reset-password/init" const val API_RESET_FINISH = "/reset-password/finish" const val API_CHANGE = "/change-password" const val API_CHANGE_PATH = "$API_USERS$API_CHANGE" } } // Abstract entity model with Generic ID, which can be of any type abstract class EntityModel<T>( open val id: T? = null ) { companion object { const val ID_MEMBER = "id" } } // Generic extension function that allows the ID to be applied to any EntityModel type inline fun <reified T : EntityModel<ID>, ID> T.withId(id: ID): T { // Use reflection to create a copy with the passed ID return this::class.constructors.first { it.parameters.any { param -> param.name == ID_MEMBER } } .call(id, *this::class.constructors.first().parameters.drop(1).map { param -> this::class.members.first { member -> member.name == param.name }.call(this) }.toTypedArray()) }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_les_différentes_approches">4. Les différentes approches</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_lapproche_classique_avec_when">4.1. L’approche classique avec <code>when</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val user: User by lazy { userFactory(USER) } val result: Either<Throwable, User> = context.findOneUserByEmail(user.email) when (result) { is Either.Left -> { val error = result.value println("Erreur : ${error.message}") } is Either.Right -> { val user = result.value println("Utilisateur trouvé : ${user.login}") } }</code></pre> </div> </div> <div class="paragraph"> <p>Cette méthode, bien que simple et lisible, ne tire pas pleinement parti des capacités fonctionnelles d’Arrow.</p> </div> </div> <div class="sect2"> <h3 id="_utilisation_de_fold_pour_une_approche_plus_concise">4.2. Utilisation de <code>fold</code> pour une approche plus concise</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">result.fold( { error -> println("Erreur : ${error.message}") }, { user -> println("Utilisateur trouvé : ${user.login}") } )</code></pre> </div> </div> <div class="paragraph"> <p><code>fold</code> permet de définir des actions pour les deux cas (Left et Right) de manière concise et élégante.</p> </div> </div> <div class="sect2"> <h3 id="_transformation_avec_map_et_mapleft">4.3. Transformation avec <code>map</code> et <code>mapLeft</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val processedResult = result .map { user -> "Utilisateur trouvé : ${user.login}" } .mapLeft { error -> "Erreur : ${error.message}" } println(processedResult.merge())</code></pre> </div> </div> <div class="paragraph"> <p>Cette approche permet de transformer les valeurs contenues dans Either tout en préservant sa structure, idéal pour des chaînes de traitement plus complexes.</p> </div> </div> <div class="sect2"> <h3 id="_gestion_des_erreurs_avec_getorelse">4.4. Gestion des erreurs avec <code>getOrElse</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val user = result.getOrElse { error -> println("Erreur : ${error.message}") User(login = "default", email = "default@example.com") // utilisateur par défaut } println("Login : ${user.login}")</code></pre> </div> </div> <div class="paragraph"> <p><code>getOrElse</code> offre une gestion élégante des erreurs en permettant de fournir une valeur par défaut.</p> </div> </div> <div class="sect2"> <h3 id="_actions_latérales_avec_onleft_et_onright">4.5. Actions latérales avec <code>onLeft</code> et <code>onRight</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">result.onLeft { error -> println("Erreur : ${error.message}") } .onRight { user -> println("Utilisateur trouvé : ${user.login}") }</code></pre> </div> </div> <div class="paragraph"> <p>Ces méthodes permettent d’effectuer des actions sur chaque côté sans modifier l’Either, parfait pour le logging ou les effets secondaires légers.</p> </div> </div> <div class="sect2"> <h3 id="_chaînage_dopérations_avec_flatmap">4.6. Chaînage d’opérations avec <code>flatMap</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">fun findUser(email: String): Either<Throwable, User> = // ... implémentation fun getUserPermissions(user: User): Either<Throwable, List<String>> = // ... implémentation val userPermissions = findUser("user@example.com") .flatMap { user -> getUserPermissions(user) }</code></pre> </div> </div> <div class="paragraph"> <p><code>flatMap</code> est utile pour enchaîner des opérations qui retournent elles-mêmes des <code>Either</code>, évitant ainsi les <code>Either</code> imbriqués.</p> </div> </div> <div class="sect2"> <h3 id="_transformation_bidirectionnelle_avec_bimap">4.7. Transformation bidirectionnelle avec <code>bimap</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result: Either<Throwable, User> = // ... obtention du résultat val processedResult = result.bimap( { error -> "Erreur: ${error.message}" }, { user -> "Utilisateur: ${user.login}" } )</code></pre> </div> </div> <div class="paragraph"> <p><code>bimap</code> permet de transformer à la fois le côté gauche et le côté droit en une seule opération.</p> </div> </div> <div class="sect2"> <h3 id="_inversion_des_côtés_avec_swap">4.8. Inversion des côtés avec <code>swap</code></h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result: Either<Throwable, User> = // ... obtention du résultat val swapped = result.swap()</code></pre> </div> </div> <div class="paragraph"> <p><code>swap</code> est utile lorsque vous voulez inverser les côtés d’un <code>Either</code>, par exemple pour adapter l’interface d’une fonction à une autre.</p> </div> </div> <div class="sect2"> <h3 id="_utilisation_de_tap_et_tapleft">4.9. Utilisation de <code>tap</code> et <code>tapLeft</code> :</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">result.tap { user -> println("Utilisateur trouvé : ${user.login}") } .tapLeft { error -> println("Erreur : ${error.message}") }</code></pre> </div> </div> <div class="paragraph"> <p>Similaire à <code>onLeft</code> et <code>onRight</code>, mais ces méthodes retournent l’Either original, ce qui est utile pour le chaînage d’opérations.</p> </div> </div> <div class="sect2"> <h3 id="_utilisation_de_recover">4.10. Utilisation de <code>recover</code> :</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val recoveredUser = result.recover { error -> println("Erreur récupérée : ${error.message}") User(login = "recovered", email = "recovered@example.com") } println("Login : ${recoveredUser.login}")</code></pre> </div> </div> <div class="paragraph"> <p>Cette méthode permet de transformer un Either.Left en Either.Right en fournissant une valeur de remplacement.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_cas_dutilisation_pratiques">5. Cas d’utilisation pratiques</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Utilisez <code>fold</code> pour des opérations simples nécessitant un traitement pour chaque cas.</p> </li> <li> <p>Préférez <code>map</code> et <code>mapLeft</code> pour des transformations de données sans changer la structure de l'`Either`.</p> </li> <li> <p>Optez pour <code>flatMap</code> lors du chaînage d’opérations pouvant échouer.</p> </li> <li> <p>Employez <code>recover</code> pour fournir une valeur par défaut en cas d’erreur.</p> </li> <li> <p>Choisissez <code>onLeft</code> et <code>onRight</code> (ou <code>tap</code> et <code>tapLeft</code>) pour des effets secondaires comme le logging.</p> </li> <li> <p>Utilisez <code>bimap</code> pour transformer les deux côtés en une seule opération.</p> </li> <li> <p>Appliquez <code>swap</code> lorsque vous devez adapter l’interface d’une fonction à une autre.</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">6. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Chacune de ces approches a ses avantages selon le contexte d’utilisation. Les méthodes comme <code>fold</code>, <code>map</code>/<code>mapLeft</code>, et <code>recover</code> sont particulièrement utiles lorsque vous voulez enchaîner plusieurs opérations ou transformer les données de manière fonctionnelle.</p> </div> <div class="paragraph"> <p>La monade <code>Either</code> d’Arrow offre une flexibilité remarquable pour gérer les cas de succès et d’erreur dans vos applications Kotlin. En maîtrisant ces différentes approches, vous pourrez écrire un code plus robuste, plus lisible et plus fonctionnel.</p> </div> <div class="paragraph"> <p>Dans votre prochain projet, n’hésitez pas à explorer ces techniques pour tirer le meilleur parti de la programmation fonctionnelle avec Kotlin et Arrow !</p> </div> </div> </div> <div class="sect1"> <h2 id="_pour_aller_plus_loin">7. Pour aller plus loin</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Documentation officielle d’Arrow : <a href="https://arrow-kt.io/docs/apidocs/arrow-core/arrow.core/-either/">Arrow Either</a></p> </li> <li> <p>Kotlin Coroutines avec Arrow : <a href="https://arrow-kt.io/docs/fx/">Arrow Fx Coroutines</a></p> </li> </ul> </div> <div class="paragraph"> <p>N’oubliez pas de partager vos expériences et vos techniques préférées pour travailler avec <code>Either</code> dans les commentaires ci-dessous !</p> </div> </div> </div> https://pages-content.github.io//blog/2024/0074_seach_file_linux_post.html Mon, 23 Sep 2024 00:00:00 +0000 blog/2024/0074_seach_file_linux_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_introduction">1. Introduction</a></li> <li><a href="#_utilisation_de_la_commande_find">2. Utilisation de la commande <code>find</code></a> <ul class="sectlevel2"> <li><a href="#_options_supplémentaires_pour_find">2.1. Options supplémentaires pour <code>find</code></a></li> </ul> </li> <li><a href="#_utilisation_de_la_commande_locate">3. Utilisation de la commande <code>locate</code></a></li> <li><a href="#_utilisation_de_la_commande_grep_pour_rechercher_du_texte_dans_des_fichiers">4. Utilisation de la commande <code>grep</code> pour rechercher du texte dans des fichiers</a></li> <li><a href="#_conclusion">5. Conclusion</a></li> </ul> </div> <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title"><em>Temps de lecture :</em></div> <p>5 à 7 minutes.</p> </div> <div class="paragraph"> <div class="title"><em>Public :</em></div> <p>Débutant et intermédiaires.</p> </div> <div class="paragraph"> <div class="title">La problématique :</div> <p>Rechercher des fichiers dans un système d’exploitation linux à travers le terminal.</p> </div> </div> </div> <div class="sect1"> <h2 id="_introduction">1. Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Dans cet article, nous allons explorer comment rechercher un fichier sous Ubuntu en utilisant un terminal Zsh. Zsh (Z shell) est un interpréteur de commandes puissant et largement utilisé pour sa flexibilité et ses fonctionnalités avancées.</p> </div> <div class="paragraph"> <p>Ubuntu, une distribution Linux populaire, propose plusieurs outils en ligne de commande pour rechercher des fichiers. Nous verrons comment utiliser des commandes telles que <code>find</code>, <code>locate</code> et <code>grep</code> pour localiser des fichiers rapidement et efficacement dans le terminal.</p> </div> </div> </div> <div class="sect1"> <h2 id="_utilisation_de_la_commande_find">2. Utilisation de la commande <code>find</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>La commande <code>find</code> permet de rechercher des fichiers dans un répertoire spécifique et ses sous-répertoires. Sa syntaxe de base est la suivante :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">find [chemin] -name [nom_du_fichier]</code></pre> </div> </div> <div class="paragraph"> <p>Voici un exemple pratique où nous recherchons un fichier nommé <code>example.txt</code> dans le répertoire <code>/home</code> :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">find /home -name "example.txt"</code></pre> </div> </div> <div class="paragraph"> <p>Cette commande va parcourir tous les sous-répertoires de <code>/home</code> et afficher le chemin complet du fichier s’il est trouvé.</p> </div> <div class="paragraph"> <p><strong>Manuel en ligne de la commande <code>find</code> : <a href="https://man.archlinux.org/man/find.1.fr/">man find</a></strong></p> </div> <div class="sect2"> <h3 id="_options_supplémentaires_pour_find">2.1. Options supplémentaires pour <code>find</code></h3> <div class="paragraph"> <p>La commande <code>find</code> est très puissante et dispose de nombreuses options. Voici quelques exemples utiles :</p> </div> <div class="ulist"> <ul> <li> <p><strong>Rechercher par type de fichier</strong> : Pour rechercher uniquement des fichiers, utilisez <code>-type f</code>, et pour rechercher des répertoires, utilisez <code>-type d</code>.</p> </li> <li> <p><strong>Rechercher par taille</strong> : Vous pouvez aussi filtrer les fichiers en fonction de leur taille en utilisant l’option <code>-size</code>. Par exemple, pour rechercher des fichiers de plus de 100 Mo, utilisez :</p> </li> </ul> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">find /home -size +100M</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_utilisation_de_la_commande_locate">3. Utilisation de la commande <code>locate</code></h2> <div class="sectionbody"> <div class="paragraph"> <p>La commande <code>locate</code> est plus rapide que <code>find</code> car elle utilise une base de données pré-indexée des fichiers présents sur le système. Vous devez d’abord mettre à jour cette base de données avec la commande suivante :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">sudo updatedb</code></pre> </div> </div> <div class="paragraph"> <p>Ensuite, vous pouvez rechercher un fichier comme ceci :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">locate example.txt</code></pre> </div> </div> <div class="paragraph"> <p>J’utilise <a href="https://fr.wikipedia.org/wiki/Z_Shell">zsh</a> avec <a href="https://github.com/ohmyzsh/ohmyzsh/wiki">oh-my-zsh</a>, il s’avere que la commande <code>locate</code> n’est pas accessible depuis <code>zsh</code> mais bien possible depuis <code>bash</code>, pour palier à cela, l’argument <code>-c</code> de la commande <code>bash</code> permet de lancer une commande <code>bash</code> depuis un autre type de terminal.</p> </div> <div class="paragraph"> <p>ici je cherche les fichiers qui se termine par le motif <code>001.pdf</code> dans le user directory</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">bash -c "locate ~/*001.pdf"</code></pre> </div> </div> <div class="paragraph"> <p><strong>Manuel en ligne de la commande <code>locate</code> : <a href="https://man.archlinux.org/man/locate.1.fr/">man locate</a></strong></p> </div> </div> </div> <div class="sect1"> <h2 id="_utilisation_de_la_commande_grep_pour_rechercher_du_texte_dans_des_fichiers">4. Utilisation de la commande <code>grep</code> pour rechercher du texte dans des fichiers</h2> <div class="sectionbody"> <div class="paragraph"> <p>Si vous voulez rechercher un texte spécifique à l’intérieur d’un fichier, vous pouvez utiliser <code>grep</code>. Par exemple, pour rechercher l’occurrence du mot "Ubuntu" dans tous les fichiers <code>.txt</code> du répertoire courant, utilisez :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">grep "Ubuntu" *.txt</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">5. Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>La recherche de fichiers sous Ubuntu via un terminal Zsh peut se faire à l’aide de plusieurs outils puissants. <code>find</code> est flexible et offre une multitude d’options, tandis que <code>locate</code> permet une recherche rapide à l’aide d’une base de données pré-construite. Enfin, <code>grep</code> permet de trouver des occurrences de texte à l’intérieur des fichiers.</p> </div> <div class="paragraph"> <p>Ces commandes vous offrent une gamme complète d’outils pour rendre vos recherches de fichiers plus efficaces et adaptées à vos besoins et chacune des ces commande posséde un manuel visible avec la commande <code>man</code></p> </div> </div> </div> https://pages-content.github.io//blog/2021/0030_memo_linux_post.html Mon, 23 Sep 2024 00:00:00 +0000 blog/2021/0030_memo_linux_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_le_clavier">1. Le clavier :</a> <ul class="sectlevel2"> <li><a href="#_la_touche_ctrl">1.1. <em>la touche <Ctrl></em></a></li> </ul> </li> <li><a href="#_permissionauthorization">2. Permission(authorization)</a></li> <li><a href="#_recherche_de_fichiers">3. Recherche de fichiers</a></li> </ul> </div> <div class="sect1"> <h2 id="_le_clavier">1. Le clavier :</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_la_touche_ctrl">1.1. <em>la touche <Ctrl></em></h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 33.3333%;"> <col style="width: 33.3333%;"> <col style="width: 33.3334%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"><em>Code</em></th> <th class="tableblock halign-left valign-top"><em>Touches associées</em></th> <th class="tableblock halign-left valign-top"><em>Fonction</em></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>intr</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^C</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Stopper un programme</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>erase</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^H</strong> <em><Backspace></em></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Effacer le dernier caractère</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>werase</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^W</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Effacer le dernier mot</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>kill</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^U</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Effacer la ligne</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>quit</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^\</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Stopper programme avec core</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>stop</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^S</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Geler l’affichage à l’écran</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>start</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^Q</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Relancer l’affichage</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>eof</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^D</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Indiquer la fin des données</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>rprnt</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^R</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Réimpression de la ligne</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>flush</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^O</strong></p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>lnext</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^V</strong></p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>susp</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^Z /^Y</strong></p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>^I</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tabulation</p></td> </tr> </tbody> </table> <div class="paragraph"> <p><a href="https://korben.info/les-raccourcis-clavier-pour-bash-terminal-linux-et-macos.html">lien</a><br> <a href="https://blogmotion.fr/systeme/astuces-bash-linux-16175">autre lien</a></p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_permissionauthorization">2. Permission(authorization)</h2> <div class="sectionbody"> <div class="paragraph"> <p>CHMOD est utilisé pour changer les permissions d’un fichier.</p> </div> <div class="listingblock"> <div class="content"> <pre>PERMISSION COMMAND U G W rwx rwx rwx chmod 777 filename rwx rwx r-x chmod 775 filename rwx r-x r-x chmod 755 filename rw- rw- r-- chmod 664 filename rw- r-- r-- chmod 644 filename U = User G = Group W = World r = Readable w = writable x = executable - = no permission</pre> </div> </div> <div class="paragraph"> <p>Une autre facon de voir les permissions:</p> </div> <div class="listingblock"> <div class="content"> <pre>400 read by owner 040 read by group 004 read by anybody (other) 200 write by owner 020 write by group 002 write by anybody 100 execute by owner 010 execute by group 001 execute by anybody</pre> </div> </div> <div class="paragraph"> <p>Pour obtenir une combinaison, il suffit de les additionner.<br> Par exemple, pour être lu, écrit, exécuté par le propriétaire,<br> lu, exécuté, par groupe et exécuté par n’importe qui,<br> vous ajouteriez 400+200+100+040+010+001 pour donner 751.<br></p> </div> </div> </div> <div class="sect1"> <h2 id="_recherche_de_fichiers">3. <a href="/blog/2024/0074_seach_file_linux_post.html">Recherche de fichiers</a></h2> <div class="sectionbody"> </div> </div> https://pages-content.github.io//blog/2024/0072_Exposer_un_port_linux_subsystem_post.adoc.html Thu, 1 Feb 2024 00:00:00 +0000 blog/2024/0072_Exposer_un_port_linux_subsystem_post.adoc.html <div class="paragraph"> <div class="title">La problématique :</div> <p>Comment exposer le port 8820 du sous système ubuntu dont l’hôte est windows ? Ubuntu est amorcé par la commande <code>wsl --install</code>.</p> </div> <div class="paragraph"> <div class="title">Réference :</div> <p><a href="https://www.it-connect.fr/wsl-2-port-forwarding-comment-acceder-a-sa-machine-virtuelle-a-distance/">wsl-2-port-forwarding</a></p> </div> https://pages-content.github.io//blog/2024/0070_installer_pandoc_post.html Tue, 30 Jan 2024 00:00:00 +0000 blog/2024/0070_installer_pandoc_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title"><em>Temps de lecture : 3 min</em></div> <p>Pandoc un convertisseur universel de document</p> </div> <div class="paragraph"> <p>Pandoc est un logiciel de traitement de texte open source qui peut être utilisé pour convertir des documents entre différents formats. Il existe plusieurs façons d’installer Pandoc.</p> </div> </div> </div> <div class="sect1"> <h2 id="_installation_à_partir_de_la_page_de_téléchargement"><strong>Installation à partir de la page de téléchargement</strong></h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour installer Pandoc à partir de la page de téléchargement, procédez comme suit :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Accédez à la page de téléchargement de Pandoc : <a href="https://pandoc.org/installing.html/">https://pandoc.org/installing.html</a></p> </li> <li> <p>Téléchargez l’installateur de package pour votre système d’exploitation.</p> </li> <li> <p>Exécutez l’installateur pour installer Pandoc.</p> </li> </ol> </div> <div class="paragraph"> <p><strong>Installation à partir d’un fichier zip</strong></p> </div> <div class="paragraph"> <p>Pour installer Pandoc à partir d’un fichier zip, procédez comme suit :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Téléchargez le fichier zip contenant les binaires de Pandoc et la documentation.</p> </li> <li> <p>Décompressez le fichier zip.</p> </li> <li> <p>Déplacez les binaires vers un répertoire de votre choix.</p> </li> </ol> </div> <div class="paragraph"> <p><strong>Installation à l’aide de Chocolatey</strong></p> </div> <div class="paragraph"> <p>Pour installer Pandoc à l’aide de Chocolatey, procédez comme suit :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Ouvrez une invite de commande.</p> </li> <li> <p>Exécutez la commande suivante :</p> </li> </ol> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-powershell" data-lang="powershell">choco install pandoc</code></pre> </div> </div> <div class="paragraph"> <p><strong>Installation à l’aide de winget</strong></p> </div> <div class="paragraph"> <p>Pour installer Pandoc à l’aide de winget, procédez comme suit :</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Ouvrez une invite de commande.</p> </li> <li> <p>Exécutez la commande suivante :</p> </li> </ol> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-powershell" data-lang="powershell">winget install --source winget --exact --id JohnMacFarlane.Pandoc</code></pre> </div> </div> <div class="paragraph"> <p><strong>Recommandations</strong></p> </div> <div class="paragraph"> <p>Par défaut, Pandoc crée des PDFs à l’aide de LaTeX. Il est recommandé d’installer LaTeX via MiKTeX. Avec l’option <code>--pdf-engine</code>, vous pouvez toutefois spécifier d’autres programmes pour cette tâche.</p> </div> <div class="paragraph"> <p><strong>Mise en garde</strong></p> </div> <div class="paragraph"> <p>L’utilisation de plusieurs méthodes d’installation peut entraîner deux installations distinctes de Pandoc. Il est recommandé de désinstaller correctement Pandoc avant de passer à une méthode d’installation alternative.</p> </div> <div class="paragraph"> <p><strong>Installation sur linux par WSL</strong></p> </div> <div class="paragraph"> <p>Vérifiez si la version de pandoc dans votre gestionnaire de paquets n’est pas obsolète. Pandoc se trouve dans les dépôts de Debian, Ubuntu, Slackware, Arch, Fedora, NixOS, openSUSE, gentoo et Void.</p> </div> <div class="paragraph"> <p>Pour obtenir la dernière version, nous proposons un paquet binaire pour l’architecture amd64 sur la page de téléchargement.</p> </div> <div class="paragraph"> <p>L’exécutable est lié statiquement et n’a pas de dépendances dynamiques ni de dépendances sur des fichiers de données externes. Remarque : en raison du lien statique, le binaire pandoc de ce paquet ne peut pas utiliser les filtres lua qui nécessitent des modules lua externes écrits en C.</p> </div> <div class="paragraph"> <p>Un tarball et un installateur deb sont fournis. Pour installer le deb :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">sudo dpkg -i $DEB</code></pre> </div> </div> <div class="paragraph"> <p>Exemple au moment de l’écriture :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">wget https://github.com/jgm/pandoc/releases/download/3.1.11.1/pandoc-3.1.11.1-1-amd64.deb</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">sudo dpkg -i pandoc-3.1.11.1-1-amd64.deb</code></pre> </div> </div> <div class="paragraph"> <p>où <code>$DEB</code> est le chemin vers le deb téléchargé. Cela installera l’exécutable <code>pandoc</code> et la page de manuel.</p> </div> <div class="paragraph"> <p>Si vous utilisez une distribution basée sur RPM, vous pourrez peut-être installer le deb de notre page de téléchargement à l’aide d’alien.</p> </div> <div class="paragraph"> <p>Sur n’importe quelle distribution, vous pouvez installer à partir du tarball dans <code>$DEST</code> (par exemple, <code>/usr/local/</code> ou <code>$HOME/.local</code>) en faisant :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">tar xvzf $TGZ --strip-components 1 -C $DEST</code></pre> </div> </div> <div class="paragraph"> <p>où <code>$TGZ</code> est le chemin vers le tarball zippé téléchargé. Pour les versions de Pandoc antérieures à 2.0, qui ne fournissent pas de tarball, essayez plutôt :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">ar p $DEB data.tar.gz | tar xvz --strip-components 2 -C $DEST</code></pre> </div> </div> <div class="paragraph"> <p>Vous pouvez également installer à partir de la source, en utilisant les instructions ci-dessous sous <code>Compilation à partir de la source</code>. Notez que la plupart des distributions ont la plate-forme Haskell dans leurs dépôts de paquets. Par exemple, sur Debian/Ubuntu, vous pouvez l’installer avec </p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">apt-get install haskell-platform</code></pre> </div> </div> <div class="paragraph"> <p>Par défaut, Pandoc crée des PDFs à l’aide de LaTeX. Nous vous recommandons d’installer TeX Live via votre gestionnaire de paquets. (Sur Debian/Ubuntu, <code>apt-get install texlive</code>). Avec l’option <code>--pdf-engine</code>, vous pouvez toutefois spécifier d’autres programmes pour cette tâche.</p> </div> </div> </div> https://pages-content.github.io//blog/2023/0069_triple_python_js_ts_post.html Mon, 25 Dec 2023 00:00:00 +0000 blog/2023/0069_triple_python_js_ts_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <div class="title"><em>Temps de lecture : 2 min</em></div> <p>Créer une implémentation complète de la classe kotlin.Triple en JavaScript, TypeScript et Python en utilisant la programmation fonctionnelle.</p> </div> <div class="paragraph"> <p><strong>Note :</strong> Les types <code>Maybe</code>, <code>Either</code>, <code>Result</code> ne font pas partie du langage de base en JavaScript ou TypeScript, donc il faut les implémenter nous-mêmes.</p> </div> </div> </div> <div class="sect1"> <h2 id="_javascript">JavaScript</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">//javascript // Maybe type const Maybe = (value) => ({ map: (fn) => (value !== null && value !== undefined ? Maybe(fn(value)) : Maybe(null)), flatMap: (fn) => (value !== null && value !== undefined ? fn(value) : Maybe(null)), getOrElse: (defaultValue) => (value !== null && value !== undefined ? value : defaultValue), }); // Either type const Either = { Left: (value) => ({ map: (fn) => Either.Left(value), flatMap: (fn) => Either.Left(value), getOrElse: (defaultValue) => defaultValue, isLeft: true, isRight: false, }), Right: (value) => ({ map: (fn) => Either.Right(fn(value)), flatMap: (fn) => fn(value), getOrElse: (defaultValue) => value, isLeft: false, isRight: true, }), }; // Triple class class Triple { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } map(fn) { return new Triple(fn(this.a), fn(this.b), fn(this.c)); } static of(a, b, c) { return new Triple(a, b, c); } // Example method using Maybe and Either divideBy(other) { return Maybe(this.b) .flatMap((numerator) => Maybe(other) .flatMap((denominator) => denominator !== 0 ? Either.Right(numerator / denominator) : Either.Left('Division by zero') ) ) .getOrElse(Either.Left('Invalid input')); } } // Example usage const triple = Triple.of(1, 2, 3); const result = triple.map((x) => x * 2); console.log(result); // Triple { a: 2, b: 4, c: 6 } const divisionResult = triple.divideBy(2); console.log(divisionResult); // Either.Right { value: 1 } const invalidDivisionResult = triple.divideBy(0); console.log(invalidDivisionResult); // Either.Left { value: 'Division by zero' }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_typescript">TypeScript</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">//Typescript // Maybe type // noinspection JSAnnotator type Maybe<T> = { map<U>(fn: (value: T) => U): Maybe<U>; flatMap<U>(fn: (value: T) => Maybe<U>): Maybe<U>; getOrElse(defaultValue: T): T; }; const just = <T>(value: T): Maybe<T> => ({ map: <U>(fn: (value: T) => U) => just(fn(value)), flatMap: <U>(fn: (value: T) => Maybe<U>) => fn(value), getOrElse: (_: T) => value, }); const nothing = <T>(): Maybe<T> => ({ map: <U>(_: (value: T) => U) => nothing<U>(), flatMap: <U>(_: (value: T) => Maybe<U>) => nothing<U>(), getOrElse: (defaultValue: T) => defaultValue, }); // Either type type Either<L, R> = { map<U>(fn: (value: R) => U): Either<L, U>; flatMap<U>(fn: (value: R) => Either<L, U>): Either<L, U>; getOrElse(defaultValue: R): R; isLeft: boolean; isRight: boolean; }; const left = <L, R>(value: L): Either<L, R> => ({ map: <U>(_: (value: R) => U) => left<L, U>(value), flatMap: <U>(_: (value: R) => Either<L, U>) => left<L, U>(value), getOrElse: (defaultValue: R) => defaultValue, isLeft: true, isRight: false, }); const right = <L, R>(value: R): Either<L, R> => ({ map: <U>(fn: (value: R) => U) => right<L, U>(fn(value)), flatMap: <U>(fn: (value: R) => Either<L, U>) => fn(value), getOrElse: (_: R) => value, isLeft: false, isRight: true, }); // Triple class class Triple<T> { constructor(public a: T, public b: T, public c: T) {} map<U>(fn: (value: T) => U): Triple<U> { return new Triple<U>(fn(this.a), fn(this.b), fn(this.c)); } static of<T>(a: T, b: T, c: T): Triple<T> { return new Triple<T>(a, b, c); } // Example method using Maybe and Either divideBy(other: T): Either<string, number> { return just(this.b) .flatMap((numerator) => just(other) .flatMap((denominator) => denominator !== 0 ? right(numerator / denominator) : left('Division by zero') ) ) .getOrElse(left('Invalid input')); } } // Example usage const triple = Triple.of(1, 2, 3); const result = triple.map((x) => x * 2); console.log(result); // Triple { a: 2, b: 4, c: 6 } const divisionResult = triple.divideBy(2); console.log(divisionResult); // Either.Right { value: 1 } const invalidDivisionResult = triple.divideBy(0); console.log(invalidDivisionResult); // Either.Left { value: 'Division by zero' }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_python_pydantic_pymonad">Python, pydantic, pymonad</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour créer une implémentation en Python en utilisant <code>pydantic</code> pour la validation des types et <code>pymonad</code> pour les monades :</p> </div> <div class="listingblock"> <div class="title">Installer les dépendances :</div> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">pip install pydantic pymonad</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-python" data-lang="python">from pymonad.either import Either, Left, Right from pydantic import BaseModel, ValidationError, validator # Définition de la classe Triple avec Pydantic class Triple(BaseModel): a: int b: int c: int @validator('b') def validate_b(cls, b, values): if b == 0: raise ValueError('Division by zero is not allowed') return b # Méthode utilisant Either pour la gestion des erreurs def divide_by(self, other): def division(numerator, denominator): return Right(numerator / denominator) def handle_error(error): return Left(str(error)) return Either(lambda: division(self.b, other)).or_else(handle_error) # Exemple d'utilisation try: triple = Triple(a=1, b=2, c=3) result = triple.divide_by(2) if result.is_right: print(f'Division result: {result.value}') else: print(f'Error: {result.value}') except ValidationError as e: print(f'Validation Error: {e}') except Exception as e: print(f'An unexpected error occurred: {e}')</code></pre> </div> </div> <div class="ulist"> <div class="title">Dans cet exemple :</div> <ul> <li> <p><code>pydantic</code> pour définir la classe <code>Triple</code> avec des champs typés.</p> </li> <li> <p>La méthode <code>divide_by</code> utilise la monade <code>Either</code> de <code>pymonad</code> pour gérer les erreurs potentielles résultant de la division par zéro.</p> </li> <li> <p>Validation personnalisée pour s’assurer que la valeur de <code>b</code> n’est pas égale à zéro. Si elle est égale à zéro, une exception est levée, et <code>pymonad</code> capture cette exception pour renvoyer un résultat <code>Left</code> indiquant l’erreur.</p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2023/0068_introduction_google_apps_script_post.html Fri, 22 Dec 2023 00:00:00 +0000 blog/2023/0068_introduction_google_apps_script_post.html <div class="sect1"> <h2 id="_table_des_matières">Table des Matières</h2> <div class="sectionbody"> <div class="paragraph"> <p><em>temps de lecture : 30 min</em></p> </div> <div class="ulist"> <ul> <li> <p><a href="#_introduction">Introduction</a></p> </li> <li> <p><a href="#_structure_de_base_en_google_apps_script">Structure de base en Google Apps Script</a></p> </li> <li> <p><a href="#_types_et_variables_en_google_apps_script">Types et Variables en Google Apps Script</a></p> </li> <li> <p><a href="#Constantes">Variables, et Lettres en Google Apps Script</a></p> </li> <li> <p><a href="#_opérations_et_opérateurs_en_google_apps_script">Opérations et Opérateurs en Google Apps Script</a></p> </li> <li> <p><a href="#Var">Let et Const en Google Apps Script</a></p> </li> <li> <p><a href="#_structures_de_contrôle_en_google_apps_script">Structures de Contrôle en Google Apps Script</a></p> </li> <li> <p><a href="#_boucles_en_google_apps_script">Boucles en Google Apps Script</a></p> </li> <li> <p><a href="#_objets_en_google_apps_script">Objets en Google Apps Script</a></p> </li> <li> <p><a href="#_fonctions_en_google_apps_script">Fonctions en Google Apps Script</a></p> </li> <li> <p><a href="#_paramètres_et_scopes_en_google_apps_script">Paramètres et Scopes en Google Apps Script</a></p> </li> <li> <p><a href="#_opérateurs_de_repos_et_de_propagation_en_google_apps_script">Opérateurs de Repos et de Propagation en Google Apps Script</a></p> </li> <li> <p><a href="#_affectation_par_décomposition_en_google_apps_script">Affectation par Décomposition en Google Apps Script</a></p> </li> <li> <p><a href="#_collections_et_programmation_déclarative_en_google_apps_script">Collections et Programmation Déclarative en Google Apps Script</a></p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_introduction">Introduction</h2> <div class="sectionbody"> <div class="paragraph"> <p>Google Apps Script (GAS) est une plateforme de développement de scripts associée à divers services Google tels que Google Sheets, Google Docs et Google Forms. Elle permet d’automatiser des tâches, d’ajouter des fonctionnalités personnalisées et d’intégrer des services Google.</p> </div> <div class="paragraph"> <p>Dans ce mémo, nous allons explorer les principaux concepts de Google Apps Script en nous appuyant sur des exemples concrets. Nous aborderons des notions telles que les variables, les boucles, les fonctions, et bien d’autres, en les adaptant au contexte spécifique de GAS.</p> </div> </div> </div> <div class="sect1"> <h2 id="_structure_de_base_en_google_apps_script">Structure de base en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour commencer, examinons la structure de base d’un script Google Apps.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Structure de base en Google Apps Script */ function exempleStructureGAS() { // Votre code ici Logger.log("Hello, Google Apps Script!"); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_types_et_variables_en_google_apps_script">Types et Variables en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Google Apps Script utilise JavaScript en tant que langage de programmation. Les types de données et les variables fonctionnent de manière similaire à JavaScript standard.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Types et Variables en Google Apps Script */ function exempleTypesVariablesGAS() { // Votre code ici var nombre = 42; var texte = "Bonjour, Google Apps Script!"; Logger.log(nombre); Logger.log(texte); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_opérations_et_opérateurs_en_google_apps_script">Opérations et Opérateurs en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les opérations et opérateurs en Google Apps Script sont les mêmes qu’en JavaScript.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Opérations et Opérateurs en Google Apps Script */ function exempleOperationsGAS() { // Votre code ici var x = 10; var y = 5; var resultat = x + y; Logger.log(resultat); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_var_let_et_const_en_google_apps_script">Var, Let et Const en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>En GAS, les concepts de <code>var</code>, <code>let</code>, et <code>const</code> sont utilisés pour déclarer des variables. Cependant, il est essentiel de comprendre leurs différences et leurs implications.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Var, Let et Const en Google Apps Script */ function exempleVarLetConstGAS() { // Votre code ici // Utilisation de var var x = 10; if (true) { var x = 20; // La variable x est modifiée globalement } Logger.log(x); // Utilisation de let let y = 30; if (true) { let y = 40; // La variable y est limitée au bloc if } Logger.log(y); // Utilisation de const const z = 50; // z = 60; // Impossible de réassigner une constante Logger.log(z); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_structures_de_contrôle_en_google_apps_script">Structures de Contrôle en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les structures de contrôle telles que <code>if</code>, <code>else</code>, <code>while</code> et <code>for</code> sont utilisées pour gérer le flux d’exécution dans Google Apps Script.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Structures de Contrôle en Google Apps Script */ function exempleStructuresControleGAS() { // Votre code ici var condition = true; if (condition) { Logger.log("La condition est vraie."); } else { Logger.log("La condition est fausse."); } var compteur = 0; while (compteur < 5) { Logger.log(compteur); compteur++; } for (var i = 0; i < 3; i++) { Logger.log(i); } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_paramètres_et_scopes_en_google_apps_script">Paramètres et Scopes en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les paramètres et les scopes jouent un rôle crucial dans le développement de scripts en GAS. Comprenez comment ils fonctionnent pour éviter des comportements inattendus.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Paramètres et Scopes en Google Apps Script */ function exempleParametresScopesGAS(parametre) { // Votre code ici var variableGlobale = "Je suis global"; function afficherParametre() { Logger.log(parametre); } afficherParametre(); Logger.log(variableGlobale); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_constantes_variables_et_lettres_en_google_apps_script">Constantes, Variables, et Lettres en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Comprendre la différence entre <code>const</code>, <code>var</code>, et <code>let</code> est essentiel pour une utilisation efficace des variables en Google Apps Script.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Constantes, Variables, et Lettres en Google Apps Script */ function exempleConstantesVariablesLettresGAS() { // Votre code ici const constante = "Je ne change pas"; Logger.log(constante); var variable = "Je peux changer"; Logger.log(variable); let lettre = "Je peux aussi changer, mais seulement dans mon bloc"; Logger.log(lettre); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_boucles_en_google_apps_script">Boucles en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les boucles, telles que <code>for</code> et <code>while</code>, sont essentielles pour itérer sur des éléments et effectuer des opérations répétitives.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Boucles en Google Apps Script */ function exempleBouclesGAS() { // Votre code ici for (var i = 0; i < 3; i++) { Logger.log(i); } var condition = true; var compteur = 0; while (condition) { Logger.log("Tour de boucle"); compteur++; if (compteur === 3) { condition = false; } } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_objets_en_google_apps_script">Objets en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les objets sont utilisés pour structurer les données. Dans GAS, de nombreux objets intégrés facilitent l’interaction avec les services Google.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Objets en Google Apps Script */ function exempleObjetsGAS() { // Votre code ici var feuille = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet(); var cellule = feuille.getRange("A1"); cellule.setValue("Nouvelle valeur"); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_constantes_variables_et_lettres_en_google_apps_script_2">Constantes, Variables, et Lettres en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Comprendre la différence entre <code>const</code>, <code>var</code>, et <code>let</code> est essentiel pour une utilisation efficace des variables en Google Apps Script.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Constantes, Variables, et Lettres en Google Apps Script */ function exempleConstantesVariablesLettresGAS() { // Votre code ici const constante = "Je ne change pas"; Logger.log(constante); var variable = "Je peux changer"; Logger.log(variable); let lettre = "Je peux aussi changer, mais seulement dans mon bloc"; Logger.log(lettre); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_fonctions_en_google_apps_script">Fonctions en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les fonctions sont des éléments fondamentaux en programmation. En GAS, elles peuvent être déclarées et appelées de différentes manières.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Fonctions en Google Apps Script */ function exempleFonctionsGAS() { // Votre code ici function additionner(a, b) { return a + b; } var resultat = additionner(2, 3); Logger.log(resultat); // Fonction anonyme var multiplier = function (x, y) { return x * y; }; Logger.log(multiplier(4, 5)); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_opérateurs_de_repos_et_de_propagation_en_google_apps_script">Opérateurs de Repos et de Propagation en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les opérateurs de repos (<code>…​</code>) et de propagation (<code>…​</code>) sont utiles pour manipuler les tableaux et les objets de manière concise.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Opérateurs de Repos et de Propagation en Google Apps Script */ function exempleOperateursReposPropagationGAS() { // Votre code ici // Opérateur de repos (...) pour les tableaux var nombres = [1, 2, 3, 4, 5]; var [...copieNombres] = nombres; Logger.log(copieNombres); // Opérateur de propagation (...) pour les objets var objOriginal = { x: 1, y: 2 }; var objClone = { ...objOriginal, z: 3 }; Logger.log(objClone); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_affectation_par_décomposition_en_google_apps_script">Affectation par Décomposition en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’affectation par décomposition est une fonctionnalité puissante qui permet d’extraire des valeurs d’objets et de tableaux de manière concise.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Affectation par Décomposition en Google Apps Script */ function exempleAffectationDecompositionGAS() { // Votre code ici var coordonnees = [3, 4]; var [x, y] = coordonnees; Logger.log(x); Logger.log(y); var utilisateur = { nom: "John", age: 30 }; var { nom, age } = utilisateur; Logger.log(nom); Logger.log(age); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_collections_et_programmation_déclarative_en_google_apps_script">Collections et Programmation Déclarative en Google Apps Script</h2> <div class="sectionbody"> <div class="paragraph"> <p>Google Apps Script prend en charge les structures de données telles que les tableaux, et les concepts de programmation fonctionnelle et d’itération déclarative (><impérative), tels que <code>map</code>, <code>reduce</code> et <code>forEach</code>.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Collections et Programmation Déclarative en Google Apps Script */ function exempleCollectionsFonctionnelleGAS() { // Votre code ici // Exemple de tableau (collection) var nombres = [1, 2, 3, 4, 5]; // Utilisation de forEach nombres.forEach(function (nombre) { Logger.log(nombre); }); // Utilisation de map var carresNombres = nombres.map(function (nombre) { return nombre * nombre; }); Logger.log(carresNombres); // Utilisation de reduce var somme = nombres.reduce(function (acc, nombre) { return acc + nombre; }, 0); Logger.log(somme); }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_conclusion">Conclusion</h2> <div class="sectionbody"> <div class="paragraph"> <p>Ce mémo a couvert les concepts fondamentaux de Google Apps Script en les illustrant à l’aide d’exemples de code concrets. Utilisez ces connaissances pour automatiser vos tâches quotidiennes, personnaliser vos documents et exploiter pleinement les fonctionnalités de Google Apps Script.</p> </div> </div> </div> https://pages-content.github.io//blog/2023/0067_formation_express_sur_google_forms_script_post.html Wed, 20 Dec 2023 00:00:00 +0000 blog/2023/0067_formation_express_sur_google_forms_script_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>Durée : 30 minutes</p> </div> </div> </div> <div class="sect1"> <h2 id="_objectifs">Objectifs</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Comprendre les bases de Google Apps Script dans Forms</p> </li> <li> <p>Apprendre à acceder à l’editeur de script et executer une instruction au déclencheur</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_temporisation">Temporisation</h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><strong>Introduction à Google Form Script</strong> (5 min)</p> <div class="ulist"> <ul> <li> <p>Aperçu rapide de Google Form Script</p> </li> <li> <p>Présentation des fonctionnalités principales</p> </li> </ul> </div> </li> <li> <p><strong>Création d’un Formulaire Google et d’un Script associé</strong> (5 min)</p> <div class="ulist"> <ul> <li> <p>Création d’un formulaire simple avec Google Forms</p> </li> <li> <p>Introduction à l’éditeur de script associé</p> </li> </ul> </div> </li> <li> <p><strong>Executer une instruction</strong> (10 min)</p> <div class="ulist"> <ul> <li> <p>Configuration du déclencheur "on start"</p> </li> <li> <p>Configuration du déclencheur "on submit"</p> </li> <li> <p>Écriture d’un script pour Executer une instruction</p> </li> <li> <p>Tests rapides pour vérifier le bon fonctionnement dans le journal</p> </li> </ul> </div> </li> <li> <p><strong>Analyse des Résultats et Bonnes Pratiques</strong> (10 min)</p> <div class="ulist"> <ul> <li> <p>Vérification des résultats de l’execution d’une instruction</p> </li> <li> <p>Discussion sur un exemple de script et comment l’automatisation peut faire gagner du temps</p> </li> </ul> </div> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="_prérequis">Prérequis</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Avoir un compte Google et accès à Google Forms et Google Sheets</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_matériel">Matériel</h2> <div class="sectionbody"> <div class="ulist"> <ul> <li> <p>Ordinateur avec un navigateur web et une connexion internet</p> </li> </ul> </div> </div> </div> <div class="sect1"> <h2 id="_remarque">Remarque</h2> <div class="sectionbody"> <div class="paragraph"> <p>Cette formation express offre une introduction rapide à l’automatisation avec Google Form Script. Pour une compréhension plus approfondie, des formations plus longues sont recommandées.</p> </div> </div> </div> <div class="sect1"> <h2 id="_1_introduction_à_google_form_script">1 - Introduction à Google Form Script</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_slide_1_aperçu_rapide_de_google_form_script">Slide 1: Aperçu rapide de Google Form Script</h3> <div class="ulist"> <ul> <li> <p>Google Form Script est une plateforme de scripting intégrée à Google Forms.</p> </li> <li> <p>Elle permet d’ajouter des fonctionnalités personnalisées et d’automatiser des tâches.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_slide_2_présentation_des_fonctionnalités_principales">Slide 2: Présentation des fonctionnalités principales</h3> <div class="ulist"> <ul> <li> <p>Script Editor : L’éditeur de script intégré pour écrire des scripts Google Apps Script.</p> </li> <li> <p>Déclencheurs : Des événements comme "on submit" qui activent l’exécution des scripts.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_slide_3_avantages_de_lutilisation_de_google_form_script">Slide 3: Avantages de l’utilisation de Google Form Script</h3> <div class="ulist"> <ul> <li> <p>Personnalisation : Créez des formulaires personnalisés avec des fonctionnalités uniques.</p> </li> <li> <p>Automatisation : Automatisez des actions en réponse aux réponses des formulaires.</p> </li> <li> <p>Intégration : Intégrez des scripts avec d’autres services Google pour une expérience plus riche.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_note_pour_le_présentateur">Note pour le présentateur :</h3> <div class="paragraph"> <p>Ces fonctionnalités offrent un potentiel considérable pour personnaliser et automatiser les formulaires. La suite de cette formation explorera plus en détail la création de scripts et d’automatisations spécifiques.</p> </div> <div class="paragraph"> <p><a href="https://developers.google.com/apps-script/add-ons/editors/forms?hl=fr" class="bare">https://developers.google.com/apps-script/add-ons/editors/forms?hl=fr</a></p> </div> <div class="paragraph"> <p><a href="https://developers.google.com/apps-script/reference/forms?hl=fr" class="bare">https://developers.google.com/apps-script/reference/forms?hl=fr</a></p> </div> <div class="paragraph"> <p><a href="https://developers.google.com/apps-script/reference/forms/form-app?hl=fr" class="bare">https://developers.google.com/apps-script/reference/forms/form-app?hl=fr</a></p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_création_dun_formulaire_google_et_dun_script_associé_5_min"><strong>Création d’un Formulaire Google et d’un Script associé</strong> (5 min)</h2> <div class="sectionbody"> </div> </div> https://pages-content.github.io//blog/2023/0066_memo_python_post.html Sun, 19 Nov 2023 00:00:00 +0000 blog/2023/0066_memo_python_post.html <div class="sect1"> <h2 id="_install_python_on_windows">Install python on windows</h2> <div class="sectionbody"> <div class="paragraph"> <p><a href="https://ninite.com/pythonx3/">python on windows</a></p> </div> <div class="paragraph"> <p><a href="https://python-docs.readthedocs.io/en/latest/starting/install3/win.html" class="bare">https://python-docs.readthedocs.io/en/latest/starting/install3/win.html</a></p> </div> <div class="paragraph"> <p><a href="https://python-docs.readthedocs.io/en/latest/dev/virtualenvs.html#virtualenvironments-ref" class="bare">https://python-docs.readthedocs.io/en/latest/dev/virtualenvs.html#virtualenvironments-ref</a></p> </div> </div> </div> <div class="sect1"> <h2 id="_running_python">Running python</h2> <div class="sectionbody"> <div class="listingblock"> <div class="title">Réference :</div> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">cd mon_projet python -m venv mon_venv source mon_venv/bin/activate # Sur windows mon_venv\Scripts\activate deactivate</code></pre> </div> </div> <div class="sect2"> <h3 id="_install_requirement">install requirement</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">pip install -r requirements.txt</code></pre> </div> </div> </div> </div> </div> <div class="sect1"> <h2 id="_initiation">initiation</h2> <div class="sectionbody"> <div class="paragraph"> <p><a href="https://python.doctor/page-apprendre-programmation-orientee-objet-poo-classes-python-cours-debutants">python POO</a></p> </div> </div> </div> <div class="sect1"> <h2 id="_design_patterns_du_gof_en_python">Design Patterns du GoF en Python</h2> <div class="sectionbody"> <div class="paragraph"> <p><a href="https://github.com/whikwon/python-patterns/">implementation 1</a></p> </div> <div class="paragraph"> <p><a href="https://github.com/Sean-Bradley/Design-Patterns-In-Python">implementation 2</a></p> </div> <div class="paragraph"> <p><a href="https://sbcode.net/python/">complete book</a></p> </div> <div class="paragraph"> <p>Les design patterns du GoF sont un ensemble de 23 design patterns qui ont été décrits dans le livre "Design Patterns: Elements of Reusable Object-Oriented Software".</p> </div> <table class="tableblock frame-all grid-all stretch"> <caption class="title">Table 1. Voici une liste des design patterns du GoF</caption> <colgroup> <col style="width: 33.3333%;"> <col style="width: 66.6667%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top">Nom</th> <th class="tableblock halign-left valign-top">Description</th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Factory Method</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Crée des objets sans spécifier la classe exacte à instancier.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Abstract Factory</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Crée des familles d’objets liés ou dépendants sans spécifier leur classe concrète.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Builder</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Sépare la construction d’un objet complexe de sa représentation afin que le même processus de construction puisse créer différentes représentations.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Prototype</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Crée de nouveaux objets en copiant un prototype existant.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Singleton</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Restreint l’instanciation d’une classe à un seul objet.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Adapter</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Convertit l’interface d’une classe en une autre interface que le client attend.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Bridge</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Découple une abstraction de son implémentation afin que les deux puissent varier indépendamment.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Composite</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Compose des objets dans des structures d’arborescence pour représenter des hiérarchies de partie-tout.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Decorator</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Attache dynamiquement des responsabilités supplémentaires à un objet.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Facade</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fournit une interface unifiée à un ensemble d’interfaces dans un sous-système.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Flyweight</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Réduit le coût de création et d’utilisation d’objets légers.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Proxy</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fournit un substitut ou un espace réservé pour un autre objet afin de contrôler l’accès à celui-ci.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Chain of Responsibility</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Permet à plus d’un objet de traiter une demande.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Command</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Encapsule une demande dans un objet, permettant ainsi de paramétrer des clients avec différentes demandes, files d’attente ou journaux, et de supporter des opérations annulables.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Interpreter</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Donne une représentation de la grammaire d’une langue et utilise cette représentation pour interpréter des phrases dans cette langue.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Iterator</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fournit un moyen de parcourir séquentiellement les éléments d’un objet agrégé sans exposer sa représentation sous-jacente.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Mediator</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Permet de réduire les dépendances complexes entre les objets en les faisant communiquer uniquement via un objet médiateur.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Memento</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fournit la capacité de restaurer un objet à son état précédent (sans violer l’encapsulation).</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Observer</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Définit une dépendance un-à-plusieurs entre les objets de sorte que lorsqu’un objet change d’état, tous ses dépendants sont notifiés et mis à jour automatiquement.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>State</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Permet à un objet de changer de comportement lorsqu’il change d’état interne.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Strategy</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Définit une famille d’algorithmes, encapsule chacun d’eux et les rend interchangeables.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Template Method</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Définit le squelette d’un algorithme dans une méthode, reportant certaines étapes aux sous-classes.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Visitor</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Permet de définir une nouvelle opération à effectuer sur une structure d’objets sans changer les classes des objets sur lesquels elle opère.</p></td> </tr> </tbody> </table> </div> </div> <div class="sect1"> <h2 id="_functional_programming">Functional programming</h2> <div class="sectionbody"> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 16.6666%;"> <col style="width: 27.7777%;"> <col style="width: 55.5557%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Bibliothèque</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">URL</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Description</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">PyMonad</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/jasondelaat/pymonad" class="bare">https://github.com/jasondelaat/pymonad</a></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">PyMonad est une implémentation de structures de données monadiques en Python basée sur des langages de programmation tels que Haskell et F# avec des implémentations pour les types de monades les plus couramment utilisés en programmation fonctionnelle. <a href="https://www.miguelfarrajota.com/2021/06/monads-in-python-with-pymonad/">article</a></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">PyFunctional</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/EntilZha/PyFunctional/" class="bare">https://github.com/EntilZha/PyFunctional/</a></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">PyFunctional est une bibliothèque Python pour la programmation fonctionnelle qui fournit des outils pour travailler avec des fonctions pures et des itérables.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Toolz</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://toolz.readthedocs.io/en/latest/" class="bare">https://toolz.readthedocs.io/en/latest/</a></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Toolz est une bibliothèque Python pour la programmation fonctionnelle qui fournit des outils pour travailler avec des fonctions pures et des itérables.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Fn.py</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/kachayev/fn.py" class="bare">https://github.com/kachayev/fn.py</a></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Fn.py est une bibliothèque Python pour la programmation fonctionnelle qui fournit des outils pour travailler avec des fonctions pures et des itérables.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Coconut</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://coconut-lang.org/" class="bare">https://coconut-lang.org/</a></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Coconut ajoute plusieurs fonctionnalités à Python pour la programmation fonctionnelle, y compris le pattern matching. <a href="https://stackoverflow.com/questions/11909681/are-there-pattern-matching-functions-in-python-like-this">conversation sof</a></p></td> </tr> </tbody> </table> <div class="sect2"> <h3 id="_side_effects">side effects</h3> </div> <div class="sect2"> <h3 id="_loops">loops</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-python" data-lang="python"># impérative way result = [] for i in inputs: x = f(g(i)) result.append(x) # idiomatic way result = map(comp(f,g), inputs)</code></pre> </div> </div> </div> </div> </div> https://pages-content.github.io//blog/2023/0065_training_web_dev_post.html Thu, 24 Aug 2023 00:00:00 +0000 blog/2023/0065_training_web_dev_post.html https://pages-content.github.io//blog/2023/0064_training_trading_card_games_post.html Mon, 21 Aug 2023 00:00:00 +0000 blog/2023/0064_training_trading_card_games_post.html https://pages-content.github.io//blog/2023/0063_memo_ts_post.html Sat, 19 Aug 2023 00:00:00 +0000 blog/2023/0063_memo_ts_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>github repository: <a href="https://github.com/cheroliv/ts-codebase" target="_blank" rel="noopener">ts-codebase</a></p> </div> </div> </div> <div class="sect1"> <h2 id="toc_ts"><span class="underline">Intro typescript</span></h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><a href="#ts_types">Les types en typescript</a></p> </li> <li> <p><a href="#fonctions">Fonctions</a></p> </li> <li> <p><a href="#data_struct">Structure de données</a></p> </li> <li> <p><a href="#enums_tuples">Enums et tuples</a></p> </li> <li> <p><a href="#void_never">Void et Never</a></p> </li> <li> <p><a href="#class_interface">Classes et interfaces</a></p> </li> <li> <p><a href="#tsconfig">Le fichier tsconfig.json</a></p> </li> <li> <p><a href="#modules">Modules</a></p> </li> <li> <p><a href="#promesses">Promesses</a></p> </li> <li> <p><a href="#async-await">async/await</a></p> </li> <li> <p><a href="#generiques">Génériques</a></p> </li> </ol> </div> <div class="paragraph"> <p>index.html</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta http-equiv="X-UA-Compatible" content="ie=edge" /> <title>Document</title> </head> <body> Intro typescript <script src="01_types.js"></script> <script src="02_data_structure.js"></script> <script src="03_enums_tuples.js"></script> </body> </html></code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="ts_types">Les types en typescript</h2> <div class="sectionbody"> <div class="paragraph"> <p>01_types.ts</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">/** * Les types en typescript */ //quand le type n'est pas defini des le debut, // alors il est réassignable // c'est le type Any qui est attribué par défaut let my_var; my_var = "username"; console.assert(my_var === "username"); my_var = 11; console.assert(my_var === 11); my_var = true; console.assert(my_var === true); let age = 1; console.assert(age === 1); age = 2; // age="trois" c'est impossible // car l'inference de type a attribué le type number console.assert(age === 2); // Déclaration explicite de type let pi: Number = 3.14; console.assert(typeof pi === "number");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="fonctions">Fonctions</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les fonctions sont des blocs de code réutilisables.</p> </div> <div class="paragraph"> <p>Exemple de cote :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">const add = (a: number, b: number): number => a + b;</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="data_struct">Structure de données</h2> <div class="sectionbody"> <div class="paragraph"> <p>02_data_structure.ts</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">/*** * Structure de données: * Avec le type any on peut changer * le type de la variable à tout instruction * Lorsque l'on fixe le type * alors il n'est plus possible de le changer * lors d'une assignation */ // Arrays let buddies: any[] = [ "cheroliv", "imrandeh", "issoudeh", "soumi92" ] console.assert(buddies[0] === "cheroliv"); console.assert(buddies[1] === "imrandeh"); console.assert(buddies[2] === "issoudeh"); console.assert(buddies[3] === "soumi92"); // Déclaré en type any, l'inference de type // a bien réaligné en type string console.assert(typeof buddies[0] === "string"); console.assert(typeof buddies[1] === "string"); console.assert(typeof buddies[2] === "string"); console.assert(typeof buddies[3] === "string"); let writers: (String | String | String | Number)[][] = [ ["Chrétien", "de Troyes", "fr", 12], ["François", "Rabelais", "fr", 16], ["René", "Descartes", "fr", 17], ["Jean-Jacques", "Rousseau", "fr", 18], ["Georg", "Hegel", "de", 19], ["Karl", "Marx", "de", 19], ["Friedrich", "Engels", "de", 19], ["Victor", "Hugo", "fr", 19], ["Paul", "Verlaine", "fr", 19], ["Arthur", "Rimbaud", "fr", 19], ["Gérard", "de Nerval", "fr", 19], ["Georg", "Lukacs", "hu", 20], ["Franz", "Kafka", "hu", 20], ["Antonio", "Gramsci", "it", 20], ["Domenico","Losurdo","it",20], ]; // console.table(writers); // Objects let author: { first_name: String, last_name: String, lang: String, century: Number } = { // slice(-1) renvoie le dernier élèment first_name: writers.slice(-1)[0][0] as String, last_name: writers.slice(-1)[0][1] as String, lang: writers.slice(-1)[0][2] as String, century: writers.slice(-1)[0][3] as Number, } // assertion sur la valeur en accés par encapsulation(dot) console.assert(author.first_name === "Antonio") console.assert(author.last_name === "Gramsci") console.assert(author.lang === "it") console.assert(author.century === 20); // assertion sur le type en accès par index console.assert(typeof author["first_name"] === "string") console.assert(typeof author["last_name"] === "string") console.assert(typeof author["lang"] === "string") console.assert(typeof author["century"] === "number");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="enums_tuples">Enums et tuples</h2> <div class="sectionbody"> <div class="paragraph"> <p>03_enums_tuples.ts</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">/** * Enums et Tuples * * Enum: il existe les enums numérique * et les enums chaine de caracteres. * * Tuple: similaire aux arrays mais ne peut * contenir qu'une valeur de type spécifié. * */ //Enum numérique // l'index par de debut défaut est 0 // ici on le place a 1 enum Week { Monday = 1, Tuesday = 2, Wednesday = 3, Thursday = 4, Friday = 5, Saturday = 6, Sunday = 7, }; console.assert(Week.Monday == 1); console.assert(Week.Tuesday == 2); console.assert(Week.Wednesday == 3); console.assert(Week.Thursday == 4); console.assert(Week.Friday == 5); console.assert(Week.Saturday == 6); console.assert(Week.Sunday == 7); console.assert(Week[1] === "Monday"); console.assert(Week[2] === "Tuesday"); console.assert(Week[3] === "Wednesday"); console.assert(Week[4] === "Thursday"); console.assert(Week[5] === "Friday"); console.assert(Week[6] === "Saturday"); console.assert(Week[7] === "Sunday"); let motd_arr_fr: String[] = [ "Associé à la Lune", "Du dieu Tiw, associé à Mars", "Du dieu germanique Odin", "Du dieu germanique du tonnerre Thor", "De la déesse germanique Frigga associée à Vénus", "Associé à Saturne", "Associé au Soleil", ]; let motd_arr_en: String[] = [ "associated with the Moon", "from the god Tiw, associated with Mars", "from Germanic god Odin", "from Germanic god of thunder Thor", "from Germanic goddess Frigga associated with Venus", "associated with Saturn", "associated with the Sun", ]; // Un tuple (triple) let monday_triple_fr: [ Number, String, String ] = [ Week.Monday, Week[Week.Monday], motd_arr_fr[0], ]; console.assert(monday_triple_fr[0] === 1); console.assert(monday_triple_fr[1] === "Monday"); console.assert(monday_triple_fr[2] === "Associé à la Lune"); let monday_triple_en: [ Number, String, String ] = [ Week.Monday, Week[Week.Monday], motd_arr_en[0], ]; console.assert(monday_triple_en[0] === 1); console.assert(monday_triple_en[1] === "Monday"); console.assert(monday_triple_en[2] === "associated with the Moon"); // On se fait un type pour ajouter le nom de la langue type Meaning_of_the_day = { lang: String, meaning: (Week | String)[][], }; //fonction d'affichage du type Meaning_of_the_day const display_motd = (motd: Meaning_of_the_day) => { motd.meaning.forEach(day => console.table(`${Week[day[0] as Week]}: ${day[1]}.(${motd.lang})`) ) }; //fonction d'assertion sur le type Meaning_of_the_day // afin de verifier la concordance du contenu avec // motd_arr_#lang# const test_motd = ( motd: Meaning_of_the_day, motd_arr: String[] ) => { console.assert(motd.lang.length === 2) for (const [i, value] of motd.meaning.entries()) { console.assert(value[1] === motd_arr[i]); } }; let motd_fr: Meaning_of_the_day = { lang: "fr", meaning: [ [Week.Monday, motd_arr_fr[0]], [Week.Tuesday, motd_arr_fr[1]], [Week.Wednesday, motd_arr_fr[2]], [Week.Thursday, motd_arr_fr[3]], [Week.Friday, motd_arr_fr[4]], [Week.Saturday, motd_arr_fr[5]], [Week.Sunday, motd_arr_fr[6]], ], } console.log("---------"); console.log("display_motd(motd_fr):"); display_motd(motd_fr); test_motd(motd_fr, motd_arr_fr) let motd_en: Meaning_of_the_day = { lang: "en", meaning: [ [Week.Monday, motd_arr_en[0]], [Week.Tuesday, motd_arr_en[1]], [Week.Wednesday, motd_arr_en[2]], [Week.Thursday, motd_arr_en[3]], [Week.Friday, motd_arr_en[4]], [Week.Saturday, motd_arr_en[5]], [Week.Sunday, motd_arr_en[6]], ], } console.log("---------"); console.log("display_motd(motd_en):"); display_motd(motd_en); console.log("---------"); test_motd(motd_en, motd_arr_en); // Un tuple (triple) utilisant le type // Meaning_of_the_day pour peupler le meaning let motd_triple: [ Number, String, String ] = [ Week.Monday, Week[Week.Monday], motd_fr.meaning[0][1] as String ]; console.assert(motd_triple[0] === 1); console.assert(motd_triple[1] === "Monday"); console.assert(motd_triple[2] === "Associé à la Lune");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="void_never">Void et Never</h2> <div class="sectionbody"> <div class="paragraph"> <p>04_void_never_types.ts</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">// Le type void est l'opposé du type any // c'est l'absence de type. function verify_writers_length(): void { console.assert(writers.length > 0); } verify_writers_length(); const verify_writers_length_arrow = (): void => console.assert(writers.length > 0); verify_writers_length_arrow(); //Type of et never let value = 30; console.assert(typeof value === "number"); //never: qqchs qui n'arrive jamais function foo(x: String | Number): Boolean { if (typeof x === "string") { return true; } else if (typeof x === "number") { return false; } return fail("Error!") } function fail(message: String): never { throw new Error(message as string); }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="class_interface">Classes et interfaces</h2> <div class="sectionbody"> <div class="paragraph"> <p>04_void_never_types.ts</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">/** * Les classes: * members, * visibility, * nommage, * accesseurs * scope identifier: static,private,protected * * convention de nommage : * Les membres private sont préfixés avec un _ * */ class Member { username: String = ""; email: String = ""; private _password: String = ""; readonly signup_date: Date = new Date(Date.now()); constructor(username: String, email: String) { this.username = username; this.email = email; } get password(): String { return this._password; } set password(new_password: String) { this._password = new_password; } /** * Une fonction static qui initilise un member, * à partir d'un author */ static fromAuthor(author: { first_name: String, last_name: String, lang: String, century: Number }): Member { return new Member( `${author.first_name}.${author.last_name}`, `${author.first_name}.${author.last_name}@acme.com`, ); } }; let domenico = Member.fromAuthor(author); domenico.password = "test"; console.assert(domenico.email === "Domenico.Losurdo@acme.com"); console.assert(domenico.password === "test"); // Héritage enum Forms { Undefined = 0, Polygones = 1, Circle = 2, Straight = 3, Segment = 4, }; class Form { type: Forms = Forms.Undefined; }; class Rectangle extends Form { h: Number = 0; w: Number = 0; }; class Square extends Rectangle { side: Number = 0; }; /** * Interface donne un contrat à un type. * Les interfaces permettent de définir la structure d'un objet. */ interface IPerson { username: String; email: String; readonly signup_date: Date; } const user1: IPerson = { username: Member.fromAuthor(author)["username"], email: Member.fromAuthor(author)["email"], signup_date: Member.fromAuthor(author)["signup_date"], }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="tsconfig">Le fichier tsconfig.json</h2> <div class="sectionbody"> <div class="paragraph"> <p>tsconfig.json</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-json" data-lang="json">{ /* Visit https://aka.ms/tsconfig to read more about this file */ "compileOnSave": true, "compilerOptions": { "target": "es2016", "module": "CommonJS", "noEmitOnError": true, "strict": true, "noImplicitAny": true, "esModuleInterop": true } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="modules">Modules</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les modules permettent d’organiser le code en plusieurs fichiers.</p> </div> <div class="paragraph"> <p>Exemple de cote :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">// Dans un fichier math.ts export const add = (a: number, b: number): number => a + b; // Dans un autre fichier import { add } from './math'; let result = add(2, 3);</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="promesses">Promesses</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les promesses sont utilisées pour effectuer des opérations asynchrones.</p> </div> <div class="paragraph"> <p>Exemple de cote :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">const promise = new Promise<string>((resolve) => { // Code asynchrone ici resolve("Succès"); }); promise.then((result) => { console.log(result); });</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="async-await">async/await</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’async/await simplifie la gestion des promesses.</p> </div> <div class="paragraph"> <p>Exemple de cote :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">const fetchData = async (): Promise<void> => { const result = await someAsyncFunction(); console.log(result); };</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_ts"><span class="underline">Intro typescript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="generiques">Génériques</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les génériques permettent de créer des composants réutilisables avec des types dynamiques.</p> </div> <div class="paragraph"> <p>Exemple de cote :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-typescript" data-lang="typescript">const identity = <T>(arg: T): T => arg; const output = identity<string>("hello"); console.log(output);</code></pre> </div> </div> </div> </div> https://pages-content.github.io//blog/2023/0062_memo_css_post.html Mon, 14 Aug 2023 00:00:00 +0000 blog/2023/0062_memo_css_post.html <div class="sect1"> <h2 id="toc">Table des matieres</h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><a href="#good_links">Bon liens</a></p> </li> <li> <p><a href="#repo">Répository et code sample</a></p> </li> <li> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </li> </ol> </div> <div class="sect2"> <h3 id="good_links">Bon liens</h3> <div class="paragraph"> <p><a href="#toc">Table des matieres</a></p> </div> </div> <div class="sect2"> <h3 id="repo">Répository et code sample</h3> <div class="paragraph"> <p>github repository: <a href="https://github.com/cheroliv/css-codebase" target="_blank" rel="noopener">css-codebase</a></p> </div> </div> <div class="sect2"> <h3 id="toc_début"><span class="underline">Début CSS</span></h3> <div class="olist arabic"> <ol class="arabic"> <li> <p><a href="#début_intro">Intro & Mise en place</a></p> </li> <li> <p><a href="#début_texts">Les textes</a></p> </li> <li> <p><a href="#début_background">Background</a></p> </li> <li> <p><a href="#début_boxes">Les boites (boxes)</a></p> </li> <li> <p><a href="#début_flexbox">Flexbox</a></p> </li> <li> <p><a href="#début_grid">Grid</a></p> </li> <li> <p><a href="#début_abs_pos">Position absolute</a></p> </li> <li> <p><a href="#début_responsive">Le responsive</a></p> </li> <li> <p><a href="#début_conclusion">Débug & Conclusion</a></p> </li> </ol> </div> <div class="paragraph"> <p><a href="#toc">Table des matieres</a></p> </div> </div> </div> </div> <div class="sect1"> <h2 id="début_intro">Intro & Mise en place</h2> <div class="sectionbody"> <div class="paragraph"> <p>Intro basé sur cette vidéo:</p> </div> <div class="videoblock"> <div class="content"> <iframe src="https://www.youtube.com/embed/iSWjmVcfQGg?rel=0" frameborder="0" allowfullscreen></iframe> </div> </div> <div class="paragraph"> <p>github repository: <a href="https://github.com/cheroliv/css-codebase/début_css/" target="_blank" rel="noopener">début css</a></p> </div> <div class="paragraph"> <p>memo source:<br> index.html</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Cours CSS</title> <link rel="stylesheet" href="style.css" /> </head> <body> <header> <h1>Les bases de CSS</h1> </header> <main> <div class="flexbox"> <h2>Flexbox</h2> <ul> <li>boite 1</li> <li>boite 2</li> <li>boite 3</li> </ul> </div> <div class="grid"> <h2>Grid</h2> <div class="grid-container"> <img src="./assets/img/css-logo.png" alt="logo css" /> <form action=""> <input type="text" id="firstname" placeholder="Prénom" /> <input type="text" id="surname" placeholder="Nom" /> <textarea cols="30" rows="10" placeholder="Ici votre message" ></textarea> <input type="submit" value="Valider" id="btn-submit" /> </form> </div> </div> <div class="absolute"> <h2>Absolute</h2> <span id="circle1"></span> <span id="circle2"></span> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p>Relier le fichier style.css à la page html:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"></head> <link rel="stylesheet" href="style.css" /> </head></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_texts">Les textes</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">/* import remote de font sur l'ensemble de la feuille*/ @import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); /* import local de font */ @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } /* body est le parent de toutes les balises, qu'il contient, donc je le déclare avant, pour la logique de précédence de parent */ body { /* si DMSerif n'est pas trouvé alors il se rabat sur Verdana*/ font-family: "DMSerif", Verdana; } /* va styliser toutes les balises h1, celles de body sont surchargés, par la déclaration présente */ h1 { text-transform: uppercase; /* espacement entre les lettres en pixel*/ letter-spacing: 3px; /* alignement du texte*/ text-align: center; /* Les tailles de polices doivent être en REM (rem = root em). Le REM se base pas sur l'élément parent pour obtenir sa taille mais sur l'élément racine. Ainsi 1rem prendra sa valeur de la font-size de votre document (body ou html).*/ font-size: 2.5rem; /* ombrage du texte */ text-shadow: 3px /* offset-x */ 3px /* offset-y */ 8px /* blur-radius */ #00000042/* color */; /* couleur du texte */ color: #ab0ef4; /*attibuer les polices(font): liste, ordonnée par priorité, de polices à utiliser pour mettre en forme le texte de l'élément ciblé.*/ font-family: "Oswald", sans-serif; /* surligner le text*/ text-decoration: underline; }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_background">Background</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } body { font-family: "DMSerif", Verdana; /* image comme background*/ background: url(./assets/img/bg.jpg) center/cover; /* 100VH = 100% de la taille de l'écran (viewport height) min afin de ne pas bloquer la possibilité d'avoir un plus grand */ min-height: 100vh; } h1 { text-transform: uppercase; letter-spacing: 3px; text-align: center; font-size: 2.5rem; text-shadow: 3px 3px 8px #00000042; color: #ab0ef4; font-family: "Oswald", sans-serif; text-decoration: underline; }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_boxes">Les boites (boxes)</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } /* *: létoile donne du style a tous les éléments. Ensuite remettre un à un les parametres par defaut afin d'eviter les stylisation inattendu.*/ * { /* surcharge de base tous les elements à padding 0*/ margin: 0; /* surcharge de base tous les elements à padding 0*/ padding: 0; } body { font-family: "DMSerif", Verdana; /* image comme background*/ background: url(./assets/img/bg.jpg) center/cover; min-height: 100vh; } h1 { text-transform: uppercase; letter-spacing: 3px; text-align: center; font-size: 2.5rem; text-shadow: 3px 3px 8px #00000042; color: #ab0ef4; font-family: "Oswald", sans-serif; text-decoration: underline; } main { background: rgba(245, 245, 245, 0.9); min-height: 500px; /* quelque soit la taille de l'écran, la boite fait toujours 90% de la taille de la page, les 10% restant sont une marge à droite, pour avoir 5% de chaque coté on ajoute une margin, tel que [0, auto]*/ width: 90%; /* haut bas prend 0, et gauche droite prend auto(center cad meme de chaque cotés)*/ margin: 0 auto; /* on ajoute des bords a notre boite*/ border: 2px solid rgb(0, 140, 255); /* on arrondis les coins de la boite*/ border-radius: 20px 20px 0 0; /* ombrage sur la boite*/ box-shadow: 0px 0px 20px 4px #81cfc6; /* marge interrieure de la boite sur tous les cotés*/ padding: 15px; } h2 { /* afin de recuprer le comportement par defaut qui a ete surchargé par l'operateur étoile*/ margin: 0; }</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Cours CSS</title> <link rel="stylesheet" href="style.css" /> </head> <body> <header> <h1>Les bases de CSS</h1> </header> <main> <div class="flexbox"> <h2>Flexbox</h2> <ul> <li>boite 1</li> <li>boite 2</li> <li>boite 3</li> </ul> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_flexbox">Flexbox</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } body { font-family: "DMSerif", Verdana; background: url(./assets/img/bg.jpg) center/cover; min-height: 100vh; } h1 { text-transform: uppercase; letter-spacing: 3px; text-align: center; font-size: 2.5rem; text-shadow: 3px 3px 8px #00000042; color: #ab0ef4; font-family: "Oswald", sans-serif; text-decoration: underline; } main { background: rgba(245, 245, 245, 0.9); min-height: 500px; width: 90%; margin: 0 auto; border: 2px solid rgb(0, 140, 255); border-radius: 20px 20px 0 0; box-shadow: 0px 0px 20px 4px #81cfc6; padding: 15px; } h2 { margin: 0; } /* le point permet d'acceder à la classe d'un composant*/ .flexbox { border: 2px solid skyblue; border-radius: 10px; padding: 10px; margin-top: 20px; min-height: 150px; } /* FLEXBOX */ /* Sert à répartir équitablement des éléments sur la page */ .flexbox ul { padding: 0; /* aligne les éléments enfants de ul(les li)*/ display: flex; /* reparti convenablement(équitablement les li sur la page) */ justify-content: space-around; } /* ce style concerne les li de la classe, flexbox des balises qui y font referencent*/ .flexbox li { /* suprime les boules des éléments de la list li*/ list-style: none; height: 160px; width: 160px; margin: 10px; background: turquoise; /* Centrer un unique élément verticalement et horizontalement */ display: flex; justify-content: center; align-items: center; }</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Cours CSS</title> <link rel="stylesheet" href="style.css" /> </head> <body> <header> <h1>Les bases de CSS</h1> </header> <main> <div class="flexbox"> <h2>Flexbox</h2> <ul> <li>boite 1</li> <li>boite 2</li> <li>boite 3</li> </ul> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_grid">Grid</h2> <div class="sectionbody"> <div class="paragraph"> <p>Pour répartir des éléments de maniere un peu plus complexe qu’avec les flexbox, avec un systeme de grille entre autres.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } body { font-family: "DMSerif", Verdana; background: url(./assets/img/bg.jpg) center/cover; min-height: 100vh; } h1 { text-transform: uppercase; letter-spacing: 3px; text-align: center; font-size: 2.5rem; text-shadow: 3px 3px 8px #00000042; color: #ab0ef4; font-family: "Oswald", sans-serif; text-decoration: underline; } main { background: rgba(245, 245, 245, 0.9); min-height: 500px; width: 90%; margin: 0 auto; border: 2px solid rgb(0, 140, 255); border-radius: 20px 20px 0 0; box-shadow: 0px 0px 20px 4px #81cfc6; padding: 15px; } h2 { margin: 0; } .flexbox, .grid { border: 2px solid skyblue; border-radius: 10px; padding: 10px; margin-top: 20px; min-height: 150px; } .flexbox ul { padding: 0; display: flex; justify-content: space-around; } .flexbox li { list-style: none; height: 160px; width: 160px; margin: 10px; background: turquoise; display: flex; justify-content: center; align-items: center; } /* GRID */ .grid-container { display: grid; /* séparatuion de la grille en deux(à ses deux enfants), avec à gauche 30% pour l'image et à droite 70% pour le formulaire*/ grid-template-columns: 30% 70%; } /* sizing de l'image css-logo contenu dans la classe grid qui est dans le parent grid-container*/ .grid img { /* l'image remplt 80% de part de grille*/ width: 80%; margin: 20px auto; display: block; } form { display: grid; /* deux colonnes de chacune 1 fraction*/ grid-template-columns: 1fr 1fr; /* trois rangés de chacune 1 fraction*/ grid-template-rows: 1fr 1fr 1fr; /* structuration sous forme de template de notre repartition des composants enfants de la forme*/ grid-template-areas: "i1 i2"/* i1: input1, i2:input2*/ "ta ta"/*ta: text area */ "vi bt"/*vi:, bt: bouton */; } /* on donne du style sur deux éléments en meme temps en les listant avant les parentheses*/ input, textarea { margin: 5px; border: 1px solid darkblue; padding: 10px; font-size: 1.1rem; font-family: "DMSerif"; border-radius: 5px; } /* donner du style uniquement la textearea*/ textarea { /* renseigner le nommage pour le grid template area*/ grid-area: ta; height: 40px; /* empeche le cassage du style de la page en empechant le resizing de la textarea du formulaire*/ resize: none; } /* pour pointer un id d'élément html on utilise la notation préfixe # */ #btn-submit { /* renseigner le nommage*/ grid-area: bt; /* change le le symbole de curseur souris quand il survole sur le bouton*/ cursor: pointer; background: cyan; transition: 0.2s; } /* au survole(hover) de la souris le bouton change de comportement*/ #btn-submit:hover { background: darkblue; /* couleur de text du bouton devient blanc*/ color: white; }</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Cours CSS</title> <link rel="stylesheet" href="style.css" /> </head> <body> <header> <h1>Les bases de CSS</h1> </header> <main> <div class="flexbox"> <h2>Flexbox</h2> <ul> <li>boite 1</li> <li>boite 2</li> <li>boite 3</li> </ul> </div> <div class="grid"> <h2>Grid</h2> <div class="grid-container"> <img src="./assets/img/css-logo.png" alt="logo css" /> <form action=""> <input type="text" id="firstname" placeholder="Prénom" /> <input type="text" id="surname" placeholder="Nom" /> <textarea cols="30" rows="10" placeholder="Ici votre message"></textarea> <input type="submit" value="Valider" id="btn-submit" /> </form> </div> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_abs_pos">Position absolute</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } body { font-family: "DMSerif", Verdana; background: url(./assets/img/bg.jpg) center/cover; min-height: 100vh; } h1 { text-transform: uppercase; letter-spacing: 3px; text-align: center; font-size: 2.5rem; text-shadow: 3px 3px 8px #00000042; color: #ab0ef4; font-family: "Oswald", sans-serif; text-decoration: underline; } main { background: rgba(245, 245, 245, 0.9); min-height: 500px; width: 90%; margin: 0 auto; border: 2px solid rgb(0, 140, 255); border-radius: 20px 20px 0 0; box-shadow: 0px 0px 20px 4px #81cfc6; padding: 15px; } h2 { margin: 0; } .flexbox, .grid, .absolute { border: 2px solid skyblue; border-radius: 10px; padding: 10px; margin-top: 20px; min-height: 150px; } .flexbox ul { padding: 0; display: flex; justify-content: space-around; } .flexbox li { list-style: none; height: 160px; width: 160px; margin: 10px; background: turquoise; display: flex; justify-content: center; align-items: center; } .grid-container { display: grid; grid-template-columns: 30% 70%; } .grid img { width: 80%; margin: 20px auto; display: block; } form { display: grid; grid-template-columns: 1fr 1fr; grid-template-rows: 1fr 1fr 1fr; grid-template-areas: "i1 i2" "ta ta" "vi bt"; } input, textarea { margin: 5px; border: 1px solid darkblue; padding: 10px; font-size: 1.1rem; font-family: "DMSerif"; border-radius: 5px; } textarea { grid-area: ta; height: 40px; resize: none; } #btn-submit { grid-area: bt; cursor: pointer; background: cyan; transition: 0.2s; } #btn-submit:hover { background: darkblue; color: white; } /* ABSOLUTE */ /* Sans élément en Relative, de base, l'élément en absolute l'est par rapport au Body */ /* Il faut mettre une position relative au parent pour contraindre l'élément en absolute dans ses frontières */ .absolute { /* position relative par rapport à son parent, donc contenu dans les frontieres de son parents*/ position: relative; } #circle1 { height: 80px; width: 80px; background: skyblue; position: absolute; border-radius: 150px; top: -20px; right: -20px; } #circle2 { height: 40px; width: 40px; border-radius: 150px; background: teal; position: absolute; left: 50%; transform: /*traslate de 50% de la taille du cercle, pour etre centré par rapport au centre du cercle, plutot que sur son bord gauche par défaut.*/ translateX(-50%); top: 100px; }</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Cours CSS</title> <link rel="stylesheet" href="style.css" /> </head> <body> <header> <h1>Les bases de CSS</h1> </header> <main> <div class="flexbox"> <h2>Flexbox</h2> <ul> <li>boite 1</li> <li>boite 2</li> <li>boite 3</li> </ul> </div> <div class="grid"> <h2>Grid</h2> <div class="grid-container"> <img src="./assets/img/css-logo.png" alt="logo css" /> <form action=""> <input type="text" id="firstname" placeholder="Prénom" /> <input type="text" id="surname" placeholder="Nom" /> <textarea cols="30" rows="10" placeholder="Ici votre message"></textarea> <input type="submit" value="Valider" id="btn-submit" /> </form> </div> </div> <div class="absolute"> <h2>Absolute</h2> <span id="circle1"></span> <span id="circle2"></span> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_responsive">Le responsive</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@500&display=swap"); @font-face { font-family: "DMSerif"; src: url(./assets/fonts/DMSerifDisplay-Regular.ttf); } body { font-family: "DMSerif", Verdana; background: url(./assets/img/bg.jpg) center/cover; min-height: 100vh; } h1 { text-transform: uppercase; letter-spacing: 3px; text-align: center; /* pour etre plus responsive on peut passer la taille en vw(view port width) pour qu'elle s'adapte à la taille de l'ecran*/ font-size: 2.5rem; text-shadow: 3px 3px 8px #00000042; color: #ab0ef4; font-family: "Oswald", sans-serif; text-decoration: underline; } main { background: rgba(245, 245, 245, 0.9); min-height: 500px; width: 90%; margin: 0 auto; border: 2px solid rgb(0, 140, 255); border-radius: 20px 20px 0 0; box-shadow: 0px 0px 20px 4px #81cfc6; padding: 15px; } h2 { margin: 0; } .flexbox, .grid, .absolute { border: 2px solid skyblue; border-radius: 10px; padding: 10px; margin-top: 20px; min-height: 150px; } .flexbox ul { padding: 0; display: flex; justify-content: space-around; } .flexbox li { list-style: none; height: 160px; width: 160px; margin: 10px; background: turquoise; display: flex; justify-content: center; align-items: center; } .grid-container { display: grid; grid-template-columns: 30% 70%; } .grid img { width: 80%; margin: 20px auto; /* permet en media query de la centrer en petit écran*/ display: block; } form { display: grid; grid-template-columns: 1fr 1fr; grid-template-rows: 1fr 1fr 1fr; grid-template-areas: "i1 i2" "ta ta" "vi bt"; } input, textarea { margin: 5px; border: 1px solid darkblue; padding: 10px; font-size: 1.1rem; font-family: "DMSerif"; border-radius: 5px; } textarea { grid-area: ta; height: 40px; resize: none; } #btn-submit { grid-area: bt; cursor: pointer; background: cyan; transition: 0.2s; } #btn-submit:hover { background: darkblue; color: white; } .absolute { position: relative; } #circle1 { height: 80px; width: 80px; background: skyblue; position: absolute; border-radius: 150px; top: -20px; right: -20px; } #circle2 { height: 40px; width: 40px; border-radius: 150px; background: teal; position: absolute; left: 50%; transform: translateX(-50%); top: 100px; } /* RESPONSIVE: a partir des tailles d'ecran permet de surcharger les reglages definis plus haut */ @media screen and (max-width: 900px) { .grid-container { display: block; } .grid-container img { width: 40%; } } @media screen and (max-width: 610px) { .flexbox ul { flex-direction: column; align-items: center; } form { grid-template-columns: 1fr; grid-template-rows: 1fr; grid-template-areas: "i1" "i2" "ta" "bt"; } input, textarea { font-size: 0.8rem; } }</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Cours CSS</title> <link rel="stylesheet" href="style.css" /> </head> <body> <header> <h1>Les bases de CSS</h1> </header> <main> <div class="flexbox"> <h2>Flexbox</h2> <ul> <li>boite 1</li> <li>boite 2</li> <li>boite 3</li> </ul> </div> <div class="grid"> <h2>Grid</h2> <div class="grid-container"> <img src="./assets/img/css-logo.png" alt="logo css" /> <form action=""> <input type="text" id="firstname" placeholder="Prénom" /> <input type="text" id="surname" placeholder="Nom" /> <textarea cols="30" rows="10" placeholder="Ici votre message"></textarea> <input type="submit" value="Valider" id="btn-submit" /> </form> </div> </div> <div class="absolute"> <h2>Absolute</h2> <span id="circle1"></span> <span id="circle2"></span> </div> </main> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="début_conclusion">Débug & Conclusion</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-css" data-lang="css">/* all elements: supprime les comportements par défaut*/ * { /* les marges à zéro*/ margin: 0; /* les parge internes(padding) à zéro*/ padding: 0; /* tous les bords avec un cadre rouge de 2px. qui est ou et qui fait quoi...*/ border: 2px solid red; }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_début"><span class="underline">Début CSS</span></a></p> </div> </div> </div> https://pages-content.github.io//blog/2023/0061_memo_html_post.html Sun, 13 Aug 2023 00:00:00 +0000 blog/2023/0061_memo_html_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_bon_liens">1. Bon liens</a></li> <li><a href="#_répository_et_code_sample">2. Répository et code sample</a></li> </ul> </div> <div class="sect1"> <h2 id="_bon_liens">1. Bon liens</h2> <div class="sectionbody"> <div class="ulist"> <div class="title">html</div> <ul> <li> <p><a href="https://htmlcheatsheet.com" target="_blank" rel="noopener">htmlcheatsheet.com</a>: HTML Cheatsheet</p> </li> </ul> </div> <div class="ulist"> <div class="title">font</div> <ul> <li> <p><a href="https://fontawesome.com" target="_blank" rel="noopener">fontawesome.com</a>: bibliothèque d’icones</p> </li> <li> <p><a href="https://www.toptal.com/designers/htmlarrows/symbols/" target="_blank" rel="noopener">toptal.com/designers/htmlarrows/symbols</a>: Icones natives en HTML</p> </li> </ul> </div> <div class="ulist"> <div class="title">caractères spéciaux et échappements</div> <ul> <li> <p><a href="https://www.sonarsource.com/blog/encoding-differentials-why-charset-matters/" class="bare">https://www.sonarsource.com/blog/encoding-differentials-why-charset-matters/</a></p> </li> <li> <p><a href="https://stackoverflow.com/a/3614344/13104550" class="bare">https://stackoverflow.com/a/3614344/13104550</a></p> </li> <li> <p><a href="https://html.spec.whatwg.org/multipage/named-characters.html" class="bare">https://html.spec.whatwg.org/multipage/named-characters.html</a></p> </li> </ul> </div> <div class="paragraph"> <p><a href="#toc">[toc]</a></p> </div> </div> </div> <div class="sect1"> <h2 id="_répository_et_code_sample">2. Répository et code sample</h2> <div class="sectionbody"> <div class="paragraph"> <p>github repository: <a href="https://github.com/cheroliv/html-codebase" target="_blank" rel="noopener">html-codebase</a></p> </div> <div class="paragraph"> <p>memo source:<br> index.html</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlightjs highlight"><code class="language-html hljs" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <!-- Le titre de la page --> <title>Cours HTML</title> <!-- Icone de l'onglet --> <link rel="shortcut icon" href="html-logo.png" /> <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.8.2/css/all.css" /> </head> <body> <header> <h1>Texte - Titre H1</h1> <p> <em>em pour mettre en italique</em>, <strong>strong pour mettre en gras</strong> <span>L'élement en span ne revient pas à la ligne</span>. </p> <p> Lorem ipsum dolor sit amet consectetur adipisicing elit. Exercitationem cumque ratione veniam officiis nulla a debitis at facilis sed dignissimos. </p> </header> <section> <div> <h2>Photo - Titre H2</h2> <img src="./img-1.jpg" alt="image-arbre" height="200" /> </div> <div> <h3>Liste - Titre H3</h3> <ul> <li>UL = unordered list</li> <li>UL = unordered list</li> <li>UL = unordered list</li> </ul> <ol> <li>OL = ordered list</li> <li>OL = ordered list</li> <li>OL = ordered list</li> </ol> </div> <div> <h4>Tableaux - Titre H4</h4> <table border="4" cellpadding="10" cellspacing="4" style="text-align: center"> <thead> <tr> <th>Col 1</th> <th>Col 2</th> <th>Col 3</th> </tr> </thead> <tbody> <tr> <td rowspan="2">Row 1 Cell 1</td> <td>Row 1 Cell 2</td> <td>Row 1 Cell 3</td> </tr> <tr> <td>Row 2 Cell 2</td> <td>Row 2 Cell 3</td> </tr> <tr> <td colspan="3">Row 3 Cell 1</td> </tr> </tbody> </table> </div> <div> <h5><span>♖</span> Liens - Titre H5</h5> <a href="https://htmlcheatsheet.com/" target="_blank">HTML Cheatsheet</a> <br /> <a href="https://www.toptal.com/designers/htmlarrows/symbols/" target="_blank">Icones natifs en HTML</a> </div> <div> <h6><i class="fas fa-video"></i> Vidéo - Titre H6</h6> <video src="video.mp4" height="150" autoplay loop muted></video> </div> </section> <br /> <!-- Formulaires en HTML --> <section> <h2>Formulaire</h2> <form action="/action.php" method="post"> <label for="name">Nom</label> <input id="name" type="text" placeholder="Entrez votre nom" /><br /> <label for="number">Entrez votre age</label> <input type="number" id="number-age" value="15" oninput="document.getElementById('range-age').value=this.value"> <input type="range" id="range-age" min="0" max="100" oninput="document.getElementById('number-age').value=this.value"><br /> <!-- Input select --> <label for="gender">Genre</label> <select id="gender"> <option selected="selected" value="Homme">Homme</option> <option value="Femme">Femme</option> </select><br /> <!-- Input radio --> <div> <input type="radio" name="type" id="human" checked /> <label for="human">Humain</label> <input type="radio" name="type" id="dog" /> <label for="dog">Chien</label> <input type="radio" name="type" id="cat" /> <label for="cat">Chat</label> </div> <textarea cols="20" rows="5" placeholder="Votre message..."></textarea><br /> <!-- Input Checkbox --> <label><input type="checkbox" />Accepter les CGV</label> <br /> <input type="submit" value="Submit" /> </form> </section> <br /> <!-- Mail & envoi de fichiers --> <footer> <a href="mailto:fs@gmail.com">Ecrivez-moi !</a> <br /> <a href="notice.txt" download="nom-du-fichier">Télécharger la notice</a> <details> <summary>Plus d'infos</summary> <p> Lorem ipsum dolor, sit amet consectetur adipisicing elit. Harum, repellendus. </p> </details> </footer> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">[toc]</a></p> </div> </div> </div> https://pages-content.github.io//blog/2023/0060_memo_js_post.html Fri, 4 Aug 2023 00:00:00 +0000 blog/2023/0060_memo_js_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p>github repository: <a href="https://github.com/cheroliv/js-codebase" target="_blank" rel="noopener">js-codebase</a></p> </div> </div> </div> <div class="sect1"> <h2 id="toc_js"><span class="underline">Intro Javascript</span></h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><a href="#start">Variables, opérateurs arithmétiques et chaines de caractères</a></p> </li> <li> <p><a href="#arrays">Les arrays</a></p> </li> <li> <p><a href="#functions">Les fonctions</a></p> </li> <li> <p><a href="#param_x_scope">Paramètres et scopes</a></p> </li> <li> <p><a href="#objects">Les objects</a></p> </li> <li> <p><a href="#loops">Les boucles</a></p> </li> <li> <p><a href="#const_var_let">Const, var et let</a></p> </li> <li> <p><a href="#rest_and_spread_operators">Rest et spread operators</a></p> </li> <li> <p><a href="#destructuring">Destructuring</a></p> </li> <li> <p><a href="#import_export">Import et export de modules</a></p> </li> <li> <p><a href="#classes">Utilisation des classes</a></p> </li> </ol> </div> <div class="paragraph"> <p>index.html</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-html" data-lang="html"><!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8"> <title>Document</title> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta http-equiv="X-UA-Compatible" content="ie=edge" /> </head> <body> index <script src="01_start.js"></script> <script src="02_arrays.js"></script> <script src="03_functions.js"></script> <script src="04_param_x_scope.js"></script> <script src="05_objects.js"></script> <script src="06_loops.js"></script> <script src="07_const_var_let.js"></script> <script src="08_rest_and_spread_operators.js"></script> <script src="09_destructuring.js"></script> <script src="10_module_import_export.js"></script> </body> </html></code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="start">Variables, opérateurs arithmétiques et chaines de caractères</h2> <div class="sectionbody"> <div class="paragraph"> <p>01_start.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Variables */ //une variable stupide var my_variable = "dummy variable"; console.log(my_variable); //assertion console.assert(my_variable === "dummy variable"); var username = "cheroliv"; console.log(username); console.assert(username === "cheroliv"); //concaténation de string console.assert(username === "cher" + "oliv"); /** * Opérateur arithmétique: + - * / % */ //integer var x = 10; var y = 5; var z = 20; console.log(x + y); console.assert(x + y === 15); console.log(x + y - z); console.assert(x + y - z === -5); console.log(x - y); console.assert(x - y === 5); console.log(x * y); console.assert(x * y === 50); console.log(x / y); console.assert(x / y === 2); console.log("---------"); x = 20; y = 10; console.log(x + y); console.assert(x + y === 30); console.log(x + y - z); console.assert(x + y - z === 10); console.log(x - y); console.assert(x - y === 10); console.log(x * y); console.assert(x * y === 200); console.log(x / z); console.assert(x / z === 1); //Littéraux de gabarits pour string avec backstick ` //Template literals (Template strings) console.assert(`typeof z: ${typeof z}` === "typeof z: number"); console.log(`x is type of : ${typeof x}`); console.log(`y is type of : ${typeof y}`); console.log(`z is type of : ${typeof z}`); //typeof: donne le type de la variable console.assert(typeof x === "number"); console.assert(typeof y === "number"); console.assert(typeof z === "number"); console.log("---------"); /** * Incrémenation/décrémentation */ //incrémantation/décrémentation préfixe console.log(++x) //incrémenté puis affiché: 21 console.log(x) //la valeur incrémenté: 21 //incrémantation/décrémentation suffixe console.log(y++) //affiche la valeur sans incrémenation puis incrémente: 10 console.log(y) //la valeur incrémenté: 11 //décrémentation x--; y--; console.assert(x === 20); console.assert(y === 10); /** * String: chaine de caractères */ console.log(`username: ${username}`); //taille de la string console.log(`username.length: ${username.length}`); console.assert(username.length === 8); console.assert(username.length === "cheroliv".length); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="arrays">Les arrays</h2> <div class="sectionbody"> <div class="paragraph"> <p>02_arrays.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Les arrays */ // auteurs [["nom ", "prénom", "pays"]] var writers = [ ["Karl", "Marx", "de"], ["Jean-Jacques", "Rousseau", "fr"], ["Victor", "Hugo", "fr"], ["René", "Descartes", "fr"], ["Paul", "Verlaine", "fr"], ["Antonio", "Gramsci", "it"], ["Georg", "Lukacs", "hu"], ["Franz", "Kafka", "hu"], ["Arthur", "Rimbaud", "fr"], ["Gérard", "de Nerval", "fr"], ["Chrétien", "de Troyes", "fr"], ["François", "Rabelais", "fr"], ["Georg", "Hegel", "de"], ["Friedrich", "Engels", "de"], ] console.table(writers); // accés aux élèments du tableau console.log(writers[0]); console.log(`${writers[0][0]}, ${writers[0][1]} (${writers[0][2]})`); console.assert("Karl, Marx (de)" === `${writers[0][0]}, ${writers[0][1]} (${writers[0][2]})`); //sauvegarder la valeur du prénom de Marx var karl = writers[0][0] //éditer un élement du tableau, le prénom de Marx writers[0][0] = "Karlito" console.log(`${writers[0][0]}, ${writers[0][1]} (${writers[0][2]})`); console.assert("Karlito, Marx (de)" === `${writers[0][0]}, ${writers[0][1]} (${writers[0][2]})`); console.assert("Karl" === karl); //remettre la valeur initale du prénom de Marx writers[0][0] = karl; console.assert(`${karl}, Marx (de)` === `${writers[0][0]}, ${writers[0][1]} (${writers[0][2]})`); console.log("---------"); /** * Arrays: map/forEach/pop/push/slice/sort/shift/unshift */ var numbers = [1, 5, 4, 3, 2]; console.log("Iterate with forEach"); // parcourir avec array.forEach numbers.forEach((it) => console.log(it)); console.log("---------"); console.log("Iterate with map"); // parcourir avec array.map numbers.map((it) => console.log(it)); console.log("---------"); //afficher les éléments sur une ligne //génère la string avec le formatage des nombres const numbersString = (numberArray) => { var consoleOutput = new String(); numberArray.forEach(number => consoleOutput += `${number}, `); return consoleOutput = consoleOutput.substring(0, consoleOutput.length - 2); }; //affiche la chaine entre crochets dans la console const displayNumbers = (numbersStr) => { console.log(`[${numbersString(numbersStr)}]`); }; console.log("orginal number array") displayNumbers(numbers); console.log("---------"); //push: ajoute à la fin console.log("push"); numbers.push(6); displayNumbers(numbers); console.log("---------"); //pop: suprime le dernier console.log("pop"); numbers.pop(); displayNumbers(numbers); console.log("---------"); //unshift: ajouter le parametre au debut de l'array console.log("unshift"); numbers.unshift(0); displayNumbers(numbers); console.log("---------"); //shift: supprime le premier element de l'array console.log("shift"); numbers.shift(); displayNumbers(numbers); console.log("---------"); //slice: renvoi l'array entre les positions en argument console.log("slice"); var sliceNumbersResult = numbers.slice(2, 4); displayNumbers(sliceNumbersResult); console.log("---------"); //sort asc console.log("sort asc"); var ascSort = numbers.sort((a, b) => a - b); displayNumbers(ascSort); console.log("---------"); //sort desc console.log("sort desc"); var descSort = numbers.sort((a, b) => b - a); displayNumbers(descSort); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="functions">Les fonctions</h2> <div class="sectionbody"> <div class="paragraph"> <p>03_functions.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Les fonctions */ //function style legacy function sayHelloWorldLegacy() { console.log("Hello world legacy!"); } sayHelloWorldLegacy(); function sayHelloLegacy(firstName, lastName, style) { console.log(`Hello ${firstName}, ${lastName} (${style})`); } sayHelloLegacy("Cher", "Oliv", "legacy"); console.log("---------"); //function style arrow const sayHelloWorld = () => console.log("Hello world!"); sayHelloWorld(); const sayHello = (firstName, lastName) => console.log(`Hello ${firstName}, ${lastName}`); sayHello("Cher", "Oliv"); console.log("---------"); var authors = [ ["Chrétien", "de Troyes", "fr"], ["François", "Rabelais", "fr"], ["René", "Descartes", "fr"], ["Jean-Jacques", "Rousseau", "fr"], ["Georg", "Hegel", "de"], ["Karl", "Marx", "de"], ["Friedrich", "Engels", "de"], ["Victor", "Hugo", "fr"], ["Paul", "Verlaine", "fr"], ["Antonio", "Gramsci", "it"], ["Georg", "Lukacs", "hu"], ["Franz", "Kafka", "hu"], ["Arthur", "Rimbaud", "fr"], ["Gérard", "de Nerval", "fr"], ] const displayAuthors = (authorsArray) => authorsArray.forEach(author => console.log(`${author[0]} ${author[1]}, (${author[2]})`) ); displayAuthors(authors); console.log("---------"); /** * valeur par défaut des parametres d'une fonctions */ const add = (a = 0, b = 0) => a + b; console.assert(add() === 0) console.assert(add(1) === 1) console.assert(add(1, 1) === 2) console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="param_x_scope">Paramètres et scopes</h2> <div class="sectionbody"> <div class="paragraph"> <p>04_param_x_scope.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">//global scope: visible partout, dans et hors functions var global; const foo = () => { //local scope: visible uniquement dans la fonction foo var bar = "bar" console.log(bar) } foo(); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="objects">Les objects</h2> <div class="sectionbody"> <div class="paragraph"> <p>05_objects.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Les objects */ var authors = [ ["Chrétien", "de Troyes", "fr"], ["François", "Rabelais", "fr"], ["René", "Descartes", "fr"], ["Jean-Jacques", "Rousseau", "fr"], ["Georg", "Hegel", "de"], ["Karl", "Marx", "de"], ["Friedrich", "Engels", "de"], ["Victor", "Hugo", "fr"], ["Paul", "Verlaine", "fr"], ["Antonio", "Gramsci", "it"], ["Georg", "Lukacs", "hu"], ["Franz", "Kafka", "hu"], ["Arthur", "Rimbaud", "fr"], ["Gérard", "de Nerval", "fr"], ]; var hugo = { firstName: authors[7][0], lastName: authors[7][1], country: authors[7][2], }; var book = { author: hugo, title: "Les misérables" }; console.log(hugo); console.log(book); //accéder à un membre de l'objet par point console.log(hugo.country); //accéder à un membre de l'objet par crochet console.log(book["title"]); console.log(book.author.lastName); console.log(book["author"]["firstName"]); //ajouter une clé a un objet hugo.gender = "non binary"; console.assert(hugo.gender === "non binary"); //mettre à jour une clé hugo.gender = "male"; console.assert(hugo.gender !== "non binary"); console.assert(hugo["gender"] === "male"); //supprimer une clé delete hugo.gender; //verfier que l'objet ne contient pas la clé gender console.assert(!Object.keys(hugo).includes("gender")); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="loops">Les boucles</h2> <div class="sectionbody"> <div class="paragraph"> <p>06_loops.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Les boucles: Itérer sur arrays et objets. */ console.log("for loop over array"); var numbers = [12, 10, 8, 6, 4, 2, 0]; for (number of numbers) { console.log(number); } console.log("---------"); console.log("for loop over object key"); var obj = { a: 1, b: 2, c: 3, d: 4 }; for (key in obj) { console.log(key); } console.log("---------"); console.log("for loop over object value"); for (value in obj) { console.log(obj[value]); } console.log("---------"); console.log("another for loop over authors array") var authors = [ ["Chrétien", "de Troyes", "fr"], ["François", "Rabelais", "fr"], ["René", "Descartes", "fr"], ["Jean-Jacques", "Rousseau", "fr"], ["Georg", "Hegel", "de"], ["Karl", "Marx", "de"], ["Friedrich", "Engels", "de"], ["Victor", "Hugo", "fr"], ["Paul", "Verlaine", "fr"], ["Antonio", "Gramsci", "it"], ["Georg", "Lukacs", "hu"], ["Franz", "Kafka", "hu"], ["Arthur", "Rimbaud", "fr"], ["Gérard", "de Nerval", "fr"], ]; for (const [i, value] of authors.entries()) { console.log(`${value[0]}, ${value[1]} (${value[2]})`); } console.log("---------"); console.log("while loop over array") var i = 0 while (i < authors.length) { console.log(`${authors[i][0]}, ${authors[i][1]} (${authors[i][2]})`); i++; } console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="const_var_let">Const, var et let</h2> <div class="sectionbody"> <div class="paragraph"> <p>07_const_var_let.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * const X var X let */ //var x du if n'est pas confiné au scope du if const varTest = () => { var x = 1; console.log(x); console.assert(x === 1); if (true) { var x = 2; console.log(x); console.assert(x === 2); } console.log(x); console.assert(x !== 1); console.assert(x === 2); } varTest(); console.log("---------"); //var x est global à tous les fichier js //chargés dans la page html //var x issue du fichier 1_start.js //ligne 46 console.log(x); console.assert(x === 20); console.log("---------"); //premier let x est confiné au scope de la fonction //le let x du if est confiné au scope du if const letTest = () => { let x = 1; console.log(x); console.assert(x === 1); if (true) { let x = 2; console.log(x); console.assert(x === 2); } console.log(x); console.assert(x === 1); console.assert(x !== 2); } letTest(); console.log("---------"); /** * const: déclare un emplacement mémoire non réattribuable * c'est modifiable pour un array, * mais non réinitialisable; * ex: * const arr = [25, 27, 29] * arr = [5, 7] //impossible * arr[0]=20 // possible * ex: * const n = 1; * n = 3; //impossible */ const arr = [25, 27, 29] console.table(arr); arr[0] = 20 // possible console.table(arr); arr.pop() console.table(arr); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="rest_and_spread_operators">Rest et spread operators</h2> <div class="sectionbody"> <div class="paragraph"> <p>08_rest_and_spread_operators.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Opérateur de rest: * const add = (...operandes) => a + b; * ou avec parametres avec valeur par défaut * const add = (a=0, b=0, ...operandes) => a + b; */ /** * spread opérateur: * récupère l'ensemble des elements d'une collection, * dans un array */ const user_ages = [25, 56, 12, 58, 41, 62, 26]; const max_user_age = Math.max(...user_ages); const min_user_age = Math.min(...user_ages); console.assert(max_user_age == 62); console.assert(min_user_age == 12); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="destructuring">Destructuring</h2> <div class="sectionbody"> <div class="paragraph"> <p>09_destructuring.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * L'affectation par décomposition (destructuring) */ const user = { first_name: "Oliv", last_name: "Cher", nick_name: "cheroliv", gender: "male", is_adult: true }; console.log(user); //première façon d'initaliser des variables sans destructuration let first_name_legacy = user.first_name; let last_name_legacy = user.last_name; let nick_name_legacy = user.nick_name; let gender_legacy = user.gender; let is_adult_legacy = user.is_adult; console.assert("Oliv" === first_name_legacy); console.assert("Cher" === last_name_legacy); console.assert("cheroliv" === nick_name_legacy); console.assert("male" === gender_legacy); console.assert(true === is_adult_legacy); console.log("---------"); /** * Initialisation par déstructuration */ const { first_name, last_name, nick_name, gender, is_adult } = user; console.assert(user.first_name === first_name); console.assert(user.last_name === last_name); console.assert(user.nick_name === nick_name); console.assert(user.gender === gender); console.assert(user.is_adult === is_adult); /** * Intialisation par déstructuration des arrays */ //cible explicite const [a1, a2] = [15, 25, 17, 81, 51, 46]; console.assert(a1 === 15); console.assert(a2 === 25); //cible avec position par rapport aux index par virgules //je veux b3 à 46 const [b1, b2, , , , b3] = [15, 25, 17, 81, 51, 46]; console.assert(b1 === 15); console.assert(b2 === 25); console.assert(b3 === 46); //déstructuration avec operateur de rest // je contruit un autre avec avec les elements // à partir du premier élèment non destructuré const [c1, c2, ...sub_arr] = [15, 25, 17, 81, 51, 46]; console.assert(b1 === 15); console.assert(b2 === 25); console.assert(sub_arr.length === 4); console.assert(sub_arr[0] === 17); console.assert(sub_arr[1] === 81); console.assert(sub_arr[2] === 51); console.assert(sub_arr[3] === 46); // Une boucle pour comparer le resultat attendu for (const [i, value] of[15, 25, 17, 81, 51, 46].entries()) { //on reconstruit le tableau à chaque iteration console.assert([c1, c2].concat(sub_arr)[i] === value); }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="import_export">Import et export de modules</h2> <div class="sectionbody"> <div class="paragraph"> <p>10_module_import_export.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Import et export de module * * Dans le fichier html * au niveau de la balise d'import de script * spécifier le type module * * 1er technique: import nommé des fonctions: * import { sum, minus, times, div, rem } from "./dummy_math_functions.js"; * * 2eme technique: import global des fonction avec l'asterisque(*) * en préfixant l'import par un nommage du fichier importé: * import * as math from "./dummy_math_functions.js"; * * 3eme technique: import par alias avec le mot clé "as" * import { * sum as add, * minus as substract, * times as multiply, * div as divide, * rem as modulo * } from "./dummy_math_functions.js"; */ import { sum, minus, times, div, rem } from "./dummy_math_functions.js"; console.assert(sum(1, 1) === 2); console.assert(minus(4, 2) === 2); console.assert(times(2, 2) === 4); console.assert(div(4, 2) === 2); console.assert(rem(4, 2) === 0);</code></pre> </div> </div> <div class="paragraph"> <p>dummy_math_functions.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">//sum const sum = (x, y) => x + y; // subtraction const minus = (x, y) => x - y; // multiplication const times = (x, y) => x * y; // division const div = (x, y) => x / y; // remainder: reste de la division euclidiene const rem = (x, y) => x % y; // log sum const sum_log = (x, y) => console.log(sum(x, y)); // log subtraction const minus_log = (x, y) => console.log(minus(x, y)); // log multiplication const times_log = (x, y) => console.log(times(x, y)); // log division const div_log = (x, y) => console.log(div(x, y)); // log remainder const rem_log = (x, y) => console.log(rem(x, y)); export { sum, minus, times, div, rem, sum_log, minus_log, times_log, div_log, rem_log };</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> <div class="sect1"> <h2 id="classes">Utilisation des classes</h2> <div class="sectionbody"> <div class="paragraph"> <p>11_classes.js</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-javascript" data-lang="javascript">/** * Utilisation des classes */ //creation d'un objet class Account { constructor(username) { this.username = username; } }; const acc1 = new Account("cheroliv"); console.table(acc1); console.assert(acc1.username === "cheroliv"); console.log("---------"); //création d'un objet et ajout de getter et setter(accesseurs) class AccountInfo { constructor(username) { this._username = username; } get username() { return this._username; } /** * @param {(arg0: string) => void} new_username */ set new_username(new_username) { this._username = new_username; } }; const acc_info1 = new AccountInfo("cheroliv"); console.table(acc_info1); //accés au membre _username avec le getter username() console.assert(acc_info1.username === "cheroliv"); //update la valeur username de acc_info1 avec le setter acc_info1.new_username = "imrandeh"; console.assert(acc_info1.username === "imrandeh"); console.log("---------");</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc_js"><span class="underline">Intro Javascript</span></a></p> </div> </div> </div> https://pages-content.github.io//blog/2022/0054_memo_cadrage_post.html Sat, 31 Dec 2022 00:00:00 +0000 blog/2022/0054_memo_cadrage_post.html <div class="sect1"> <h2 id="_cadrage">cadrage</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_atelier_1_vision">Atelier 1 : Vision</h3> <div class="sect3"> <h4 id="_1_le_pattern_qqoqcp_qui_quoi_où_quand_comment_pourquoi">1. Le pattern “QQOQCP” – Qui, Quoi, Où, Quand, Comment, Pourquoi</h4> </div> <div class="sect3"> <h4 id="_2_le_product_vision_board">2. Le Product Vision Board</h4> <div class="sect4"> <h5 id="_target_group">Target Group</h5> <div class="paragraph"> <p>Qui sont les utilisateurs qui utilisent le produit ou l’offre ? (direct, indirect)</p> </div> </div> <div class="sect4"> <h5 id="_needs">Needs</h5> <div class="paragraph"> <p>Quels sont les 5 besoins principaux des utilisateurs clés de l’application ?</p> </div> </div> <div class="sect4"> <h5 id="_product">Product</h5> <div class="paragraph"> <p>Quelle est ma proposition de valeur ? Quelles sont les 5 fonctionnalités principales du produit qui permettent de répondre aux besoins</p> </div> </div> <div class="sect4"> <h5 id="_business_goal">Business Goal</h5> <div class="paragraph"> <p>Quelles sont les critères de succès ?</p> </div> </div> <div class="sect4"> <h5 id="_vision">Vision</h5> <div class="paragraph"> <p>Quand les 4 colonnes sont complètes, il vous faudra remplir la partie vision du Product Vision Board en une phrase complète.</p> </div> </div> </div> </div> <div class="sect2"> <h3 id="_atelier_2_personasparcours_utilisateurs">Atelier 2: Personas/Parcours utilisateurs</h3> <div class="ulist"> <div class="title">Définir pour chaque persona un parcours utilisateur:</div> <ul> <li> <p>Qui va utiliser mon service? (Cible)</p> </li> <li> <p>Que veut-il faire ? (But)</p> </li> <li> <p>Comment va t-il faire ? (Parcours Utilisateur)</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_atelier_3_zoning_storyboard_sitemap">Atelier 3: Zoning, Storyboard, Sitemap</h3> <div class="sect3"> <h4 id="_1_zoning">1. Zoning</h4> </div> <div class="sect3"> <h4 id="_2_storyboard">2. StoryBoard</h4> </div> <div class="sect3"> <h4 id="_3_sitemap">3. SiteMap</h4> </div> </div> <div class="sect2"> <h3 id="_atelier_4_wireframemoodboard">Atelier 4: Wireframe/Moodboard</h3> <div class="sect3"> <h4 id="_1_wireframes">1. Wireframes</h4> </div> <div class="sect3"> <h4 id="_2_moodboard">2. Moodboard</h4> </div> </div> <div class="sect2"> <h3 id="_atelier_5_story_mapping_user_stories">Atelier 5: Story Mapping/ User stories</h3> <div class="sect3"> <h4 id="_story_mapping_priorisation_des_us">Story mapping (priorisation des US)</h4> </div> <div class="sect3"> <h4 id="_en_tant_que_type_dutilisateur_je_veux_un_objectif_afin_que_une_raison">En tant que <type d’utilisateur>, je veux <un objectif> afin que <une raison>.</h4> </div> </div> <div class="sect2"> <h3 id="_atelier_6_backlog">Atelier 6: Backlog</h3> <div class="paragraph"> <p><a href="https://www.atlassian.com/fr/agile/scrum/backlogs">backlogs</a></p> </div> </div> <div class="sect2"> <h3 id="_atelier_7_technique_et_architecture">Atelier 7: Technique et Architecture</h3> </div> </div> </div> https://pages-content.github.io//blog/2022/0053_memo_kotlin_post.html Sun, 29 May 2022 00:00:00 +0000 blog/2022/0053_memo_kotlin_post.html <div class="sect1"> <h2 id="_good_links">Good links</h2> <div class="sectionbody"> <div class="paragraph"> <p><a href="https://play.kotlinlang.org/">kotlinlang playground</a><br></p> </div> <div class="paragraph"> <p><a href="https://arrow-kt.io/">arrow.kt</a><br></p> </div> <div class="paragraph"> <p><a href="https://arkivanov.github.io/MVIKotlin/">MVI:Model View Intent</a><br></p> </div> <div class="paragraph"> <p><a href="https://github.com/arkivanov/Essenty">Essenty</a><br></p> </div> <div class="paragraph"> <p><a href="https://arkivanov.github.io/Decompose/">Decompose</a><br></p> </div> </div> </div> <div class="sect1"> <h2 id="_bout_de_code_divers">Bout de code divers</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_map_reduce">map reduce</h3> <div class="paragraph"> <p>Convertir une list de bite vers une list de string et résumer la list de string<br> dans une string contenant la concatenation. Comment logger la request envoyé(requestBodyContent:byte[])</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">log.info( requestBodyContent!!.map { it.toInt().toChar().toString() } .reduce { request: String, s: String -> request + s } )</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_enum_et_sealed_classes">enum et sealed classes</h3> <div class="paragraph"> <p>post: <a href="0038_training_kotlin_enum_sealed_class_post" target="_blank" rel="noopener">training kotlin enum sealed class</a></p> </div> </div> <div class="sect2"> <h3 id="_functionnal_interface_et_method_reference">functionnal interface et method reference</h3> <div class="paragraph"> <p>On peut transformer une entité en model domain de dto avec un methode reference(functionnal style- java 8)</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">fun findAllByLoginNot( pageable:Pageable, login:String) :Page<UserDto> { return userDao.findAllByLoginNot( pageable, login).map(::fromEntity) }</code></pre> </div> </div> <div class="paragraph"> <p>une <a href="https://stackoverflow.com/a/22245383/837404">bonne explication</a></p> </div> </div> <div class="sect2"> <h3 id="_capturer_la_sortie_standard">Capturer la sortie standard</h3> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package functional import java.io.ByteArrayOutputStream import java.io.PrintStream import java.lang.System.out import java.lang.System.setOut import kotlin.test.AfterTest import kotlin.test.BeforeTest import kotlin.test.Test import kotlin.test.assertEquals class BasicsHOF { private val standardOut: PrintStream? = out private val outputStreamCaptor = ByteArrayOutputStream() @BeforeTest fun setUp() = setOut(PrintStream(outputStreamCaptor)) @AfterTest fun tearDown() = setOut(standardOut) @Test fun `three times dope`() { 3.times { println("Hello") } assertEquals( buildString { repeat(3) { append("Hello\n") } deleteAt(length - 1) }, outputStreamCaptor .toString() .trim() ) } fun Int.times(fn: () -> Unit) = (1..this).forEach { _ -> fn() } }</code></pre> </div> </div> </div> <div class="sect2"> <h3 id="_quelle_est_la_différence_en_kotlin_entre_apply_run_let_also_use_et_with">Quelle est la différence en kotlin entre apply, run, let, also, use et with ?</h3> <div class="paragraph"> <p><strong>Comparaison des fonctions Kotlin et Utilisation des Formes Lambda Reference</strong></p> </div> <div class="paragraph"> <div class="title">Introduction</div> <p>Les fonctions Kotlin <code>apply</code>, <code>run</code>, <code>let</code>, <code>also</code>, <code>use</code>, et <code>with</code> offrent des moyens différents de traiter les objets. Chacune a ses propres cas d’utilisation et comportements. En outre, les formes lambda reference permettent de rendre le code plus lisible et réutilisable en faisant référence à des fonctions lambda existantes.</p> </div> </div> </div> </div> <div class="sect1"> <h2 id="_apply">apply</h2> <div class="sectionbody"> <div class="paragraph"> <p>La fonction <code>apply</code> est utilisée pour configurer un objet pendant sa création. Elle retourne l’objet sur lequel elle est appelée.</p> </div> <div class="paragraph"> <p>Exemple avec lambda reference :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val someObject = SomeClass().apply(::configureObject)</code></pre> </div> </div> <div class="paragraph"> <p>Exemple avec lambda :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val someObject = SomeClass().apply { // configuration des propriétés de someObject }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_run">run</h2> <div class="sectionbody"> <div class="paragraph"> <p>La fonction <code>run</code> est utilisée pour exécuter un bloc de code sur un objet et retourne le résultat du bloc de code.</p> </div> <div class="paragraph"> <p>Exemple avec lambda reference :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result = someObject.run(::someFunction)</code></pre> </div> </div> <div class="paragraph"> <p>Exemple avec lambda :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result = someObject.run { // bloc de code à exécuter sur someObject // la dernière expression est renvoyée }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_let">let</h2> <div class="sectionbody"> <div class="paragraph"> <p>La fonction <code>let</code> est utilisée pour exécuter un bloc de code sur un objet et retourne le résultat du bloc de code.</p> </div> <div class="paragraph"> <p>Exemple avec lambda reference :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result = someObject.let(::processObject)</code></pre> </div> </div> <div class="paragraph"> <p>Exemple avec lambda :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result = someObject.let { // bloc de code à exécuter sur someObject // la dernière expression est renvoyée }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_also">also</h2> <div class="sectionbody"> <div class="paragraph"> <p>La fonction <code>also</code> est utilisée pour effectuer une action additionnelle sur un objet et retourne l’objet sur lequel elle est appelée.</p> </div> <div class="paragraph"> <p>Exemple avec lambda reference :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">someObject.also(::performAdditionalAction)</code></pre> </div> </div> <div class="paragraph"> <p>Exemple avec lambda :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">someObject.also { // action additionnelle sur someObject }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_use">use</h2> <div class="sectionbody"> <div class="paragraph"> <p>La fonction <code>use</code> est utilisée pour travailler avec des ressources qui doivent être fermées après utilisation. Elle appelle automatiquement la fonction <code>close</code> à la fin du bloc.</p> </div> <div class="paragraph"> <p>Exemple avec lambda reference :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">someResource.use(::useResource)</code></pre> </div> </div> <div class="paragraph"> <p>Exemple avec lambda :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">someResource.use { // travailler avec la ressource }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_with">with</h2> <div class="sectionbody"> <div class="paragraph"> <p>La fonction <code>with</code> est utilisée pour appeler plusieurs méthodes sur un objet sans répéter son nom et retourne le résultat de la dernière expression.</p> </div> <div class="paragraph"> <p>Exemple avec lambda reference :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result = with(someObject, ::processWithObject)</code></pre> </div> </div> <div class="paragraph"> <p>Exemple avec lambda :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">val result = with(someObject) { // appeler des méthodes sur someObject // la dernière expression est renvoyée }</code></pre> </div> </div> <div class="paragraph"> <p>En utilisant les formes lambda reference ou les blocs <code>{}</code>, vous pouvez encapsuler la logique dans des fonctions distinctes, améliorant ainsi la lisibilité et la réutilisabilité du code.</p> </div> </div> </div> <div class="sect1"> <h2 id="_let_function_en_kotlin">let Function en Kotlin</h2> <div class="sectionbody"> <div class="paragraph"> <div class="title">Est-ce que let renvoi l’objet avec les effets de bord opérés dessus ou dans l’état initiale d’entré en fonction(let) ?</div> <p>La fonction <code>let</code> en Kotlin est utilisée pour effectuer des opérations sur un objet et renvoyer un résultat différent. Cependant, il est important de noter que la fonction <code>let</code> ne modifie pas l’état initial de l’objet sur lequel elle est appelée.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 100%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"><strong>Signature</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><code>inline fun <T, R> T.let(block: (T) → R): R</code></p></td> </tr> </tbody> </table> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 100%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"><strong>Usage</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">La fonction <code>let</code> est couramment utilisée pour appliquer des transformations à un objet et obtenir un résultat basé sur ces transformations.</p></td> </tr> </tbody> </table> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 100%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"><strong>Résultat</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">La valeur renvoyée par la fonction <code>let</code> est le résultat de l’expression lambda passée en argument, généralement le résultat des opérations effectuées sur l’objet.</p></td> </tr> </tbody> </table> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 100%;"> </colgroup> <thead> <tr> <th class="tableblock halign-left valign-top"><strong>Effets de Bord</strong></th> </tr> </thead> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Bien que la fonction <code>let</code> puisse avoir des effets de bord sur l’objet lorsqu’elle est utilisée dans l’expression lambda, elle ne modifie pas l’état initial de l’objet lui-même.</p></td> </tr> </tbody> </table> <div class="paragraph"> <p>Ainsi, la fonction <code>let</code> est une façon élégante d’effectuer des opérations sur un objet tout en obtenant un résultat dérivé, tout en préservant l’intégrité de l’objet d’origine.</p> </div> </div> </div> https://pages-content.github.io//blog/2022/0052_memo_jvm_post.html Sat, 28 May 2022 00:00:00 +0000 blog/2022/0052_memo_jvm_post.html <div class="sect1"> <h2 id="toc">table des matières</h2> <div class="sectionbody"> <div class="olist arabic"> <ol class="arabic"> <li> <p><a href="#char">chaines de caractères et caractères</a></p> </li> <li> <p><a href="#math">nombres et math</a></p> </li> <li> <p><a href="#date">dates et heures</a></p> </li> <li> <p><a href="#java8date">dates et heures java8</a></p> </li> <li> <p><a href="#arrCol">tableaux et collections</a></p> </li> <li> <p><a href="#sysProp">System.Properties</a></p> </li> <li> <p><a href="#threads">Threads</a></p> </li> <li> <p><a href="#regex">Expressions Régulières</a></p> </li> </ol> </div> </div> </div> <div class="sect1"> <h2 id="char">chaines de caractères et caractères</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">import java.text.Collator import java.util.* import kotlin.test.* class StringsTest { @Test fun `chaines de caractères et caractères`() { //inférence de type val s = "C'est" assertEquals("C'est", s) //concaténation val t: String = s + " le moment." assertEquals("C'est le moment.", t) // StringBuilder val t1: String = s + buildString { append(" le moment.") } assertEquals("C'est le moment.", t1) //interpolation val t2 = "$s le moment." assertEquals("C'est le moment.", t2) //multiligne chaine de caractères val t3 = """$s le moment.""" assertEquals("C'est le moment.", t3) //conversion de type val t4 = t + " " + 23.4 assertEquals("C'est le moment. 23.4", t4) val t5 = 'C'.toString() assertEquals("C", t5) //taille de la chaine de caractères assertEquals(16, t.length) //sous-chaine d'une chaine de caractères //retourne une chaine de caractères contenant, //les caractères aux positions x à y-1 //sub = t.substring(x, y) //t = "C'est le moment." //retourne les caractères 6 et 7 var sub = t.substring(6, 8) assertEquals("le", sub) //retourne les caractères 0 à 4 sub = t.substring(0, 5) assertEquals("C'est", sub) //la longueur d'une sous-chaine est toujours égale (y-x) val numChars = sub.length assertEquals(5 - 0, numChars) //extraction des caractères d'une chaine assertEquals('e', t.elementAt(2)) assertEquals('e', t.get(2)) assertEquals('e', t[2]) //conversion d'une chaine en tableau de caractères val ca = t.toCharArray() assertEquals(t.length, ca.size) t.mapIndexed { index, char -> assertEquals(char, ca[index]) } //place les 4 premiers caractères de t1 //dans le tableau ca a la position 2 (t as java.lang.String).getChars( /* srcBegin = */ 0, /* srcEnd = */ 3, /* dst = */ ca, /* dstBegin = */ 1 ) assertEquals("CC'et le moment.", String(ca)) //colle tous les caractères dans un meme string assertEquals("CC'et le moment.", ca.concatToString()) //to lower case assertEquals("c'est le moment.", t.toLowerCase()) assertEquals("c'est le moment.", t.lowercase()) //to upper case assertEquals("C'EST LE MOMENT.", t.toUpperCase()) assertEquals("C'EST LE MOMENT.", t.uppercase()) //comparaison de chaines de caractères //t = "C'est le moment." assertFalse(t.equals("hello")) assertFalse(t == "hello") //ignore la casse assertTrue(t.equalsIgnoreCase("C'EST LE MOMENT.")) assertTrue(t.equals("C'EST LE MOMENT.", ignoreCase = true)) //démarre par assertTrue(t.startsWith("C'est")) //se finit par assertTrue(t.endsWith("le moment.")) //compareTo //retourne une valeur < 0, car s est //alphabétiquement avant "N'est" val r1: Int = s.compareTo("N'est") assertTrue(r1 < 0) //variante ignorant la casse val r1Prime: Int = (s as java.lang.String).compareToIgnoreCase("n'est") assertTrue(r1Prime < 0) //retourne 0 si les chaines sont equivalente val r2: Int = s.compareTo("C'est") assertEquals(0, r2) //retourne une valeur > 0 car s vient apres "B'est" val r3: Int = s.compareTo("B'est") assertTrue(r3 > 0) //Recherche de caractères et de sous-chaines de caractères //recherche de caractères //position du premier caractères 't' var pos = t.indexOf('t') assertEquals(4, pos) //position du suivant pos = t.indexOf('t', pos + 1) assertEquals(14, pos) //retour d'érreur -1 si absence de suivant pos = t.indexOf('t', pos + 1) assertEquals(-1, pos) //position du dernier 't' dans la chaine: 14 pos = t.lastIndexOf('t') assertEquals(14, pos) //recherche de 't' vers l'arrière a partir du caractères 13 pos = t.lastIndexOf('t', pos - 1) assertEquals(4, pos) //recherche de sous-chaines //retourne 2 pos = t.indexOf("est") assertEquals(2, pos) //"est" n'apparait qu'une seule fois: retourne -1 pos = t.indexOf("est", pos + 1) assertEquals(-1, pos) //recherche d'une sous-chaine depuis l'arrière //t = "C'est le moment." //retourne 6 pos = t.lastIndexOf("le ") assertEquals(6, pos) //extrait depuis la position 9, //renvoi toute la chaine après "le " val noun = t.substring(pos + 3) assertEquals(-1, noun.indexOf("le ")) //remplacement de toutes les instances d'un caractère //par un autre caractère //ne fonctionne que avec les caractères, pas les chaines val exclaim: String = t.replace('.', '!') assertEquals('!', exclaim.get(exclaim.length - 1)) assertEquals(exclaim.length - 1, exclaim.indexOf('!')) assertEquals(-1, exclaim.indexOf('.')) //suppression des espaces blancs //au début et à la fin d'une chaine val noextraspaces = t.trim() assertNotEquals(' ', noextraspaces.get(0)) assertNotEquals(' ', noextraspaces.get(noextraspaces.length - 1)) //extraction des instances uniques de chaines de caractères //avec intern() val s1 = s.intern() assertEquals(s, s1) val s2 = "C'est".intern() assertEquals("C'est", s2) assertEquals(s1, s2) //StringBuilder pour manipuler les caractères d'une chaine de caractères //crée un tampon StringBuilder à partir d'une chaine de caractères val b = StringBuilder("N'est") //extrait et définit des caractères individuel du tampon StringBuilder //le caractères à l'index 0 val c: Char = b.get(0) assertEquals('N', c) //modifier le premier caractère de la chaine b.setCharAt(0, 'C') assertEquals(s, b.toString()) //ajouter des données à un StringBuilder b.append(' ') b.append("le moment.") b.append(23) //insère des chaines de caractères ou autre dans le StringBuilder b.insert(6, "pas ") assertEquals("C'est pas le moment.23", b.toString()) //remplace un sous ensemble de caractères //avec une chaine de caractères donnée b.replace(2, 9, "est") assertEquals("C'est le moment.23", b.toString()) //supprime les caractères b.delete(15, 18) assertEquals("C'est le moment", b.toString()) b.deleteCharAt(2) assertEquals("C'st le moment", b.toString()) //insert à la postion 2 et décale reste à droite(sans perte de données) b.insert(2, 'e') //tronque la taille de la donnée b.setLength(5) assertEquals("C'est", b.toString()) //inverse les caractères de la chaine b.reverse() assertEquals("tse'C", b.toString()) //écrase le StringBuilder, pret à etre réutilisé b.setLength(0) assertEquals("", b.toString()) //java.util.StringTokenizer pour fragmenter une chaine //de caractères en un ensemble de mots var st = StringTokenizer(t) //nb d'items encore présentent dans la file assertEquals(3, st.countTokens()) //est ce que il y a encore des items dans la file assertTrue(st.hasMoreTokens()) //récupérer le token courrant assertEquals("C'est", st.nextToken()) assertEquals("le", st.nextToken()) assertEquals("moment.", st.nextToken()) assertFalse(st.hasMoreTokens()) assertEquals(0, st.countTokens()) //extraire des occurences de mots délimités //par des caractères autres que des expaces. val str = "a:b:c:d" st = StringTokenizer(str, ":") assertEquals(4, st.countTokens()) assertTrue(st.hasMoreTokens()) assertEquals("a", st.nextToken()) assertEquals("b", st.nextToken()) assertEquals("c", st.nextToken()) assertEquals("d", st.nextToken()) assertFalse(st.hasMoreTokens()) assertEquals(0, st.countTokens()) //text="C'est le moment." val text = t.toCharArray() var p = 0 //sauter les espaces de tete //pour ramener p à la position du premier caractère imprimable while ((p < text.size) && (Character.isWhitespace(text[p])) ) p++ assertEquals(0, p) assertEquals("C'est le moment.", text.concatToString()) //met le premier mot du texte en majuscule while (p < text.size && Character.isLetter(text[p])) { text[p] = Character.toUpperCase(text[p]) p++ } assertEquals(1, p) assertEquals('C', text[0]) assertTrue(Character.isUpperCase(text[0])) assertFalse(Character.isLetter(text[1])) //comparer des chaines de caractères // avec les contrainte la locale système val col = Collator.getInstance() //le résulat est négatif car chica //est avant chico dans l'ordre alphabétique assertTrue(col.compare("chica", "chico") < 0) } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="math">nombres et math</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">import java.math.BigInteger import java.security.SecureRandom import java.text.NumberFormat import java.util.* import kotlin.test.* class NumbersMathTest { @Test fun `Nombres et Math`() { //Constantes utiles Byte.MIN_VALUE Byte.MAX_VALUE Short.MIN_VALUE Short.MAX_VALUE Float.MIN_VALUE Float.MAX_VALUE Math.PI Math.E val s = "-42" //conversion de chaine de caractères //vers un nombre, si possible. var b: Byte = java.lang.Byte.parseByte(s) var sh: Short = java.lang.Short.parseShort(s) var i: Int = java.lang.Integer.parseInt(s) var l: Long = java.lang.Long.parseLong(s) var f: Float = java.lang.Float.parseFloat(s) var d: Double = java.lang.Double.parseDouble(s) //valeur exacte val f_exac = java.lang.Float.valueOf(s) val d_exac = java.lang.Double.valueOf(s) //les routines de conversions entière gérent //les nombres dans diverses bases. //1011 en binare est égal a 11 en base dix b = java.lang.Byte.parseByte("1011", 2) assertEquals(11, b) //ff en base 16(hexa) est égal à 255 en base dix. sh = java.lang.Short.parseShort("ff", 16) assertEquals(255, sh) //la méthode valueOf() peut gérer des bases arbitraires. i = java.lang.Integer.valueOf("egg", 17).toInt() assertEquals(4334, i) //la méthode decode() gére les representations octale, //décimal, hexadécimal, en fonction du préfixe numérique //de la chaine de caractères //un 0 de tete signifie base 8 //un 0x de tete signifie base 16 //les autres sont en base 10 val sho = java.lang.Short.decode("0377") //la classe Integer peut convertir les nombres //en diverses chaines de caractères. val decimal = java.lang.Integer.toString(42) assertEquals("42", decimal) val decimal_ = 42.toString() assertEquals("42", decimal_) val binary = java.lang.Integer.toBinaryString(42) assertEquals("101010", binary) val octal = java.lang.Integer.toOctalString(42) assertEquals("52", octal) val hex = java.lang.Integer.toHexString(42) assertEquals("2a", hex) val base36 = java.lang.Integer.toString(42, 36) assertEquals("16", base36) val base36_ = 42.toString(36) assertEquals("16", base36_) //java.text.NumberFormat effectue la conversion // d'une maniere spécifique aux parametres locaux //sans parametre prend la local systeme comme reference val nf = NumberFormat.getNumberInstance(Locale.FRANCE) val formatted_number = nf.format(9876543.21) assertNotEquals("9876543.21", formatted_number) //parse la chaine de caractères en fonction des parametres locaux(fr) val n = nf.parse("1234567,89") assertEquals(1234567.89, n) //les valeurs monétaires sont parfois formaté // d'une maniere differente des nombres val money_format = NumberFormat.getCurrencyInstance(Locale.FRANCE) assertEquals("123,40 €", money_format.format(1234.56)) //java.lang.Math d = Math.toRadians(27.0) d = Math.cos(d) d = Math.sqrt(d) d = Math.log(d) d = Math.exp(d) d = Math.pow(10.0, d) d = Math.atan(d) d = Math.toDegrees(d) //arrondi au dessus val up = Math.ceil(d) //arrondi au dessous val down = Math.floor(d) //arrondi au plus près val nearest = Math.round(d) //java.lang.Math.Random() val r = Math.random() assertTrue(r >= 0.0 && r < 1.0) //créé un nouvel objet Random, en l'initialisant //avec l'heure courante val generator = java.util.Random(System.currentTimeMillis()) //prochaine valeur aléatoire de taille double d = generator.nextDouble() assertTrue((d >= 0.0) && (d < 1.0)) //prochaine valeur aléatoire de taille float f = generator.nextFloat() assertTrue((f >= 0.0) && (f < 1.0)) //prochaine valeur aléatoire de taille long l = generator.nextLong() assertTrue( (Math.abs(l) <= Long.MAX_VALUE) && (Math.abs(l) >= 0) ) //prochaine valeur aléatoire de taille int i = generator.nextInt() assertTrue( (Math.abs(i) <= java.lang.Integer.MAX_VALUE) && (Math.abs(i) >= 0) ) val limit = 100 //prochaine valeur aléatoire de taille int //la limit max du ramdom est ramené à limit //et la limit min est 0 i = generator.nextInt(limit) assertTrue(i in 0 until limit) //prochaine valeur aléatoire de taille booléen val bool = generator.nextBoolean() assertNotNull(bool) //valeur moyenne 0.0, déviation standard 1.0 d = generator.nextGaussian() //randoms bytes //rempli un tableau avec des valeurs byte aléatoires val b_arr = ByteArray(128) generator.nextBytes(b_arr) b_arr.iterator().forEachRemaining { assertTrue( it <= Byte.MAX_VALUE && it >= Byte.MIN_VALUE ) } //java.security.SecureRandom pour les nombres aléatoires //utilisé en cryptographie val secure_generator = SecureRandom() //le générateur génère sa propre tete de liste sur 16 octets secure_generator.setSeed(secure_generator.generateSeed(16)) val sec_b_arr = ByteArray(128) secure_generator.nextBytes(sec_b_arr) sec_b_arr.iterator().forEachRemaining { assertTrue( it <= java.lang.Byte.MAX_VALUE && it >= java.lang.Byte.MIN_VALUE ) } //java.math.BigDecimal java.math.BigInteger //pour travailler sur des grandes valeurs. //calcule de la factorielle de 1000 var total = BigInteger.valueOf(1) (2..1000).forEach { total = total.multiply(BigInteger.valueOf(it.toLong())) } assertTrue(total.toString().length == 2568) } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="date">dates et heures</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">import java.text.DateFormat import java.text.SimpleDateFormat import java.time.Instant import java.util.* import kotlin.test.Test import kotlin.test.assertEquals import kotlin.test.assertTrue class DatesHoursTest { @Test fun `Dates et heures`() { //l'heure courante en millisecondes val t0 = System.currentTimeMillis() //une autre représentation de la meme information val now = java.util.Date() //converti un objet java.util.Date en une valeur long. val t1 = now.getTime() assertTrue(t1 > Instant.EPOCH.toEpochMilli()) //kotlin property access syntaxe style val t1_prime = now.time //java.text.DateFormat //affiche la date d'aujourd'hui en utilisant le format //par défaut des parametres locaux val defaultDateFormat = DateFormat.getDateInstance() //personnalisation du formatage et de la locale val df = DateFormat.getDateInstance(DateFormat.LONG, Locale.FRANCE) val localeFormattedDate = df.format(Date()) //constantes pour les styles de pattern de formatage assertEquals(0, DateFormat.FULL) assertEquals(1, DateFormat.LONG) assertEquals(2, DateFormat.MEDIUM) assertEquals(3, DateFormat.SHORT) assertEquals(2, DateFormat.DEFAULT) //utilise pour l'heure un format abrégé avec //des parametres personnalisés val tf = DateFormat.getTimeInstance( DateFormat.SHORT, Locale.FRANCE ) //affiche l'heure en utilisant le format de tf val shortTime = tf.format(Date()) assertTrue(shortTime.contains(':')) //affiche la date et l'heure en utilisant //un format détaillé val longTimeStamp = DateFormat.getDateTimeInstance( DateFormat.FULL, DateFormat.FULL, ) assert(longTimeStamp.format(Date()).isNotEmpty()) //utilisez java.text.SimpleDateFormat //pour définir votre propre modele de formatage val customFormat = SimpleDateFormat("yyyy.MM.dd") assertEquals(10, customFormat.format(Date()).length) //DateFormat peut également parser les date contenu dans des chaines val kotlinAnnounceDate = customFormat.parse("2019.05.08") //la class Date et sa représentation en millisecondes //n'autorise qu'une forme trés simple d'arithmétique //on ajoute 3 600 000 millisecondes à l'heure courante val anHourFromNow = now.getTime() + (60 * 60 * 1000) assert(anHourFromNow > now.getTime()) //java.util.Calendar //pour manipuler les dates et heures de facon plus sophistiquée //instanciation selon les parametres locaux //et le fuseau horaire local val calendar = Calendar.getInstance() //initialisation du calendrier à la date de maintenant calendar.setTime(now) //détermine le jour de l'année auquel correspond la date courante val dayOfYear = calendar.get(Calendar.DAY_OF_YEAR) assert(dayOfYear < 366) //réinitialisation de la date courante calendar.set(2019, Calendar.MAY, 8) assertEquals(4, calendar.get(Calendar.DAY_OF_WEEK)) //à quel jour du mois correspond le deuxieme mercredi de mai 2019 //set(key,value) calendar.set(Calendar.YEAR, 2019) calendar.set(Calendar.MONTH, Calendar.MAY) calendar.set(Calendar.DAY_OF_WEEK, Calendar.WEDNESDAY) //defini à quel (n=2) semaine du mois est la date calendar.set(Calendar.DAY_OF_WEEK_IN_MONTH, 2) //extrait le jour du mois val dayOfMonth = calendar.get(Calendar.DAY_OF_MONTH) assertEquals(8, dayOfMonth) calendar.setTime(kotlinAnnounceDate) //ajoute 30j à la date calendar.add(Calendar.DATE, 30) val monthAfter = calendar.getTime() //date est elle avant ou apres? assertTrue(monthAfter.after(kotlinAnnounceDate)) } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="java8date">dates et heures java8</h2> <div class="sectionbody"> <div class="paragraph"> <p>Java 8 introduit le nouveau package <strong><em>java.time</em></strong>, qui contient les classes de base qui<br> la plupart des développeurs travaillent avec. Il contient également quatre sous-packages:<br></p> </div> <div class="paragraph"> <p><strong><em>java.time.chrono</em></strong><br> Chronologies alternatives que les développeurs utilisant des systèmes de calendrier qui ne<br> suivre la norme ISO va interagir avec. Un exemple serait un cal japonais<br> système endurant.<br> <strong><em>java.time.format</em></strong><br> Contient le DateTimeFormatter utilisé pour convertir les objets de date et d’heure<br> dans une chaîne et également pour analyser les chaînes dans les objets de données et de temps.<br> <strong><em>java.time.temporal</em></strong><br> Contient les interfaces requises par les classes de date et d’heure de base et également<br> des abstractions (telles que des requêtes et des ajusteurs) pour des opérations avancées avec des dates.<br> <strong><em>java.time.zone</em></strong><br> Classes utilisées pour les règles de fuseau horaire sous-jacentes;<br> la plupart des développeurs n’auront pas besoin ce paquet.<br></p> </div> <div class="imageblock"> <div class="content"> <img src="../../img/java8-date-time.png" alt="java8 date time"> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">import java.time.LocalDate import java.time.Month import java.time.Period import java.time.YearMonth import java.time.temporal.* import java.util.HashMap import java.util.stream.Collectors import kotlin.test.Test class DatesHoursJava8Test { class BirthdayDiary { private val birthdays: MutableMap<String, LocalDate> init { birthdays = HashMap() } fun addBirthday( name: String, day: Int, month: Int, year: Int ): LocalDate { val birthday: LocalDate = LocalDate.of(year, month, day) birthdays[name] = birthday return birthday } fun getBirthdayFor(name: String): LocalDate? { return birthdays[name] } fun getAgeInYear(name: String, year: Int): Int { val period: Period = Period.between( birthdays[name], birthdays[name]!!.withYear(year) ) return period.getYears() } fun getFriendsOfAgeIn(age: Int, year: Int): Set<String> { return birthdays.keys.stream() .filter { p: String -> getAgeInYear(p, year) == age } .collect(Collectors.toSet()) } fun getDaysUntilBirthday(name: String): Int { val period: Period = Period.between( LocalDate.now(), birthdays[name] ) return period.getDays() } fun getBirthdaysIn(month: Month): Set<String> { return birthdays.entries.stream() .filter { (_, value): Map.Entry<String, LocalDate> -> value.getMonth() === month } .map<String> { (key): Map.Entry<String, LocalDate> -> key } .collect(Collectors.toSet()) } val birthdaysInCurrentMonth: Set<String> get() = getBirthdaysIn(LocalDate.now().getMonth()) val totalAgeInYears: Int get() = birthdays.keys.stream() .mapToInt { p: String -> getAgeInYear( p, LocalDate.now().getYear() ) } .sum() } //Les ajusteurs modifient les objets de date et d'heure. Supposons, par exemple, que nous voulions //renvoie le premier jour d'un trimestre qui contient un horodatage particulier : class FirstDayOfQuarter : TemporalAdjuster { override fun adjustInto(temporal: Temporal): Temporal? { val currentQuarter: Int = YearMonth.from(temporal) .get(IsoFields.QUARTER_OF_YEAR) return when (currentQuarter) { 1 -> LocalDate.from(temporal) .with(TemporalAdjusters.firstDayOfYear()) 2 -> LocalDate.from(temporal) .withMonth(Month.APRIL.value) .with(TemporalAdjusters.firstDayOfMonth()) 3 -> LocalDate.from(temporal) .withMonth(Month.JULY.value) .with(TemporalAdjusters.firstDayOfMonth()) 4 -> LocalDate.from(temporal) .withMonth(Month.OCTOBER.value) .with(TemporalAdjusters.firstDayOfMonth()) else -> null } } } enum class Quarter { FIRST, SECOND, THIRD, FOURTH } //Dans quel trimestre de l'année cette date se situe-t-elle ? class QuarterOfYearQuery : TemporalQuery<Quarter> { override fun queryFrom(temporal: TemporalAccessor): Quarter { val now = LocalDate.from(temporal) return if (now.isBefore(now.with(Month.APRIL).withDayOfMonth(1))) Quarter.FIRST else if (now.isBefore( now.with(Month.JULY) .withDayOfMonth(1) ) ) Quarter.SECOND else if (now.isBefore( now.with(Month.NOVEMBER) .withDayOfMonth(1) ) ) Quarter.THIRD else Quarter.FOURTH } } @Test fun `Dates et heures après java 8`() { val today = LocalDate.now() val currentMonth = today.month val firstMonthOfQuarter = currentMonth.firstMonthOfQuarter() val q = QuarterOfYearQuery() // Direct var quarter: Quarter? = q.queryFrom(LocalDate.now()) println(quarter) // Indirect quarter = LocalDate.now().query(q) println(quarter) val now = LocalDate.now() val fdoq: Temporal = now.with(FirstDayOfQuarter()) println(fdoq) } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="arrCol">tableaux et collections</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="../../img/collections_classes_inheritance.png" alt="Classes de collections et héritage"> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package playground.programming import java.util.* import kotlin.test.Test import kotlin.test.assertEquals import kotlin.test.assertFalse import kotlin.test.assertTrue class ArrayCollectionTest { @Test fun `Tableaux, collections`() { //Tableau //java.util.Arrays définit d'utiles méthodes de manipulation de tableaux, //y compris de tri et de recherche au sein d'un tableau val intArray = arrayOf(10, 5, 7, -3) //tri le tableau Arrays.sort(intArray) var pos = Arrays.binarySearch(intArray, 7) //la valeur 7 est trouvé a l'index 2 assertEquals(2, pos) //12 pas trouvé retourne une valeur negative assert(Arrays.binarySearch(intArray, 12) < 0) //les tableaux peuvent également etre triés //et faire l'objet d'une recherche val stringArray = arrayOf("le", "moment", "c'est") assertEquals("c'est", stringArray[2]) assertEquals("le", stringArray[0]) assertEquals("moment", stringArray[1]) Arrays.sort(stringArray) assertEquals("c'est", stringArray[0]) assertEquals("le", stringArray[1]) assertEquals("moment", stringArray[2]) //Arrays.equals() compare tous les éléments de deux tableaux //Arrays.clone() copie tous les elements du tableau dans un autre stringArray.forEachIndexed { i, it -> assertEquals(it, stringArray.clone()[i]) } val data = ByteArray(100) //Arrays.fill() initialise tous les éléments des deux tableaux //initalise tous les éléments à -1 Arrays.fill(data, -1) data.forEach { assertEquals(-1, it) } //attribue aux éléments 5, 6, 7, 8 et 9 la valeur -2 Arrays.fill(data, 5, 10, -2) ((5 until (10 - 1))).forEach { assertEquals(-2, data[it]) } //récupère le type de data val type = data::class.java //est ce que data est un tableau? assertTrue(type.isArray()) //est ce que data est un tableau de byte assertEquals(Byte::class.java, type.getComponentType()) //Collection val s = java.util.HashSet<String>() s.add("test") assertTrue(s.contains("test")) assertFalse(s.contains("test2")) s.remove("test") assertFalse(s.contains("test")) val ss = TreeSet<String>() ss.add("b") ss.add("a") ss.iterator().forEach { assertTrue(it == "a" || it == "b") } //liste doublement chainée var dll: List<String> = LinkedList<String>() //plus efficace val l = java.util.ArrayList<String>() l.addAll(ss) l.addAll(1, ss) val obj = l.get(1) val obj_prime = l[1] assertEquals(obj, obj_prime) l.set(3, "nouvel élément") l.add("test") l.add(0, "test2") l.removeAt(1) l.remove("a") assertFalse(l.contains("a")) l.removeAll(ss) assertFalse(l.containsAll(ss)) assertFalse(l.isEmpty()) assertTrue(l.isNotEmpty()) val sublist = l.subList(1, 3) val elements = l.toArray() l.clear() val m = HashMap<String, Integer>() m.put("clé", Integer(42)) m["clé"] = Integer(42) val value: Integer = m.get("clé")!! assertEquals(Integer(42), value) m.remove("clé") assertTrue(m.isEmpty()) val keys = m.keys assertTrue(keys.isEmpty()) val set = HashSet<String>() set.add("key_1") set.add("key_2") set.add("key_3") val members = set.toArray() assertEquals(3, members.size) val list = ArrayList<String>() list.add("items1") list.add("items2") list.add("items3") val items = list.toArray() assertEquals(3, items.size) //trie et recherche d'éléments sur les collections list.add("clé") //en premier on trie Collections.sort(list) //en kotlin list.sort() //en deuxieme on cherche //retourne l'index du premier trouvé sinon -1 pos = Collections.binarySearch(list, "clé") assertEquals(0, pos) val list1 = mutableListOf(1, 2, 3, 4, 5) val list2 = mutableListOf<Int>(0, 0, 0, 0, 0) //d'autres méthodes intéressantes concernant Collections //copie list1 dans list2, 2e parametre dans 1er parametre Collections.copy(list2, list1) //comparaison de la copy avec filter assertTrue(list1.filterIndexed { i: Int, it: Int -> it != list2[i] }.isEmpty()) //comparaison de la copy avec map list1.mapIndexed { index: Int, it: Int -> assertEquals(it, list2[index]) } //rempli avec des 0 Collections.fill(list2, 0) assertTrue(list2.none { it != 0 }) //le maximum assertEquals(5, Collections.max(list1)) //le minimum assertEquals(1, Collections.min(list1)) //renverse Collections.reverse(list) listOf("items3", "items2", "items1", "clé").mapIndexed { i: Int, it: String -> assertEquals(it, list[i]) } //mélange la list Collections.shuffle(list) //retourne un ensemble immuable possédant un seul élément 0 Collections.singleton(0) //renvoi un emballage immuable autour d'une liste Collections.unmodifiableList(list) //renvoi un emballage synchronisé autour d'une map, ensemble clé valeur Collections.synchronizedMap(m) //java.util.Properties un est objet key value } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="sysProp">System.Properties</h2> <div class="sectionbody"> <div class="paragraph"> <p><a href="https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html">System.Properties doc officielle</a></p> </div> <div class="paragraph"> <p>voici un tableau de quelques propriétés intéressantes<br> Ces propriétés sont intéressantes pour avoir des informations<br> sur le système hôte de la JVM.</p> </div> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 50%;"> <col style="width: 50%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Key</strong></p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Meaning</strong></p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">file.separator</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Character that separates components of a file path. This is "/" on UNIX and "\" on Windows.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">java.class.path</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Path used to find directories and JAR archives containing class files. Elements of the class path are separated by a platform-specific character specified in the path.separator property.</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">java.home</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Installation directory for Java Runtime Environment (JRE)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">java.vendor</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">JRE vendor name</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">java.vendor.url</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">JRE vendor URL</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">java.version</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">JRE version number</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">line.separator</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Sequence used by operating system to separate lines in text files</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">os.arch</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Operating system architecture</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">os.name</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Operating system name</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">os.version</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Operating system version</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">path.separator</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Path separator character used in java.class.path</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">user.dir</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">User working directory</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">user.home</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">User home directory</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">user.name</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">User account name</p></td> </tr> </tbody> </table> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="threads">Threads</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">import java.text.DateFormat import java.util.* import kotlin.test.Test class ThreadsTest { @Test fun `threads test`() { //java.lang.Thread représente le thread fondamentale de l'API java //il existe deux manière de définir un thread //1) étendre la classe Thread ou une lambda en kotlin //2) implémenter l'interface Runnable, // puis passer une instance de cet objet Runnable au constructeur de Thread. val list1: List<Int> = List( size = 45, init = { (1..31).random() } ) println("list1$list1") //facon 1 val t = Thread { Collections.sort(list1) println("list1 sorted$list1") } t.start() val list2 = List( size = 45, init = { (1..31).random() } ) println("list2$list2") //facon 2 val sorter = BackgroundSorter(list2) sorter.start() //priorité des threads //tant qu'un thread de niveau de priorité supérieure n'est pas fini //alors celui de niveau inférieur ne peut s'exécuter //on définit un thread avec une priorité inférieur à la normale t.setPriority(Thread.NORM_PRIORITY - 1) //ici on définit un thread avec une priorité inférieur à la priorité //du thread courant t.setPriority(Thread.currentThread().getPriority() - 1) //Thread.yield() fait une pause pour laisser les autres threads de meme priorité s'exécuter } class BackgroundSorter(private val l: List<Int>) : Thread() { override fun run() { Collections.sort(l) println("list2 sorted$l") } } //pour l'arrêt du thread, plutôt qu'utiliser la fonction Thread.stop() // qui laisse la memoire dans un état non controlé. //utiliser la méthode tel que l'exemple pleaseStop() class DummyClock( private val df: DateFormat = DateFormat.getTimeInstance(DateFormat.MEDIUM), private var keepRunning: Boolean = true ) : Thread() { init { isDaemon = true start() } override fun run() { while (keepRunning) { println(df.format(Date())) try { sleep(1000) } catch (e: InterruptedException) { println(e.message) } } } fun pleaseStop() { keepRunning = false } } //java.util.Timer //java.util.TimerTask //ces classes permettent l'exécution de taches répétitives @Test fun `Timer et TimerTask test`() { DummyClock() } }</code></pre> </div> </div> <div class="paragraph"> <p><a href="#toc">table des matières</a></p> </div> </div> </div> <div class="sect1"> <h2 id="regex">Expressions Régulières</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">import java.util.* import java.util.regex.Matcher import java.util.regex.Pattern import java.util.stream.Collectors import kotlin.test.Test import kotlin.test.assertEquals class RegularExpressionsTest { @Test fun `expressions régulières`() { val p: Pattern = Pattern.compile("honou?r") val caesarUK = "For Brutus is an honourable man" val mUK: Matcher = p.matcher(caesarUK) assertEquals(true, mUK.find(), "Should matches UK spelling") val caesarUS = "For Brutus is an honorable man" val mUS: Matcher = p.matcher(caesarUS) assertEquals(true, mUS.find(), "Should matches US spelling") } @Test fun `expressions régulières plus complexes`() { //Notez que nous devons utiliser \\ car nous avons besoin d'un littéral \ //et Java utilise un seul \ comme caractère d'échappement var pStr = "\\d" // Un chiffre numérique var text = "Apollo 13" var p = Pattern.compile(pStr) var m = p.matcher(text) print(pStr + " matches " + text + "? " + m.find()) println(" ; match: " + m.group()) pStr = "[a..zA..Z]" //N'importe quelle lettre p = Pattern.compile(pStr) m = p.matcher(text) print(pStr + " matches " + text + "? " + m.find()) println(" ; match: " + m.group()) //N'importe quel nombre de lettres, qui doivent toutes être comprises entre 'a' et 'j' //mais peut-être en majuscule ou en minuscule. pStr = "([a..jA..J]*)" p = Pattern.compile(pStr) m = p.matcher(text) print(pStr + " matches " + text + "? " + m.find()) println(" ; match: " + m.group()) text = "abacab" //'a' suivi de quatre caractères quelconques, suivi de 'b' pStr = "a....b" p = Pattern.compile(pStr) m = p.matcher(text) print(pStr + " matches " + text + "? " + m.find()) println(" ; match: " + m.group()) } @Test fun `Quelles chaînes correspondent à la regex ?`() { val pStr = "\\d" // Un chiffre numérique val p = Pattern.compile(pStr) val ls: List<String> = Arrays.asList("Cat", "Dog", "Ice-9", "99 Luftballoons") val containDigits: List<String> = ls.stream() .filter(p.asPredicate()) .collect(Collectors.toList()) assert(containDigits.contains("Ice-9")) assert(containDigits.contains("99 Luftballoons")) assertEquals(2, containDigits.size) } }</code></pre> </div> </div> <div class="sect2"> <h3 id="_tableau_regex_metacharacters">Tableau regex metacharacters</h3> <table class="tableblock frame-all grid-all stretch"> <colgroup> <col style="width: 33.3333%;"> <col style="width: 33.3333%;"> <col style="width: 33.3334%;"> </colgroup> <tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">Metacharacter</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">fonctionnalité</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Notes</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">?</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Caractère facultatif—zéro ou une instance</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">*</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Zéro ou plus du caractère précédent</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">+</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un ou plusieurs des caractères précédents</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">{M,N}</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Entre M et N instances du caractère précédent</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\d</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un chiffre</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\D</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un caractère non numérique</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\w</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un caractère de mot</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Chiffres, lettres et _</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\W</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un caractère sans mot</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\s</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un caractère d’espacement</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\S</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un caractère non blanc</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\n</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Caractère de saut de ligne</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">\t</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Caractère de tabulation</p></td> <td class="tableblock halign-left valign-top"></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">.</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Un caractère n’importe lequel</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">N’inclut pas la nouvelle ligne en Java</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">[ ]</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tout caractère contenu entre crochets</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Appelé une classe de caractères</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">[^ ]</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Tout caractère non contenu entre crochets</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Appelé une classe de caractères inversée</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">( )</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Construire un groupe d’éléments de motif</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Appelé un groupe (ou groupe de capture)</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">|</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Définir des possibilités alternatives</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Implémente le OU logique</p></td> </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">^</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">Début de chaîne $ Fin de chaîne</p></td> <td class="tableblock halign-left valign-top"></td> </tr> </tbody> </table> <div class="paragraph"> <p>compléter <a href="https://www.codeurjava.com/2015/05/les-expressions-regulieres-avec-regex.html">avec</a></p> </div> </div> </div> </div> https://pages-content.github.io//blog/2022/0047_memo_gradle_post.html Mon, 23 May 2022 00:00:00 +0000 blog/2022/0047_memo_gradle_post.html <div id="toc" class="toc"> <div id="toctitle">Sommaire</div> <ul class="sectlevel1"> <li><a href="#_afficher_laide">1. Afficher l’aide</a></li> <li><a href="#_définir_la_propriété_système_de_la_jvm_d_system_prop">2. Définir la propriété système de la JVM : <code>-D, --system-prop</code></a></li> <li><a href="#_définir_la_propriété_du_projet_pour_le_build_script_pmypropmyvalue">3. Définir la propriété du projet pour le build script : <code>-Pmyprop=myvalue</code></a></li> <li><a href="#_spécifie_le_répertoire_de_démarrage_de_gradle_la_valeur_par_défaut_est_le_répertoire_actuel">4. Spécifie le répertoire de démarrage de Gradle. La valeur par défaut est le répertoire actuel.</a></li> <li><a href="#_surcharger_la_property_param_component_par_la_ligne_de_commande">5. Surcharger la property 'param_component' par la ligne de commande :</a></li> <li><a href="#_ajouter_un_dossier_à_un_source_set_dans_un_projet_normal_avec_le_kotlin_dsl">6. Ajouter un dossier à un source-set dans un projet normal avec le kotlin dsl</a></li> <li><a href="#_ajouter_un_dossier_à_un_source_set_dans_un_projet_android_avec_le_groovy_dsl">7. Ajouter un dossier à un source-set dans un projet android avec le groovy dsl</a></li> <li><a href="#_éviter_de_construire_et_tester_un_sous_module">8. Éviter de construire et tester un sous module</a></li> <li><a href="#_tar_un_dossier">9. Tar un dossier</a></li> <li><a href="#_afficher_les_dépendances_dun_build">10. Afficher les dépendances d’un build</a></li> <li><a href="#_exemple_dutilisation_de_reduce_concaténation_dune_list_dans_un_string">11. Exemple d’utilisation de reduce : concaténation d’une list dans un string</a></li> <li><a href="#_récupérer_la_description_dune_tache_en_particulier">12. Récupérer la description d’une tache en particulier</a></li> <li><a href="#_pour_lancer_une_tache_depuis_le_workingdir_root_alors_préfixer_la_tache_pas_un">13. Pour lancer une tache depuis le workingDir root, alors préfixer la tache pas un <code>:</code></a></li> <li><a href="#_pour_relancer_les_taches_qui_ont_échouées_utiliser_loption_rerun_tasks">14. Pour relancer les taches qui ont échouées, utiliser l’option <code>--rerun-tasks</code></a></li> <li><a href="#_lancer_une_tâche_dans_un_projet_spécifique_depuis_un_autre_répertoire">15. Lancer une tâche dans un projet spécifique depuis un autre répertoire</a></li> </ul> </div> <div class="sect1"> <h2 id="_afficher_laide">1. Afficher l’aide</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew --help</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_définir_la_propriété_système_de_la_jvm_d_system_prop">2. Définir la propriété système de la JVM : <code>-D, --system-prop</code></h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew -Dmyprop=myvalue #ou ./gradlew --system-prop myvalue</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_définir_la_propriété_du_projet_pour_le_build_script_pmypropmyvalue">3. Définir la propriété du projet pour le build script : <code>-Pmyprop=myvalue</code></h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew -Pmyprop=myvalue #ou ./gradlew --project-prop myvalue</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_spécifie_le_répertoire_de_démarrage_de_gradle_la_valeur_par_défaut_est_le_répertoire_actuel">4. Spécifie le répertoire de démarrage de Gradle. La valeur par défaut est le répertoire actuel.</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew -p ~/src/next_startup #ou ./gradlew --project-dir ~/src/next_startup</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_surcharger_la_property_param_component_par_la_ligne_de_commande">5. Surcharger la property 'param_component' par la ligne de commande :</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew -Pparam_component=CUSTOM_VALUE</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_ajouter_un_dossier_à_un_source_set_dans_un_projet_normal_avec_le_kotlin_dsl">6. Ajouter un dossier à un source-set dans un projet normal avec le kotlin dsl</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">sourceSets { getByName("test"){ java.srcDir("src/scripts/groovy") } getByName("test"){ java.srcDir("src/scripts/kscript") } getByName("test"){ java.srcDir("src/test/javascript") } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_ajouter_un_dossier_à_un_source_set_dans_un_projet_android_avec_le_groovy_dsl">7. Ajouter un dossier à un source-set dans un projet android avec le groovy dsl</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">android { sourceSets { main.java.srcDirs += "src/main/../../../../ceelo/domain/src/main/java/" test.java.srcDirs += "src/test/../../../../ceelo/domain/src/test/java/" } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_éviter_de_construire_et_tester_un_sous_module">8. Éviter de construire et tester un sous module</h2> <div class="sectionbody"> <div class="paragraph"> <p>gradle build -x :excluded-module:check -x :excluded-module:assemble -x :excluded-module:build</p> </div> <div class="listingblock"> <div class="title">Déplacer des fichiers</div> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">tasks.register("moveWebappNode") { doLast { ant.withGroovyBuilder { "move"( "webapp/node_modules" to "$rootDir/webapp-src/node_modules", ) } } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_tar_un_dossier">9. Tar un dossier</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">tasks.register<Tar>("tarWebapp") { dependsOn("moveWebappNpm") group = WEBAPP description = "tar webapp" doLast { setOf( "build", "target", "node_modules" ).forEach { dir -> exclude { it.name .dir } } archiveFileName.set("webapp.tar") destinationDirectory.set(File("${rootDir.absolutePath}$sep$WEBAPP_SRC")) } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_afficher_les_dépendances_dun_build">10. Afficher les dépendances d’un build</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">tasks.register("printDependencies") { description = "print project dependencies" group = WEBAPP doLast { println("${project.name} dependencies") mutableMapOf<String, Map<String, String>>( "buildDependencies" to buildDependencies, "domainDeps" to domainDeps, "domainTestDeps" to domainTestDeps, ).apply { putAll(appModules) } .forEach { module -> if (module.value.isNotEmpty()) { println("${module.key}:") module.value.forEach { println(dependency(it)) } println() } } } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_exemple_dutilisation_de_reduce_concaténation_dune_list_dans_un_string">11. Exemple d’utilisation de reduce : concaténation d’une list dans un string</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">tasks.register("printWebappSrc") { description = "print webapp sources" group = WEBAPP doLast { webAppSrc .reduce { acc, s -> "$acc\n\t$s" } .run { println("$WEBAPP_SRC: $this\n") } } }</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_récupérer_la_description_dune_tache_en_particulier">12. Récupérer la description d’une tache en particulier</h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew -q help --task foo</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_pour_lancer_une_tache_depuis_le_workingdir_root_alors_préfixer_la_tache_pas_un">13. Pour lancer une tache depuis le workingDir root, alors préfixer la tache pas un <code>:</code></h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew :foo</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_pour_relancer_les_taches_qui_ont_échouées_utiliser_loption_rerun_tasks">14. Pour relancer les taches qui ont échouées, utiliser l’option <code>--rerun-tasks</code></h2> <div class="sectionbody"> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew check --rerun-tasks</code></pre> </div> </div> </div> </div> <div class="sect1"> <h2 id="_lancer_une_tâche_dans_un_projet_spécifique_depuis_un_autre_répertoire">15. Lancer une tâche dans un projet spécifique depuis un autre répertoire</h2> <div class="sectionbody"> <div class="paragraph"> <p>L’option <code>-p</code> (ou <code>--project-dir</code>) permet de spécifier le chemin d’accès à un projet Gradle et d’y exécuter une tâche, même si le répertoire courant est différent.</p> </div> <div class="paragraph"> <p>Par exemple, pour lancer la tâche <code>build</code> du projet situé dans <code>~/projets/mon-autre-projet</code> tout en étant dans un autre répertoire :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">./gradlew -p ~/projets/mon-autre-projet build</code></pre> </div> </div> <div class="paragraph"> <p>Cela est particulièrement utile pour scripter des actions sur plusieurs projets depuis un emplacement central.</p> </div> <hr> <div class="ulist"> <div class="title">voir aussi :</div> <ul> <li> <p><a href="https://docs.gradle.org/current/userguide/command_line_interface.html#sec:command_line_warnings">ref</a></p> </li> <li> <p><a href="https://docs.gradle.org/current/userguide/command_line_interface.html#sec:command_line_options">ref</a></p> </li> <li> <p><a href="https://stackoverflow.com/a/36178581/837404">discussion</a></p> </li> </ul> </div> </div> </div> https://pages-content.github.io//blog/2022/0038_training_kotlin_enum_sealed_class_post.html Tue, 17 May 2022 00:00:00 +0000 blog/2022/0038_training_kotlin_enum_sealed_class_post.html <div class="paragraph"> <p>les sealed classes, ne sont pas des énumérations(mot clef:enum).<br> Venant de Java, vous pourriez être tenté de surcharger votre énumération d’apport de fonctionnalités:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-java" data-lang="java">enum PizzaOrderStatus { ORDER_RECEIVED, PIZZA_BEING_MADE, OUT_FOR_DELIVERY, COMPLETED; public PizzaOrderStatus nextStatus() { switch (this) { case ORDER_RECEIVED: return PIZZA_BEING_MADE; case PIZZA_BEING_MADE: return OUT_FOR_DELIVERY; case OUT_FOR_DELIVERY: return COMPLETED; case COMPLETED:return COMPLETED; } } }</code></pre> </div> </div> <div class="paragraph"> <p>Au lieu de cela, vous pouvez utiliser la sealed classe :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">sealed class PizzaOrderStatus(protected val orderId: Int) { abstract fun nextStatus() : PizzaOrderStatus class OrderReceived(orderId: Int) : PizzaOrderStatus(orderId) { override fun nextStatus(): PizzaOrderStatus { return PizzaBeingMade(orderId) } } class PizzaBeingMade(orderId: Int) : PizzaOrderStatus(orderId) { override fun nextStatus(): PizzaOrderStatus { return OutForDelivery(orderId) } } class OutForDelivery(orderId: Int) : PizzaOrderStatus(orderId) { override fun nextStatus(): PizzaOrderStatus { return Completed(orderId) } } class Completed(orderId: Int) : PizzaOrderStatus(orderId) { override fun nextStatus(): PizzaOrderStatus { return this } } }</code></pre> </div> </div> <div class="paragraph"> <p>L’avantage de cette approche est que nous pouvons maintenant transmettre des données avec le statut:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">var status: PizzaOrderStatus = OrderReceived(123) while (status !is Completed) { status = when (status) { is OrderReceived -> status.nextStatus() is PizzaBeingMade -> status.nextStatus() is OutForDelivery -> status.nextStatus() is Completed -> status } }</code></pre> </div> </div> <div class="paragraph"> <p>En général, les sealed classes sont bonnes si vous voulez avoir des données associées à un Etat.</p> </div> https://pages-content.github.io//blog/2022/0036_training_kotlin_post.html Thu, 12 May 2022 00:00:00 +0000 blog/2022/0036_training_kotlin_post.html <div class="sect1"> <h2 id="_mind_map">Mind map</h2> <div class="sectionbody"> <div class="paragraph"> <p><span class="image"><img src="../../diagram/training_kotlin.png" alt="training_kotlin"></span></p> </div> </div> </div> <div class="sect1"> <h2 id="_programmation_fonctionnelle">Programmation fonctionnelle</h2> <div class="sectionbody"> <div class="paragraph"> <p>Les execrices sont tirés du livre:<br> Functional programing in kotlin by tutorials<br> Written by Massimo Carli<br> repo: <a href="https://github.com/kodecocodes/fpk-materials" class="bare">https://github.com/kodecocodes/fpk-materials</a></p> </div> <div class="sect2"> <h3 id="_syntaxe">Syntaxe</h3> <div class="sect3"> <h4 id="_firstprogramtest">FirstProgramTest</h4> <div class="paragraph"> <p>notions: affichage écran, fonction<br> FirstProgramTest: <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/programming/FirstProgramTest.kt">source</a><br></p> </div> </div> <div class="sect3"> <h4 id="_concatfunctiontest">ConcatFunctionTest</h4> <div class="paragraph"> <p>notions: memoire, variable, valeur, objet, extension de fonction<br> ExampleUnitTest: <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/programming/ConcatFunctionTest.kt">source</a><br></p> </div> </div> <div class="sect3"> <h4 id="_birthdaymessagetestoutput">BirthdayMessageTestOutput</h4> <div class="paragraph"> <p>notions: ensembles, boucles<br> <a href="https://developer.android.com/codelabs/basic-android-kotlin-training-first-kotlin-program?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-one%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-first-kotlin-program">Introduction to kotlin</a><br> BirthdayMessageTestOutput: <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/programming/BirthdayMessageTestOutput.kt">source</a><br></p> </div> </div> </div> <div class="sect2"> <h3 id="_cours_de_kotlin">Cours de kotlin</h3> <div class="videoblock"> <div class="content"> <iframe src="https://www.youtube.com/embed/YRjY3jRrQYY?rel=0" frameborder="0" allowfullscreen></iframe> </div> </div> </div> <div class="sect2"> <h3 id="_tutotiel_sur_les_collections_en_java">Tutotiel sur les collections en java</h3> <div class="paragraph"> <p><a href="https://docs.oracle.com/javase/tutorial/collections/index.html" target="_blank" rel="noopener">Collections</a></p> </div> <div class="paragraph"> <p>Le coeur des interfaces de collection<br> <span class="image"><img src="../../img/0036_training_kotlin_post/colls-coreInterfaces.gif" alt="Collections"></span><br></p> </div> </div> <div class="sect2"> <h3 id="_basiques_fonctionnels">Basiques fonctionnels</h3> <div class="sect3"> <h4 id="_declarative_x_imperative_approach">Declarative X imperative approach</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package functional import kotlin.test.Test import kotlin.test.assertEquals class DeclarativeTests { val input = listOf( "123", "abc", "1ds", "987", "abdf", "1d3", "de1", "88", "101" ) fun imperativeSum(list: List<String>): Int { var sum = 0 for (item in list) { try { sum += item.toInt() } catch (_: NumberFormatException) { } } return sum } @Test fun `test imperative approach`() { imperativeSum(input).run { println("Sum $this") assertEquals(1299, this) } } fun isValidNumber(s: String) = try { s.toInt() true } catch (_: NumberFormatException) { false } fun declarativeSum(list: List<String>) = list .filter(::isValidNumber) .map(String::toInt) .sum() @Test fun `test declarative approach`() { assertEquals(1299, declarativeSum(input).apply { println("Sum $this") }) } }</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_exercice_1_1">Exercice 1.1</h4> <div class="paragraph"> <p>Implémenter la fonction sumInRange, qui additionne les valeurs dans<br> une List<String> dans un intervalle donné. La signature est :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">fun sumInRange(input: List<String>, range: IntRange): Int</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">@Test fun `Exercise 1_1`() { assertEquals(4, sumInRange( listOf("1", "10", "a", "7", "ad2", "3"), 1..5 ).apply { println("sumInRange 1..5: $this") } ) }</code></pre> </div> </div> <div class="paragraph"> <p>Essayez-le et vérifiez votre réponse avec la <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/functional/DeclarativeTests.kt">solution</a>.</p> </div> </div> <div class="sect3"> <h4 id="_higher_order_functions">Higher-order functions</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package functional import java.io.ByteArrayOutputStream import java.io.PrintStream import java.lang.System.* import java.lang.Thread.sleep import kotlin.math.sign import kotlin.test.Test import kotlin.test.assertEquals class BasicsHOFTests { val ONE_SECOND = 1000L @Test fun `high order function`() { //capture de la sortie standard val standardOut: PrintStream? = out val outputStreamCaptor = ByteArrayOutputStream() setOut(PrintStream(outputStreamCaptor)) 3.times { println("Hello") } assertEquals( buildString { repeat(3) { append("Hello\n") } deleteAt(length - 1) }, outputStreamCaptor .toString() .trim() ) //libération de la sortie standard setOut(standardOut) } fun Int.times1(fn: () -> Unit) { for (i in 1..this) { fn() } } fun Int.times2(fn: () -> Unit) { for (i in 1..this) fn() } fun Int.times3(fn: () -> Unit) = (1..this).forEach { fn() } fun Int.times4(fn: () -> Unit) = repeat((1..this).count()) { fn() } fun Int.times(fn: () -> Unit) = (1..this).forEach { _ -> fn() } }</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_exercice_1_2">Exercice 1.2</h4> <div class="paragraph"> <p>Implémenter chrono, qui accepte une fonction de type <code>() →</code><br> Unit en entrée et renvoie le temps passé à l’exécuter. La signature est :<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">fun chrono(fn : () -> Unité) : Long</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">@Test fun `Exercise 1_2`() { val waitOneSec = { sleep(ONE_SECOND) } chrono(waitOneSec).apply { println("chrono: $this") assertEquals(1, sign) } }</code></pre> </div> </div> <div class="paragraph"> <p>Essayez-le et vérifiez votre réponse avec la <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/functional/BasicsHOFTests.kt">solution</a>.</p> </div> </div> <div class="sect3"> <h4 id="_composition">Composition</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package functional import kotlin.test.Test import kotlin.test.assertEquals fun double(x: Int): Int = 2 * x fun square(x: Int): Int = x * x fun squareAndDouble1(x: Int) = double(square(x)) infix fun <A, B, C> ((A) -> B).compose(g: (B) -> C) : (A) -> C = { a -> g(this(a)) } class CompositionTests { @Test fun composition_impure() { assertEquals(200, double(square(10))) assertEquals(200, squareAndDouble1(10)) } @Test fun composition_pure() { val squareAndDouble = ::square compose ::double assertEquals(200, squareAndDouble(10)) } }</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_pure_functions_and_testability">Pure functions and testability</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package functional import java.io.ByteArrayOutputStream import java.io.PrintStream import java.lang.System.out import java.lang.System.setOut import kotlin.test.Test import kotlin.test.assertEquals var count = 0 //impure car une variable global subit un effet de bord fun impure(value: Int): Int { count++ return value + count } //impure car utilisation de la sortie standard qui fait muter le system fun addOneAndLog(x: Int): Int { val result = x + 1 println("New Value is $result") return result } //pure fun addOne(x: Int) = (x + 1).run { Pair(this, "New Value is $this") } class PureTests { @Test fun `impure fonction`() { assertEquals(3, impure(2)) val standardOut = out val outputStreamCaptor = ByteArrayOutputStream() setOut(PrintStream(outputStreamCaptor)) addOneAndLog(3) assertEquals( "New Value is 4", outputStreamCaptor .toString() .trim() ) setOut(standardOut) } @Test fun `pure fonction`() { addOne(3).run { assertEquals(4, first) assertEquals("New Value is 4", second) } } }</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_exception_handling">Exception handling</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">package functional import org.junit.jupiter.api.assertThrows import kotlin.Result.Companion.failure import kotlin.Result.Companion.success import kotlin.test.Test import kotlin.test.assertEquals //NumberFormatException est un effet de bord qui rend la fonction impure fun strToInt(str: String) = str.toInt() //pure fun strToIntOrNull(str: String) = try { str.toInt() } catch (nfe: NumberFormatException) { null } //pure avec gestion de l'exception plus élégante fun strToIntResult(str: String): Result<Int> = try { success(str.toInt()) } catch (nfe: NumberFormatException) { failure(nfe) } class ExceptionHandlingTests { @Test fun impure() { assertThrows<NumberFormatException> { strToInt("foo") } assertEquals(1, strToInt("1")) } @Test fun pure() { assertEquals(null, strToIntOrNull("foo")) assertEquals(1, strToIntOrNull("1")) } @Test fun `pure avec result`() { assertEquals(1, strToIntResult("1").getOrNull()) assertEquals( "For input string: \"foo\"", strToIntResult("foo") .exceptionOrNull() ?.message ) } }</code></pre> </div> </div> </div> </div> <div class="sect2"> <h3 id="_points_clés">Points clés</h3> <div class="ulist"> <ul> <li> <p>Alors que la programmation orientée objet signifie programmer avec des objets, la programmation fonctionnelle signifie programmer avec des fonctions. Vous décomposez un problème en plusieurs sous-problèmes, que vous modélisez avec les fonctions.</p> </li> <li> <p>Les fonctions d’ordre supérieur acceptent d’autres fonctions en entrée ou renvoient d’autres fonctionnent comme des valeurs de retour. La théorie des catégories est la théorie de la composition, et vous l’utilisez pour comprendre comment composer vos fonctions dans un programme de travail. La valeur de sortie d’une fonction pure ne dépend que de ses paramètres d’entrée, et elle n’a pas d’effets secondaires.</p> </li> <li> <p>Un effet secondaire est quelque chose qu’une fonction fait au monde extérieur. Ce peut être un journal dans la sortie standard ou la modification de la valeur d’une variable globale. La programmation fonctionnelle fonctionne pour les fonctions pures, mais elle fournit également les des outils pour transformer des fonctions impures en fonctions pures. Vous pouvez rendre une fonction impure pure en déplaçant les effets pour les rendre partie de la valeur de retour.</p> </li> <li> <p>La programmation fonctionnelle est une question de composition. La gestion des erreurs est un cas typique d’effets secondaires, et Kotlin vous donne les outils pour les gérer de manière fonctionnelle.</p> </li> </ul> </div> </div> <div class="sect2"> <h3 id="_approfondir_java8_lambdas_expressions_et_interface_fonctionnelles">Approfondir java8: lambdas expressions et interface fonctionnelles</h3> <div class="videoblock"> <div class="content"> <iframe src="https://www.youtube.com/embed/20waNRw6wMA?rel=0&list=PLzzeuFUy_Cng0wZhqbnkvWAW0d2fdVfyQ" frameborder="0" allowfullscreen></iframe> </div> </div> </div> <div class="sect2"> <h3 id="_théorie_des_catégories">Théorie des catégories</h3> <div class="paragraph"> <p>La théorie mathématique des catégories:</p> </div> <div class="videoblock"> <div class="content"> <iframe src="https://www.youtube.com/embed/LVHoROSF3KA?rel=0" frameborder="0" allowfullscreen></iframe> </div> </div> </div> <div class="sect2"> <h3 id="_fondamentaux_des_fonctions">Fondamentaux des fonctions</h3> <div class="sect3"> <h4 id="_exercice_2_1">Exercice 2.1</h4> <div class="paragraph"> <p>Pouvez-vous écrire un exemple de fonction mappant des valeurs distinctes<br> dont le domaine à des valeurs non distinctes dans la plage, comme f(b) et f(c) dans la figure ci-dessous ?<br></p> </div> <div class="paragraph"> <p>Essayez-le, puis vérifiez le projet de défi pour une solution à voir comment tu as fait.<br> Vous trouverez des conseils et une explication en suivant le lien vers la <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/functional/BasicsHOFTests.kt">solution</a>.<br></p> </div> </div> <div class="sect3"> <h4 id="_exercise_2_2">Exercise 2.2</h4> <div class="paragraph"> <p>Can you write the inverse function of twice ?<br> What are the domain and range for the inverse function?<br> Check out the challenge project and Appendix B for the solution.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">fun chrono(fn : () -> Unité) : Long</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-kotlin" data-lang="kotlin">@Test fun `Exercise 1_2`() { val waitOneSec = { sleep(ONE_SECOND) } chrono(waitOneSec).apply { println("chrono: $this") assertEquals(1, sign) } }</code></pre> </div> </div> <div class="paragraph"> <p>Essayez-le et vérifiez votre réponse avec la <a href="https://github.com/cheroliv/cheroliv.com/blob/master/codes/src/test/kotlin/functional/BasicsHOFTests.kt">solution</a>.</p> </div> </div> </div> </div> </div> https://pages-content.github.io//blog/2022/0031_memo_design_system_post.html Sun, 9 Jan 2022 00:00:00 +0000 blog/2022/0031_memo_design_system_post.html <div class="sect1"> <h2 id="_tools">Tools</h2> <div class="sectionbody"> <div class="dlist"> <div class="title"><strong>Illustrations</strong></div> <dl> <dt class="hdlist1"><a href="https://undraw.co/">undraw.co</a></dt> <dd> <p>Illustrations open source pour toutes les idées que vous pouvez imaginer et créer.</p> </dd> <dt class="hdlist1"><a href="https://absurd.design/">absurd.design</a></dt> <dd> <p>Des illustrations absurdes qui ont du sens.</p> </dd> <dt class="hdlist1"><a href="https://drawkit.com/">drawkit.com</a></dt> <dd> <p>Magnifiques illustrations gratuites. Mises à jour hebdomadaires.</p> </dd> <dt class="hdlist1"><a href="https://icons8.com/">icons8.com</a></dt> <dd> <p>Icons, illustrations, photos, music, and design tools.</p> </dd> <dt class="hdlist1"><a href="https://blush.design/">blush.design</a></dt> <dd> <p>Icônes, illustrations, photos, musique et outils de conception.</p> </dd> <dt class="hdlist1"><a href="https://www.humaaans.com/">humaaans.com</a></dt> <dd> <p>Mélangez et assortissez des illustrations de personnes avec une bibliothèque de conception.</p> </dd> </dl> </div> <div class="dlist"> <div class="title"><strong>Couleurs</strong></div> <dl> <dt class="hdlist1"><a href="https://coolors.co/">coolors.co</a></dt> <dd> <p>Le générateur de schémas de couleurs ultra-rapide !</p> </dd> </dl> </div> <div class="dlist"> <div class="title"><strong>Tendances</strong></div> <dl> <dt class="hdlist1"><a href="https://fr.pinterest.com">pinterest</a></dt> <dd> <p>Découverte visuelle d’idées : images, vidéos, collections thématiques.</p> </dd> <dt class="hdlist1"><a href="https://dribbble.com">Dribble</a></dt> <dd> <p>Plateforme pour designers partageant leurs créations et interagissant.</p> </dd> </dl> </div> <div class="dlist"> <div class="title"><strong>UX/UI et Design Systems</strong></div> <dl> <dt class="hdlist1"><a href="https://material.io/">Google Material Design</a></dt> <dd> <p>Système de design de Google pour des interfaces utilisateur unifiées et adaptables.</p> </dd> <dt class="hdlist1"><a href="https://developer.apple.com/design/human-interface-guidelines/">Apple Human Interface Guidelines</a></dt> <dd> <p>Recommandations d’Apple pour concevoir des applications iOS et macOS intuitives.</p> </dd> <dt class="hdlist1"><a href="https://www.uxpin.com/">UXPin</a></dt> <dd> <p>Plateforme de design et de collaboration pour créer des prototypes et des design systems.</p> </dd> <dt class="hdlist1"><a href="https://www.frontify.com/">Frontify</a></dt> <dd> <p>Plateforme de gestion de marque et de design systems pour assurer la cohérence.</p> </dd> <dt class="hdlist1"><a href="https://designsystemsrepo.com/design-systems/">Design Systems Repo</a></dt> <dd> <p>Collection de ressources et d’exemples de design systems pour l’inspiration.</p> </dd> </dl> </div> <div class="dlist"> <div class="title"><strong>Développement Frontend</strong></div> <dl> <dt class="hdlist1"><a href="https://htmlcheatsheet.com" target="_blank" rel="noopener">htmlcheatsheet.com</a></dt> <dd> <p>HTML Cheatsheet</p> </dd> <dt class="hdlist1"><a href="https://fontawesome.com" target="_blank" rel="noopener">fontawesome.com</a></dt> <dd> <p>bibliothèque d’icones</p> </dd> <dt class="hdlist1"><a href="https://www.toptal.com/designers/htmlarrows/symbols/" target="_blank" rel="noopener">toptal.com/designers/htmlarrows/symbols</a></dt> <dd> <p>Icones natives en HTML</p> </dd> <dt class="hdlist1"><a href="https://css-tricks.com/">CSS-Tricks</a></dt> <dd> <p>Incontournable pour CSS, avec des articles, tutoriels et astuces frontend modernes.</p> </dd> <dt class="hdlist1"><a href="https://www.frontendmentor.io/">Frontend Mentor</a></dt> <dd> <p>Défis de code frontend basés sur des projets réels pour améliorer vos compétences.</p> </dd> <dt class="hdlist1"><a href="https://dev.to/">Dev.to</a></dt> <dd> <p>Communauté de développeurs pour partager des articles, tutoriels et projets.</p> </dd> <dt class="hdlist1"><a href="https://codepen.io/">CodePen</a></dt> <dd> <p>Éditeur de code en ligne et communauté pour partager des extraits de code et des démos.</p> </dd> </dl> </div> <div class="dlist"> <div class="title"><strong>Développement Frontend assisté par IA</strong></div> <dl> <dt class="hdlist1"><a href="https://v0.dev/">v0.dev</a></dt> <dd> <p>v0 convertit les descriptions en langage naturel en code et interface utilisateur.</p> </dd> <dt class="hdlist1"><a href="https://uizard.io/">Uizard</a></dt> <dd> <p>Uizard se concentre sur la transformation de maquettes (images, croquis) en code HTML, CSS et React.</p> </dd> <dt class="hdlist1"><a href="https://www.usegalileo.ai/explore">usegalileo.ai</a></dt> <dd> <p>Galileo AI vous permet de décrire l’interface que vous souhaitez en langage naturel, et l’IA génère des designs Figma éditables.</p> </dd> <dt class="hdlist1"><a href="https://play.teleporthq.io/">TeleportHQ</a></dt> <dd> <p>TeleportHQ est une plateforme de développement front-end low-code qui utilise l’IA pour vous aider à construire et déployer des sites web visuellement.</p> </dd> </dl> </div> </div> </div> https://pages-content.github.io//blog/2020/0029_kubernetes_microk8s_docker_premiers_pas_post.html Tue, 3 Nov 2020 00:00:00 +0000 blog/2020/0029_kubernetes_microk8s_docker_premiers_pas_post.html <div id="preamble"> <div class="sectionbody"> <div class="paragraph"> <p><a href="https://microk8s.io/docs/">doc officiel de microk8s</a><br></p> </div> </div> </div> <div class="sect3"> <h4 id="_installation_du_paquet_microk8s">Installation du paquet microk8s:</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>sudo snap install microk8s --classic --channel=1.19</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_ajout_de_lutilisateur_courrant_au_group_du_processus_microk8s">Ajout de l’utilisateur courrant au group du processus microk8s</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>sudo usermod -a -G microk8s $USER sudo chown -f -R $USER ~/.kube su - $USER</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_afficher_létat_de_microk8s">Afficher l’état de microk8s</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s status --wait-ready</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_acceder_à_kubernetes">Acceder à Kubernetes</h4> <div class="paragraph"> <p>Récuperer les nodes(noeuds):<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s kubectl get nodes</code></pre> </div> </div> <div class="paragraph"> <p>Récuperer les services en cours:<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s kubectl get services</code></pre> </div> </div> <div class="paragraph"> <p>Récuperer les pods en cours:<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s kubectl get pods</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_ajouter_un_alias_à_son_shell">Ajouter un alias à son shell</h4> <div class="sect4"> <h5 id="_pour_zsh">pour zsh</h5> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>touch ~/.zsh_alias; echo "alias kubectl='microk8s kubectl'" >> ~/.zsh_alias;</code></pre> </div> </div> </div> <div class="sect4"> <h5 id="_pour_bash">pour bash</h5> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>touch ~/.bash_alias; echo "alias kubectl='microk8s kubectl'" >> ~/.bash_alias;</code></pre> </div> </div> </div> </div> <div class="sect3"> <h4 id="_installer_des_add_ons">Installer des add-ons</h4> <div class="paragraph"> <p>Pour commencer, il est recommandé d’ajouter la gestion DNS pour faciliter la communication entre les services. Pour les applications nécessitant du stockage, le module complémentaire «stockage» fournit un espace de répertoire sur l’hôte. Ceux-ci sont faciles à configurer:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s enable dns storage</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_démarrer_et_arreter_microk8s">Démarrer et arreter MicroK8s</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s stop</code></pre> </div> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s start</code></pre> </div> </div> <div class="paragraph"> <p>Notez que si vous laissez MicroK8 en marche, il redémarrera automatiquement après un redémarrage. Si vous ne voulez pas que cela se produise, n’oubliez pas de lancer l’arrêt microk8s avant de l’éteindre.</p> </div> </div> <div class="sect3"> <h4 id="_deployer_une_app">Deployer une app</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s kubectl create deployment nginx --image=nginx</code></pre> </div> </div> <div class="paragraph"> <p>Pour vérifier l’état du déploiement:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>microk8s kubectl get pods</code></pre> </div> </div> </div> https://pages-content.github.io//blog/2020/0028_gradle_executer_un_processus_externe_depuis_une_tache_gradle_post.html Mon, 28 Sep 2020 00:00:00 +0000 blog/2020/0028_gradle_executer_un_processus_externe_depuis_une_tache_gradle_post.html <div class="sect3"> <h4 id="_gradle_kotlin_dsl">Gradle-Kotlin-DSL:</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>open class PrintHerokuVersion : Exec() { init { this.workingDir = project.rootDir this.commandLine("/snap/bin/heroku", "-v") this.standardOutput = ByteArrayOutputStream() } } project.tasks.register<PrintHerokuVersion>("printHerokuVersion") project.tasks.withType<PrintHerokuVersion> { doLast { logger.info(standardOutput.toString()) } }</code></pre> </div> </div> <div class="paragraph"> <p>Pour exécuter la tâche:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ ./gradlew pHV</code></pre> </div> </div> </div> <div class="sect3"> <h4 id="_gradle_groovy_dsl">Gradle-Groovy-DSL:</h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>task printHerokuVersionGroovy(type: Exec) { workingDir(project.projectDir) commandLine("/snap/bin/heroku", "-v") standardOutput = new ByteArrayOutputStream() doLast { logger.info(standardOutput.toString()) } }</code></pre> </div> </div> <div class="paragraph"> <p>Pour exécuter la tâche:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ ./gradlew pHVG</code></pre> </div> </div> </div> https://pages-content.github.io//blog/2020/0027_kotlin_not_implemented_exception_not_implemented_error_post.html Sun, 27 Sep 2020 00:00:00 +0000 blog/2020/0027_kotlin_not_implemented_exception_not_implemented_error_post.html <div class="paragraph"> <p>NotImplementedException NotImplementedError, utilité pour les tests, ça permet de savoir, où on en est, et la cause du fail.<br> Pas encore implémenté, permet de lever la bonne exception.<br> Il y a :<br> <a href="http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/NotImplementedException.html">org.apache.commons.lang3.NotImplementedException</a><br> <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-not-implemented-error/">kotlin.NotImplementedError</a><br></p> </div> https://pages-content.github.io//blog/2020/0026_untar_post.html Sat, 26 Sep 2020 00:00:00 +0000 blog/2020/0026_untar_post.html <div class="sect3"> <h4 id="_liens_interserver_net">Liens: <a href="https://www.interserver.net/tips/kb/extract-tar-gz-files-using-linux-command-line/">interserver.net</a></h4> </div> https://pages-content.github.io//blog/2020/0025_gradle_rejouer_les_tests_meme_lorsque_les_tests_sont_UP-TO-DATE_post.html Fri, 25 Sep 2020 00:00:00 +0000 blog/2020/0025_gradle_rejouer_les_tests_meme_lorsque_les_tests_sont_UP-TO-DATE_post.html <div class="paragraph"> <p>ajouter l’argument --rerun-tasks à la ligne commande.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ ./gradlew test --rerun-tasks</code></pre> </div> </div> https://pages-content.github.io//blog/2020/0024_docker_n_installe_pas_l_application_mais_tire_la_plutot_post.html Thu, 24 Sep 2020 00:00:00 +0000 blog/2020/0024_docker_n_installe_pas_l_application_mais_tire_la_plutot_post.html <div class="sect3"> <h4 id="_source_hackernoon_com">source: <a href="https://hackernoon.com/dont-install-postgres-docker-pull-postgres-bee20e200198">hackernoon.com</a></h4> </div> https://pages-content.github.io//blog/2020/0023_gherkin_en_francais_post.html Wed, 23 Sep 2020 00:00:00 +0000 blog/2020/0023_gherkin_en_francais_post.html <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-json" data-lang="json">{"fr": { "and": [ "* ", "Et que ", "Et qu'", "Et " ], "background": [ "Contexte" ], "but": [ "* ", "Mais que ", "Mais qu'", "Mais " ], "examples": [ "Exemples" ], "feature": [ "Fonctionnalité" ], "given": [ "* ", "Soit ", "Sachant que ", "Sachant qu'", "Sachant ", "Etant donné que ", "Etant donné qu'", "Etant donné ", "Etant donnée ", "Etant donnés ", "Etant données ", "Étant donné que ", "Étant donné qu'", "Étant donné ", "Étant donnée ", "Étant donnés ", "Étant données " ], "name": "French", "native": "français", "rule": [ "Règle" ], "scenario": [ "Exemple", "Scénario" ], "scenarioOutline": [ "Plan du scénario", "Plan du Scénario" ], "then": [ "* ", "Alors ", "Donc " ], "when": [ "* ", "Quand ", "Lorsque ", "Lorsqu'" ] } }</code></pre> </div> </div> https://pages-content.github.io//blog/2020/0022_gradle_cli_surcharger_un_parametre_post.html Tue, 22 Sep 2020 00:00:00 +0000 blog/2020/0022_gradle_cli_surcharger_un_parametre_post.html <div class="sect4"> <h5 id="_surcharger_un_parametre_par_la_ligne_de_commande">Surcharger un parametre par la ligne de commande :</h5> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ ./gradlew -Pparam_component=CUSTOM</code></pre> </div> </div> </div> https://pages-content.github.io//blog/2020/0021_memo_git_post.html Mon, 21 Sep 2020 00:00:00 +0000 blog/2020/0021_memo_git_post.html <div class="sect1"> <h2 id="_changer_de_depot_distant_dans_git">Changer de depot distant dans git</h2> <div class="sectionbody"> <div class="sect3"> <h4 id="_sources">Sources:</h4> <div class="ulist"> <ul> <li> <p><a href="https://xenovation.com/blog/source-control-management/git/how-to-change-remote-git-repository">xenovation</a></p> </li> <li> <p><a href="https://intellipaat.com/community/3102/git-show-remote-url-how-can-i-determine-the-url-that-a-local-git-repository-was-originally-cloned-from">intellipaat</a></p> </li> </ul> </div> </div> <div class="sect3"> <h4 id="_changer_de_repo_distant_dans_git">changer de repo distant dans git</h4> <div class="paragraph"> <p>afficher l’url du repo distant courrant:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git config --get remote.origin.url</code></pre> </div> </div> <div class="paragraph"> <p>Pour plus d’information sur le depot distant:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git remote show origin</code></pre> </div> </div> <div class="paragraph"> <p>Lister les depots distants</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git remote -v</code></pre> </div> </div> <div class="paragraph"> <p>Changer de dépot distants</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git remote set-url origin git@github.com:kotlin-codes/hands-on-design-pattern-kotlin.git</code></pre> </div> </div> <div class="paragraph"> <p>Ajouter quand le dépot n’existe pas</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git remote add origin git@github.com:kotlin-codes/foo.git</code></pre> </div> </div> <div class="paragraph"> <p>Pusher</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git push -u origin master</code></pre> </div> </div> <div class="paragraph"> <p>ou</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git push -u origin main</code></pre> </div> </div> <div class="paragraph"> <p><em>changement d’adresse ip</em><br> relancer la commande suivante pour que les pushs passent.<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>git remote set-url origin git@github.com:USER_ACCOUNT/PROJECT.git</code></pre> </div> </div> </div> </div> </div> https://pages-content.github.io//blog/2020/0021_aspirer_depuis_une_URL_post.html Sun, 20 Sep 2020 00:00:00 +0000 blog/2020/0021_aspirer_depuis_une_URL_post.html <div class="sect3"> <h4 id="_liens_stackoverflow">Liens: <a href="https://stackoverflow.com/a/1078539/837404">stackoverflow</a></h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ wget -r -k -np http://site.com/docs/manual/</code></pre> </div> </div> <div class="paragraph"> <p>Pour définir un dossier cible ajouter l’argument -P puis donner le chemin.</p> </div> </div> https://pages-content.github.io//blog/2020/0020_creer_un_disk_bootable_post.html Sat, 19 Sep 2020 00:00:00 +0000 blog/2020/0020_creer_un_disk_bootable_post.html <div class="sect3"> <h4 id="_liens_etcher">Liens: <a href="https://www.balena.io/etcher/">etcher</a></h4> </div> https://pages-content.github.io//blog/2020/0019_dezipper_en_CLI_dans_un_dossier_cible_post.html Fri, 18 Sep 2020 00:00:00 +0000 blog/2020/0019_dezipper_en_CLI_dans_un_dossier_cible_post.html <div class="sect3"> <h4 id="_liens_askubuntu">Liens: <a href="https://askubuntu.com/questions/86849/how-to-unzip-a-zip-file-from-the-terminal">askubuntu</a></h4> <div class="paragraph"> <p>Si vous souhaitez extraire vers un dossier de destination particulier, vous pouvez utiliser :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ unzip fichier.zip -d dossier_destination</code></pre> </div> </div> <div class="paragraph"> <p>Si les répertoires source et de destination sont identiques, vous pouvez simplement faire:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ unzip file.zip</code></pre> </div> </div> </div> https://pages-content.github.io//blog/2020/0018_Afficher_la_somme_des_tailles_de_fichier_dans_la_liste_des_r%C3%A9pertoires_post.html Thu, 17 Sep 2020 00:00:00 +0000 blog/2020/0018_Afficher_la_somme_des_tailles_de_fichier_dans_la_liste_des_r%C3%A9pertoires_post.html <div class="sect3"> <h4 id="_liens_stackexchange">Liens: <a href="https://unix.stackexchange.com/questions/72661/show-sum-of-file-sizes-in-directory-listing">stackexchange</a></h4> <div class="listingblock"> <div class="content"> <pre class="highlight"><code>$ du -ach --exclude "./.*" /home/troll/</code></pre> </div> </div> </div> https://pages-content.github.io//blog/2020/0017_detruire_une_branch_sur_github_post.html Wed, 16 Sep 2020 00:00:00 +0000 blog/2020/0017_detruire_une_branch_sur_github_post.html <div class="sect3"> <h4 id="_détruire_une_branch_sur_github">Détruire une branch sur github</h4> </div> <div class="sect3"> <h4 id="_lien_gist">Lien: <a href="https://gist.github.com/cheroliv/921a13ed23ae6d4d66af8d43dd536987">gist</a></h4> </div> https://pages-content.github.io//blog/2020/0016_asciidoc_markdown_memo_post.html Tue, 15 Sep 2020 00:00:00 +0000 blog/2020/0016_asciidoc_markdown_memo_post.html <div class="paragraph"> <div class="title">Pourquoi asciidoc ou markdown ?</div> <p>Ici, je m’oriente vers asciidoc, car j’ai déjà quelques tickets écris en asciidoc.<br> Asciidoc est un langage de balisage, qui permet de produire du contenu, en apportant une mise en page qui garde le texte lisible pour un humain.<br> C’est une façon de standardiser les traitements de textes pour des contenus simples sans logiciel supplémentaire.</p> </div> <div class="ulist"> <div class="title">Liens :</div> <ul> <li> <p><a href="https://blog.oxiane.com/2018/06/13/asciidoc-documentation-as-code/" target="_blank" rel="noopener">@jmdoudoux sur blog.oxiane.com</a> [asciidoc]</p> </li> <li> <p><a href="https://powerman.name/doc/asciidoc" target="_blank" rel="noopener">powerman.name</a> [asciidoc]</p> </li> </ul> </div> <div class="paragraph"> <div class="title">asciidoc:</div> <p><a href="https://docs.asciidoctor.org/asciidoc/latest/attributes/character-replacement-ref/" target="_blank" rel="noopener">character-replacement-ref</a></p> </div> https://pages-content.github.io//blog/2019/0013_how-to-install-a-deb-file_post.html Mon, 19 Aug 2019 00:00:00 +0000 blog/2019/0013_how-to-install-a-deb-file_post.html <div class="paragraph"> <p>Pour installer un paquet debian depuis un fichier .deb en ligne de commandes.<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ sudo dpkg -i /chemin/du/fichier/deb/</code></pre> </div> </div> <div class="paragraph"> <p>voir içi pour la <a href="https://unix.stackexchange.com/questions/159094/how-to-install-a-deb-file-by-dpkg-i-or-by-apt">référence</a><br></p> </div> https://pages-content.github.io//blog/2019/0011_gradle_configuration_ide_jbake_content_post.html Fri, 16 Aug 2019 00:00:00 +0000 blog/2019/0011_gradle_configuration_ide_jbake_content_post.html <div class="paragraph"> <p>Dans un projet applicatif piloté par le gestionnaire de build Gradle<br> il est plus agréable d’avoir la visibilité sur tous les dossiers<br> participant au développement de l’application,<br> comme des dossiers de ressources qui ne sont pas<br> dans les chemins par convention.<br> Par exemple je veux que le dossier src/jbake,<br> soit visible en tant ‘resource folder’,<br> il est possible de le faire en rentrant dans la configuration du projet,<br> dans les wizards de l’IDE. Cependant cette option n’est pas sauvegardée au rechargement suivant<br> du projet Gradle dans l’IDE. Pour apporter cette configuration de façon permanente<br> la solution est de surcharger la configuration des chemins de sources<br> dans le fichier de configuration build.gradle tel que aux lignes 18, 19, 20 et 21 :<br> build.gradle<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">plugins { id "java" id "groovy" id "org.jbake.site" version "5.0.0" id "org.ajoberstar.git-publish" version "2.1.1" } repositories { mavenCentral() jcenter() } group project_group version project_version sourceSets { main { java { srcDirs = [] } groovy { srcDirs =["src/main/java", "src/main/groovy"] } resources { srcDirs =[ "src/main/resources", "src/jbake"//in order to get site src content in the IDE ] } } test { java { srcDirs = [] } groovy { srcDirs =["src/test/java", "src/test/groovy"] } } } test { useJUnitPlatform() } configurations { ivy } dependencies { ivy "org.apache.ivy:ivy:$ivy_version" implementation "org.codehaus.groovy:groovy-all:$groovy_version" implementation "org.asciidoctor:asciidoctor-java-integration:$asciidoctor_java_integration_version" implementation "org.freemarker:freemarker:$freemarker_version" testImplementation "org.junit.jupiter:junit-jupiter-api:$junit5_version" testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:$junit5_version" } gitPublish { repoUri = github_pages_blog_repository branch = git_branch contents { from(file(jbake_content_from)) { into jbake_content_to } } } tasks.withType(GroovyCompile) { groovyClasspath += configurations.ivy }</code></pre> </div> </div> https://pages-content.github.io//blog/2019/0010_gradle_groovy_script_grab_ivy_configuration_post.html Wed, 14 Aug 2019 00:00:00 +0000 blog/2019/0010_gradle_groovy_script_grab_ivy_configuration_post.html <div class="paragraph"> <p>Le sujet du ticket est la configuration d’un script de build Gradle.<br> Je veux pouvoir utiliser un script Groovy sans faire référence<br> au projet Gradle dans lequel je l’ai attaché.<br> Je veux avoir la possibilité de lancer ce script Groovy hors de Gradle<br> sans que les annotations ivy de récupération de dépendance externe<br> ne viennent poser problème de performance ou de compilation<br> du script de build Gradle.<br> Pour illustrer la configuration je m’appuie sur deux scripts:<br> un script de build Gradle et un script Groovy.<br> Le script Groovy contient au début à la ligne 2,<br> une instruction pour tirer une dépendance externe<br> à l’aide du gestionnaire de dépendance ivy.<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-Groovy" data-lang="Groovy">#!/usr/bin/env groovy @Grab("commons-io:commons-io:2.6") import org.apache.commons.io.FileUtils static String getSeparator() { System.getProperty("file.separator") } String from = "${System.getProperty("user.home")}${separator}.config${separator}transmission${separator}torrents" String to = "${System.getProperty("user.home")}${separator}Documents${separator}torrents_completed" File fromDlDir = new File("${System.getProperty("user.home")}${separator}Téléchargements") File fromDir = new File(from) File toDir = new File(to) Collection<File> torrentFiles = FileUtils.listFiles( fromDir, ["torrent"] as String[], false) torrentFiles.addAll(FileUtils.listFiles( fromDlDir, ["torrent", "torrent.added"] as String[], false)) torrentFiles.empty ?: torrentFiles.each { it -> FileUtils.copyFileToDirectory(it, toDir) } println torrentFiles.size()</code></pre> </div> </div> <div class="paragraph"> <p>Dans le fichier build.gradle, maintenant voyons comment mettre en harmonie<br> les deux gestionnaires de dépendances, ivy et Gradle. L’accord entre les deux se fait aux lignes :<br> 26, 30, 37, 38 et 39<br> Ainsi je peux lancer mon script Groovy manuellement,<br> et la compilation de Gradle n’est pas gênée par le @Grab.<br> Les dépendances du script Groovy ne sont pas à fournir dans Gradle.<br> Par contre je ne peux pas lancer le script Groovy depuis Gradle.<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-Groovy" data-lang="Groovy">plugins { id "java" id "groovy" } repositories { mavenCentral() jcenter() } sourceSets { main { java { srcDirs = [] } groovy { srcDirs =["src/main/java", "src/main/groovy"] } resources { srcDirs =["src/main/resources"] } } test { java { srcDirs = [] } groovy { srcDirs =["src/test/java", "src/test/groovy"] } } } configurations { ivy } dependencies { ivy "org.apache.ivy:ivy:$ivy_version" implementation "org.codehaus.groovy:groovy-all:$groovy_version" } tasks.withType(GroovyCompile) { groovyClasspath += configurations.ivy }</code></pre> </div> </div> <div class="paragraph"> <p>référence du ticket sur <a href="https://stackoverflow.com/a/18174033/837404">stackoverflow</a></p> </div> https://pages-content.github.io//blog/2019/0009_groovy_algebre_pgcd_ppmc_post.html Tue, 13 Aug 2019 00:00:00 +0000 blog/2019/0009_groovy_algebre_pgcd_ppmc_post.html <div class="sect2"> <h3 id="_le_pgcd">Le PGCD</h3> <div class="paragraph"> <p><a href="https://fr.wikipedia.org/wiki/Plus_grand_commun_diviseur">wiki PGCD ou Plus Grand Commun Diviseur</a></p> </div> </div> <div class="sect2"> <h3 id="_le_ppmc">Le PPMC</h3> <div class="paragraph"> <p><a href="https://fr.wikipedia.org/wiki/Plus_petit_commun_multiple">wiki PPMC ou Plus Petit Commun Multiple</a></p> </div> <div class="paragraph"> <p>AlgebraUtils.groovy<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">package com.cheroliv.misc import groovy.transform.CompileStatic @CompileStatic class AlgebraUtils { /** * Great common divisor * Plus grand commun diviseur(pgcd) * Great Common Divisor * @param a * @param b * @return */ static Integer gcd(Integer a, Integer b) { !b ? a : gcd(b, a % b) } /** * Least common multiple * Plus petit commun multiplicateur(ppmc) * @param a * @param b * @return */ static BigInteger lcm(Integer a, Integer b) { (a * b / gcd(a, b)) as BigInteger } static void main(String... args) { Integer a = 96 Integer b = 28 println "gcd($a, $b) = ${gcd(a, b)}" a = 790 b = 990 println "lcm($a, $b) = ${lcm(a, b)}" } }</code></pre> </div> </div> <div class="paragraph"> <p>résultat:</p> </div> <div class="listingblock"> <div class="content"> <pre>gcd(96, 28) = 4 lcm(790, 990) = 78210</pre> </div> </div> </div> https://pages-content.github.io//blog/2019/0008_bash_find_trouver_fichiers_par_extension_post.html Mon, 12 Aug 2019 00:00:00 +0000 blog/2019/0008_bash_find_trouver_fichiers_par_extension_post.html <div class="paragraph"> <p>Je recherche des fichiers par critères de nom: la liste des fichier qui ont pour extension .h et .cpp</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ find . -name '*.h' -o -name '*.cpp' + +</code></pre> </div> </div> <div class="paragraph"> <p>la liste des fichier qui ont pour extension .h et .cpp<br> le résultat est sauvegardé dans le fichier list_of_txt_files.list</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ find . -name '*.h' -o -name '*.cpp' -print > list_of_txt_files.list</code></pre> </div> </div> <div class="paragraph"> <p>Je recheche la liste des fichiers dont l’extension est .chm<br> et je détruit cette liste.<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ find . -name "*.chm" -type f -delete</code></pre> </div> </div> https://pages-content.github.io//blog/2019/0015_projet_avec_methodologie_en_cascade_post.html Thu, 1 Aug 2019 00:00:00 +0000 blog/2019/0015_projet_avec_methodologie_en_cascade_post.html <div class="sect2"> <h3 id="_analyser_et_receuillir_les_besoins">Analyser et receuillir les besoins</h3> </div> <div class="sect2"> <h3 id="_definir_la_gestion_de_projet">Definir la gestion de projet</h3> <div class="imageblock"> <div class="content"> <img src="../../diagram/definir_projet.png" alt="definir la gestion de projet"> </div> </div> <div class="imageblock"> <div class="content"> <img src="../../img/triangle_qcd.png" alt="triangle_qcd"> </div> </div> </div> <div class="sect2"> <h3 id="_contextualiser_le_projet">Contextualiser le projet</h3> </div> <div class="sect2"> <h3 id="_analyser_et_recueillir_des_besoins">Analyser et recueillir des besoins</h3> <div class="sect3"> <h4 id="_formuler_les_objectifs_et_livrables">Formuler les objectifs et livrables</h4> </div> </div> <div class="sect2"> <h3 id="_décrypter_une_grille_de_lecture">Décrypter une grille de lecture</h3> </div> <div class="sect1"> <h2 id="_cadrez_le_projet_avec_votre_équipe">Cadrez le projet avec votre équipe</h2> <div class="sectionbody"> <div class="imageblock"> <div class="content"> <img src="../../img/conductor.png" alt="chef d’orchestre"> </div> </div> <div class="sect2"> <h3 id="_consulter_les_experts_pour_trouver_la_solution">Consulter les experts pour trouver la solution</h3> </div> <div class="sect2"> <h3 id="_choisir_une_méthodologie_de_gestion_de_projet">Choisir une méthodologie de gestion de projet</h3> <div class="imageblock"> <div class="content"> <img src="../../img/cascading_planning.png" alt="planning en cascade"> </div> </div> <div class="imageblock"> <div class="content"> <img src="../../img/Cycle_V_details.jpeg" alt="cycle en V"> </div> </div> </div> </div> </div> https://pages-content.github.io//blog/2019/0014_list_all_databases_in_postgresql_post.html Tue, 30 Jul 2019 00:00:00 +0000 blog/2019/0014_list_all_databases_in_postgresql_post.html <div class="paragraph"> <p>Je n’ai pas envie d’installer <a href="https://www.pgadmin.org/">pgAdmin</a> ou <a href="http://phppgadmin.sourceforge.net/">phppgadmin</a> alors que tout est présent en ligne de commande.<br> Pour cela nous devons lancer le terminal et nous connecter en tant que user postgres.<br> le user postgres est le seul à avoir par défaut le droit de lancer l’application psql qui est le client ligne de commande (<a href="https://fr.wikipedia.org/wiki/Interface_en_ligne_de_commande">CLI</a>) postgresql,<br> pour pouvoir parler à la base de donnees en ligne de commande depuis le terminal.<br> Pour se connecter, lancer le terminal et taper ceci:<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ sudo -i -u postgres</code></pre> </div> </div> <div class="paragraph"> <p>Pour se connecter et arriver directement à l’invite de commande postgresql, taper ceci :</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ sudo -i -u postgres psql</code></pre> </div> </div> <div class="paragraph"> <p>Pour lister les bases de données d’une instance de postgresql, voici la commande :<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-SQL" data-lang="SQL">postgres=# \l</code></pre> </div> </div> <div class="paragraph"> <p>résultat:</p> </div> <div class="listingblock"> <div class="content"> <pre> Liste des bases de données Nom | Propriétaire | Encodage | Collationnement | Type caract. | Droits d'accès -----------+--------------+----------+-----------------+--------------+----------------------- fiber | tech | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =Tc/tech + | | | | | tech=CTc/tech fiberdev | tech | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =Tc/tech + | | | | | tech=CTc/tech fiberweb | tech | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =Tc/tech + | | | | | tech=CTc/tech postgres | postgres | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | template0 | postgres | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres (6 lignes)</pre> </div> </div> <div class="paragraph"> <p>taper q pour sortir de l’affichage des resulats<br> <br> pour lister les schémas d’une instance de postgresl.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-sql" data-lang="sql">postgres=# SELECT schema_name FROM information_schema.schemata;</code></pre> </div> </div> <div class="paragraph"> <p>résultat</p> </div> <div class="listingblock"> <div class="content"> <pre>-------------------- public information_schema pg_catalog pg_toast_temp_1 pg_temp_1 pg_toast (6 lignes)</pre> </div> </div> <div class="paragraph"> <p>ou</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-sql" data-lang="sql">postgres=# SELECT nspname FROM pg_catalog.pg_namespace;</code></pre> </div> </div> <div class="paragraph"> <p>résultat</p> </div> <div class="listingblock"> <div class="content"> <pre>-------------------- pg_toast pg_temp_1 pg_toast_temp_1 pg_catalog information_schema public (6 lignes)</pre> </div> </div> https://pages-content.github.io//blog/2019/0007_groovy_rename_recursively_files_post.html Mon, 29 Jul 2019 00:00:00 +0000 blog/2019/0007_groovy_rename_recursively_files_post.html <div class="paragraph"> <p>Mon lecteur de vidéo sur ma TV a sa façon de passer<br> d’un fichier à l’autre en lecture continue<br> et son mode de lecture est de passer de 1…​..mp4 à 10…​.mp4,<br> et non pas de 1…​mp4 à 2…​.mp4.<br> Le problème est qu’il y a près de 900 fichiers et dossiers.<br> Bingo un super cas d’utilisation de Groovy pour manipuler<br> des fichiers, renommage, recherche de motif dans le nom du fichier<br> ou dossier.<br> Ici le but est de changer les noms commençant par<br> un chiffre et dont le second caractère du nom<br> n’est pas un chiffre, j’ajouterai à ce nom un 0 au début<br></p> </div> <div class="paragraph"> <p>renameFilesToStartWithTwoDigit.groovy<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">#!/usr/bin/env groovy /** * get a crossplateform separator * @return */ static String getSeparator() { System.getProperty("file.separator") } /** * rename file * @param file * @param newName * @return the renamed file */ static File rename(File file, String newName) { assert file.renameTo(file .parentFile.path + getSeparator() + newName) new File(file .parentFile.path + getSeparator() + newName) } String rootFolderPath = System.getProperty("user.home") + "/Bureau/ng-courses/Udemy - Angular 7 " + "(formerly Angular 2) - The Complete Guide" File rootFolder = new File(rootFolderPath) assert rootFolder.exists() assert rootFolder.directory assert rootFolder.canRead() List<File> dirList = new ArrayList<>() //Adding rootFolder in dirList // just in case there is some files in it dirList.add(rootFolder) //looping to get list of directories //recursively inside rootFolder rootFolder.traverse { File file -> !file.directory ?: dirList.add(file) } //looping through dirList //to rename directories filling criterias for (int i = dirList.size() - 1; i >= 0; i--) { Character[] chars = dirList.get(i).name.chars !(chars[0].digit && !chars[1].digit) ?: dirList.set(i, rename(dirList.get(i), "0${dirList.get(i).name}")) if (dirList.get(i).directory) { //looping through directory //to rename file filling criterias dirList.get(i).listFiles().each { File f -> Character[] cs = f.name.chars !(cs[0].digit && !cs[1].digit) ?: rename(f, "0${f.name}") } } }</code></pre> </div> </div> https://pages-content.github.io//blog/2019/0006_groovy_find_files_copy_to_post.html Fri, 19 Jul 2019 00:00:00 +0000 blog/2019/0006_groovy_find_files_copy_to_post.html <div class="paragraph"> <p>Le but de ce script est de rechercher des fichiers,<br> à partir d’un répertoire parent; récupérer la sélection<br> dans une liste. Enfin copier cette liste de fichiers<br> dans un répertoire destination cela en Groovy.</p> </div> <div class="paragraph"> <p>findCopyTo.groovy<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">#!/usr/bin/env groovy @Grab("commons-io:commons-io:2.6") import groovy.io.FileType import org.apache.commons.io.FileUtils /** * un separateur OS independant * @return */ static String getSep() { System.getProperty("file.separator") } /** * la liste des fichiers dont le titre contient un item * de la liste des motifs * * @param path * @param motifs * @return la liste des chemins complet de fichiers */ static List<String> findFilesContainingMotifs( String path, List<String> motifs) { List<String> filePathResultList = new ArrayList<>() new File(path) .eachFileRecurse(FileType.FILES) { if (it.name.toLowerCase().contains('cucumber')) { filePathResultList.add it.path } } filePathResultList } /** * copy vers la liste des fichiers * @param files * @param to */ static void copyFilesTo(List<String> files, String to) { File toDirDest = new File(to) files.each { String filepath -> File file = new File(filepath) //si le dernier caractere de to n'est pas un separateur // alors ajoute le a la chaine (to.substring(to.length() - 1) == sep) ?: to.concat(sep) if (to + file.name != filepath) { FileUtils.copyFileToDirectory(file, toDirDest) file.delete() } } } /** * la list des arguments */ String userName = System.getProperty("user.name") List<String> motifs = ['cucumber'] String path = "/media/$userName/320/Books/" String to = "/media/$userName/320/Books/bdd/" /** * lappel aux methodes */ copyFilesTo(findFilesContainingMotifs(path, motifs), to) //affiche moi les fichiers déplacés findFilesContainingMotifs(path, motifs).each { println it }</code></pre> </div> </div> https://pages-content.github.io//blog/2019/0005_groovy_manipulation_files_post.html Thu, 18 Jul 2019 00:00:00 +0000 blog/2019/0005_groovy_manipulation_files_post.html <div class="paragraph"> <p>Ici je vais m’intéresser au chargement d’une propriété dans un build projet <a href="https://docs.gradle.org/current/userguide/userguide.html">gradle</a><br> sans que celle ci soit disponible dans le code.<br> La propriété sera défini dans le fichier gradle.properties du dossier ~/.gradle/gradle.properties<br> ~ est un raccourcie de la variable symbolique HOME_PATH représentant la racine utilisateur de session: le <a href="https://fr.wikipedia.org/wiki/R%C3%A9pertoire_personnel">répertoire personnel</a>.<br> De la même façon dans un build projet <a href="https://maven.apache.org/guides/index.html">maven</a>, avec ~/.m2/settings.xml Le but de ce script c’est de supprimer les fichiers qui correspondraient aux motifs énoncés<br> dans la variable strCriteria. Pour cela je vais utiliser les <a href="https://fr.wikipedia.org/wiki/Fermeture_(informatique)">closures</a>: each, findAll, collect<br> ainsi que la classe StringTokenizer qui va découper en morceau ma chaîne de critères<br> pour en récupérer une liste de strings. Si un des fichiers de mon dossier à nettoyer contient un des motif dans son nom<br> alors il sera un candidat à la destruction en étant ajouté à la liste résultat.<br> Et à la dernière ligne un petit exemple d’<a href="https://en.wikipedia.org/wiki/Elvis_operator">Elvis operator</a><br> filemanip.groovy<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">#!/usr/bin/env groovy //Mes criteres de selection des fichiers à detruire String strCriteria = "Dummies Dummie ajax Objective-C Windows blackberry " + "wordpress joomla ios c# f# rails ruby flex asp flash Dreamweaver adobe " + "CoffeeScript c++ .chm .epub .rar .zip .tar drupal drupals .net php javascript " + ".js iphone ipad js _js facebook gwt vaadin linq python py zope window " + "3D scala gaming active_directory tomcat jboss glassfish microsoft 2d " + "lego blogger blog cocoa dojo dom dotnetnuke eclipse .gz unity sharepoint " + ".tgz iwork filemaker .doc .txt" //repertoire personnel String userDir = System.getProperty("user.home") //un separateur de chemin crossplatform String sep = System.getProperty("file.separator") //la variable symbolique String sym_books_vrac_path = "books_vrac_path" //le chemin de mon fichier gradle.properties hors projet String propertiesFilePath = userDir .concat("${sep}.gradle${sep}gradle.properties") File propertiesFile = new File(propertiesFilePath) //je m'aassure que le fichier existe et que ce n'est pas un dossier assert propertiesFile.exists() && !propertiesFile.directory Properties gradleProperties = new Properties() //on boucle avec un inpustream sur le fichier //gradle.properties pour peupler ma variable gradleProperties propertiesFile.withInputStream { InputStream it -> gradleProperties.load(it) } //le chemin du dossier books_vrac est la valeur de notre clé books_vrac_path String pathVracDir = gradleProperties.get(sym_books_vrac_path) //j'ai récuperé tous ces livres en tapant cette commande dans le terminal //wget -m -np -c -R "index.html*" "http://the-eye.eu/public/Books/IT%20Various/" //on ouvre le dossier dont le chemin est dans la variable pathVracDir // on s'assure qu'il existe et que c'est un dossier File vracDir = new File(pathVracDir) assert vracDir.exists() && vracDir.directory //separer les élèments de ma liste de critère StringTokenizer tokenizer = new StringTokenizer(strCriteria) //la liste de critere List<String> criteriaList = new ArrayList<>() //j'itère sur les tokens et je construit ma liste de token, // mot clef critère de recherche tokenizer.each { String it -> criteriaList.add(it.toLowerCase()) } //je collect tous les noms de fichier dans le dossier List<String> fileNameList = vracDir .listFiles() .collect { File it -> it.directory ?: it.name } // je collect les noms de fichier qui contiendraient un des criteres List<String> resultList = fileNameList.findAll { String name -> criteriaList.findAll { String crit -> name.toLowerCase().contains(crit) } } // je parcours ma liste de résultat pour les effacer resultList.each { String fileName -> assert new File(vracDir.path + sep + fileName).delete() } println fileNameList.size() println resultList.size() resultList.empty ?: println(vracDir.path + sep + resultList.first())</code></pre> </div> </div> https://pages-content.github.io//blog/2019/0004_groovy_replace_string_load_properties_post.html Wed, 17 Jul 2019 00:00:00 +0000 blog/2019/0004_groovy_replace_string_load_properties_post.html <div class="paragraph"> <p>Voici un bout de code fonctionnel en groovy,<br> pour changer toutes les occurrences d’une séquence de caractères dans une String<br> et charger un fichier .properties dans un objet properties.<br> Exécuter une commande dans une String.<br> replaceTextinFile.groovy<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">#!/usr/bin/env groovy println System.getProperty("user.home") static String getSeparator_() { System.getProperty("file.separator") } String separator = separator_ String path = System.getProperty("user.home") .concat("${separator}.gradle" + separator + "gradle.properties") File propertiesFile = new File(path) assert propertiesFile.exists() && !propertiesFile.directory Properties gradleProperties = new Properties() propertiesFile.withInputStream { InputStream it -> gradleProperties.load(it) } String user_name = gradleProperties.getProperty("user_name") String text String resultText text = new File("${System.getProperty("user.home")}" + separator + "src" + separator + "cheroliv.github.io" + separator + "src" + separator + "main" + separator + "resources" + separator + "eco_space.txt").text String to = separator + "media" + separator + "${user_name}" + separator + "320" + separator + "videoCours" + separator String from = "${System.getProperty("user.home")}" + separator + "p2p" + separator resultText = text.replace(to, from) println resultText //execute command line in a string println "rsync -avr ${resultText} ${to}".execute().text</code></pre> </div> </div> https://pages-content.github.io//blog/2019/0003_groovy_char_ascci_post.html Wed, 10 Jul 2019 00:00:00 +0000 blog/2019/0003_groovy_char_ascci_post.html <div class="paragraph"> <p>Voici un bout de code fonctionnel en Groovy, qui génère un fichier texte,<br> avec les 256 premiers caractères lisibles du tableau ASCII<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-groovy" data-lang="groovy">#!/usr/bin/env groovy import java.nio.charset.StandardCharsets List<Character> chars = new ArrayList<>() int j = 0 Character jumpLine = '\n' 256.times { Integer idx -> if (Character.isAlphabetic(idx) || Character.isDigit(idx)) { if (j % 10 == 0 && j != 0) { chars.add(jumpLine) chars.add(idx as char) } else chars.add(idx as char) j++ } } String seperator = System.getProperty("file.separator") String path = "${System.getProperty("user.home")}${seperator}ascii.txt" File speCharFile = new File(path) if (speCharFile.exists() && !speCharFile.directory) { speCharFile.text = "" } else { speCharFile.createNewFile() } String text = new String() chars.each { Character it -> text = it == jumpLine ? "$text$it" : "$text $it " } speCharFile.setText(text, StandardCharsets.UTF_8.toString())</code></pre> </div> </div> <div class="paragraph"> <p>j’ai nommé le fichier spe_char.groovy,<br> depuis le dossier ou est le fichier<br> ouvrir un terminal et copier coller pour exécuter le script<br></p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-bash" data-lang="bash">$ groovy spe_char.groovy</code></pre> </div> </div> <div class="paragraph"> <p>résultat:</p> </div> <div class="listingblock"> <div class="content"> <pre> 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z ª µ º À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö Ø Ù Ú Û Ü Ý Þ ß à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ø ù ú û ü ý þ ÿ</pre> </div> </div>