<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Doolta on Le Blog d'Arhuman</title><link>https://blog.assad.fr/tags/doolta/</link><description>Recent content in Doolta on Le Blog d'Arhuman</description><generator>Hugo</generator><language>fr-fr</language><lastBuildDate>Sat, 30 May 2026 02:00:07 +0100</lastBuildDate><atom:link href="https://blog.assad.fr/tags/doolta/index.xml" rel="self" type="application/rss+xml"/><item><title>Le code fonctionne. Mais est-il de qualité ?</title><link>https://blog.assad.fr/post/code_audit/</link><pubDate>Sat, 30 May 2026 02:00:07 +0100</pubDate><guid>https://blog.assad.fr/post/code_audit/</guid><description>&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;À chaque problème complexe correspond une solution claire, simple… et fausse.&lt;/strong&gt;&lt;br&gt;
— H. L. Mencken&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;J’ai passé des années à chercher des solutions élégantes à des problèmes complexes.&lt;/p&gt;
&lt;p&gt;Aujourd’hui, l’un d’eux me résiste particulièrement :&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Comment évaluer la qualité réelle d’un dépôt de code source ?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Avec l’IA, le défi a changé. Ce n’est plus seulement “est-ce que ça fonctionne ?”, mais :&lt;br&gt;
&lt;strong&gt;Ce code sera-t-il encore maintenable, sûr et fiable dans six mois ?&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>L'Architecte qui ne posait aucune brique...</title><link>https://blog.assad.fr/post/architect_mason_ai/</link><pubDate>Fri, 01 May 2026 02:38:37 +0100</pubDate><guid>https://blog.assad.fr/post/architect_mason_ai/</guid><description>&lt;h2 id="et-comment-lia-la-fait-maçon"&gt;&amp;hellip;et comment l&amp;rsquo;IA l&amp;rsquo;a fait maçon&lt;/h2&gt;
&lt;p&gt;Mon profil psychologique est INTJ&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt; aussi appelé Architecte, et j’ai passé une bonne partie de ma vie à prouver que cette étiquette était adaptée&amp;hellip;de la pire des manières.&lt;/p&gt;
&lt;p&gt;Des années à avoir une multitude d’idées&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;sur des systèmes d’analyse (Blockchain, Productivité)&lt;/li&gt;
&lt;li&gt;sur des méthodes de développement personnel (Mémoire, Discipline, Apprentissage)&lt;/li&gt;
&lt;li&gt;des algorithmes (routage, metacompression, chiffrement)&lt;/li&gt;
&lt;li&gt;des outils (conversion de formats, gestion de projet, administration système)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Des années à produire des centaines d’idées à la chaîne pour rien ou pire pour en voir certaines réalisées par d’autres des années plus tard.&lt;/p&gt;</description></item><item><title>Suivre la méthode, rater le projet</title><link>https://blog.assad.fr/post/project-shu-ha-ri/</link><pubDate>Sun, 12 Apr 2026 02:00:07 +0100</pubDate><guid>https://blog.assad.fr/post/project-shu-ha-ri/</guid><description>&lt;p&gt;&lt;strong&gt;Vos plannings dérapent, vos deadlines explosent et le périmètre se réduit.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Est-ce la faute de votre méthode de gestion de projet ?&lt;/p&gt;
&lt;p&gt;Non, bien sûr. Chaque méthode a ses forces et son utilité et offre un cadre plus efficace que le développement au fil de l&amp;rsquo;eau et au doigt mouillé.&lt;/p&gt;
&lt;p&gt;Mais toute méthode a deux effets pervers :&lt;/p&gt;
&lt;h2 id="la-méthode-donne-souvent-un-faux-sentiment-de-sécurité"&gt;La méthode donne souvent un faux sentiment de sécurité&lt;/h2&gt;
&lt;p&gt;La méthode rassure parce qu’elle rend visible ce qui est facile à mesurer, mais &lt;strong&gt;des KPI au vert peuvent masquer un projet qui va dans le mur&lt;/strong&gt; :&lt;/p&gt;</description></item><item><title>Less is More : Pourquoi j'ai remplacé Git par Jujutsu.</title><link>https://blog.assad.fr/post/jj_has_better_legs/</link><pubDate>Sun, 05 Apr 2026 02:38:37 +0100</pubDate><guid>https://blog.assad.fr/post/jj_has_better_legs/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;En informatique, l’aphorisme “Less is More” revient souvent.
Avec Jujutsu (jj), il prend une forme très concrète : un modèle mental plus simple peut réduire la friction quotidienne dans la gestion de versions.&lt;/p&gt;
&lt;p&gt;Dans cet article&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt;, je ne vais pas chercher à “prouver” que &lt;code&gt;jj&lt;/code&gt; est supérieur à &lt;code&gt;git&lt;/code&gt;. Je vais montrer, sur un cas concret, pourquoi certaines opérations courantes : interrompre un travail, réorganiser ses modifications, corriger un commit non atomique ou résoudre un conflit, deviennent plus naturelles avec jj.&lt;/p&gt;</description></item><item><title>Pourquoi je code en Go de cette manière en 2026</title><link>https://blog.assad.fr/post/why-i-code-go-this-way-2026/</link><pubDate>Mon, 30 Mar 2026 15:24:26 +0100</pubDate><guid>https://blog.assad.fr/post/why-i-code-go-this-way-2026/</guid><description>&lt;h2 id="pourquoi-écrire-encore-sur-le-layout-et-les-pratiques-go-en-2026-"&gt;Pourquoi écrire encore sur le layout et les pratiques Go en 2026 ?&lt;/h2&gt;
&lt;p&gt;En 2018, Mat Ryer écrivait un article de référence &lt;a href="https://pace.dev/blog/2018/05/09/how-I-write-http-services-after-eight-years.html"&gt;How I write HTTP services after 8 years&lt;/a&gt; qu’il a mis à jour quelques années plus tard : &lt;a href="https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/"&gt;&amp;ldquo;How I write HTTP services in Go after 13 years&amp;rdquo;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;En 2019, je présentais déjà ma manière de coder en Go dans plusieurs &lt;a href="https://blog.assad.fr/slides/talk-how_I_code_in_go"&gt;présentations d’introduction au langage&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Ce texte est une version révisée de cette présentation, nourrie par mon expérience et mes contraintes en 2026.&lt;/p&gt;</description></item><item><title>Et si votre OOM n’était pas qu’un problème de mémoire ?</title><link>https://blog.assad.fr/post/what-if-oom-is-not-only-about-memory/</link><pubDate>Fri, 20 Mar 2026 15:24:26 +0100</pubDate><guid>https://blog.assad.fr/post/what-if-oom-is-not-only-about-memory/</guid><description>&lt;p&gt;Parfois, une investigation raconte une autre histoire que celle que vous attendez.&lt;/p&gt;
&lt;p&gt;C’est ce qui m’est arrivé récemment en cherchant pourquoi un pod finissait en OOMKilled deux à trois fois par jour.&lt;/p&gt;
&lt;p&gt;Une rapide observation de la mémoire du pod incriminé ne montre pas la courbe croissante typique d’un memory leak. Je manque de données juste avant le OOM (parce que c’est toujours quand votre système de métriques est en train de migrer que ce type d’incident se produit) mais avec les données de la journée, la cause semble se trouver ailleurs.&lt;/p&gt;</description></item><item><title>Et si votre dette technique n’était pas un problème technique ?</title><link>https://blog.assad.fr/post/what-if-tech-is-not-the-answer/</link><pubDate>Sun, 15 Mar 2026 11:05:26 +0100</pubDate><guid>https://blog.assad.fr/post/what-if-tech-is-not-the-answer/</guid><description>&lt;p&gt;Alors que les méthodes se font toujours plus nombreuses, les livres toujours plus prescriptifs, les outils toujours plus performants, la démarche toujours plus industrielle, l’industrie du logiciel continue à produire autant de dette, de retard et de bugs qu’auparavant.&lt;br&gt;
C’est un secret de polichinelle et pourtant rien ne change. Pourquoi ?&lt;br&gt;
Peut-être est-il temps de chercher la cause là où trop peu regardent.&lt;/p&gt;
&lt;p&gt;Laissez-moi vous raconter une histoire.&lt;/p&gt;
&lt;p&gt;Imaginez, vous êtes embauché en tant que chef de projet informatique, dans une startup où le développement est complètement stoppé :&lt;/p&gt;</description></item><item><title>Le supplément d'Art du programmeur</title><link>https://blog.assad.fr/post/extra-touch-of-art/</link><pubDate>Tue, 10 Mar 2026 02:38:37 +0100</pubDate><guid>https://blog.assad.fr/post/extra-touch-of-art/</guid><description>&lt;p&gt;Face à une IA capable de compiler nos intentions en programmes fonctionnels, je m&amp;rsquo;interroge : notre métier se réduit-il à l&amp;rsquo;assemblage de syntaxe, ou cache-t-il une dimension qui échappe par nature au calcul ?&lt;/p&gt;
&lt;p&gt;J’avais 17 ans quand j’ai enfin mis la main sur “The Art of Computer Programming” de Donald Knuth.&lt;br&gt;
À l’époque, en 1989, les livres de référence sur la programmation étaient rares et les 4 volumes de TAOCP faisaient figure de “bible”; il reste encore pour moi un ouvrage de référence que chaque informaticien devrait lire.&lt;/p&gt;</description></item></channel></rss>