<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Apprentissage on Pragmatique — Blog de François Fournier</title><link>https://pragmatique.francoisfournier.fr/tags/apprentissage/</link><description>Recent content in Apprentissage on Pragmatique — Blog de François Fournier</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Fri, 30 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pragmatique.francoisfournier.fr/tags/apprentissage/index.xml" rel="self" type="application/rss+xml"/><item><title>Le pourquoi avant le comment</title><link>https://pragmatique.francoisfournier.fr/articles/pourquoi-avant-le-comment/</link><pubDate>Fri, 30 Oct 2026 00:00:00 +0000</pubDate><guid>https://pragmatique.francoisfournier.fr/articles/pourquoi-avant-le-comment/</guid><description>&lt;p>Quand j&amp;rsquo;accompagne un développeur junior, la même conversation revient. Quelque
chose, dans le projet, est manifestement inefficace : une étape manuelle qu&amp;rsquo;on
pourrait automatiser, un détour que personne ne justifie, une règle qui ralentit
tout le monde. La frustration est réelle et elle est légitime.&lt;/p>
&lt;p>Dans la plupart des cas, il suffit d&amp;rsquo;identifier &lt;strong>pourquoi&lt;/strong> c&amp;rsquo;est comme ça pour
que le problème cesse d&amp;rsquo;en être un.&lt;/p>
&lt;p>Le plus souvent, la raison est hors de notre contrôle — une contrainte d&amp;rsquo;un
autre service, une décision prise ailleurs, un système qu&amp;rsquo;on ne peut pas
toucher. L&amp;rsquo;inefficacité ne disparaît donc pas. Le travail reste exactement le
même.&lt;/p></description></item></channel></rss>