<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Engineering on Antoine Boucher</title><link>https://antoineboucher.info/CV/blog/fr/tags/software-engineering/</link><description>Recent content in Software Engineering on Antoine Boucher</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Mon, 13 Apr 2026 08:00:00 -0400</lastBuildDate><atom:link href="https://antoineboucher.info/CV/blog/fr/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Notes sur le cycle de vie logiciel — GOALS, waterfall, vérification vs validation</title><link>https://antoineboucher.info/CV/blog/fr/posts/software-engineering-textbook-figures/</link><pubDate>Mon, 13 Apr 2026 08:00:00 -0400</pubDate><guid>https://antoineboucher.info/CV/blog/fr/posts/software-engineering-textbook-figures/</guid><description>&lt;p&gt;Ces pages viennent d’un &lt;strong&gt;manuel de génie logiciel&lt;/strong&gt; utilisé en cours. J’y ai regroupé les figures sur une seule page de référence : &lt;strong&gt;planification orientée objectifs&lt;/strong&gt;, comment le modèle &lt;strong&gt;waterfall&lt;/strong&gt; enchaîne les activités (avec &lt;strong&gt;vérification et validation&lt;/strong&gt; appariées à chaque phase), une variante &lt;strong&gt;incrémentale&lt;/strong&gt;, la liste des &lt;strong&gt;sous-objectifs du cycle de vie&lt;/strong&gt; du manuel, le rappel que &lt;strong&gt;les conseils méthodo dépendent du contexte&lt;/strong&gt;, et un court passage &lt;strong&gt;d’éthique&lt;/strong&gt; sur l’impact sur les personnes.&lt;/p&gt;</description></item><item><title>Mon parcours en génie logiciel</title><link>https://antoineboucher.info/CV/blog/fr/posts/software-engineering-journey/</link><pubDate>Sat, 30 Dec 2023 10:00:00 -0400</pubDate><guid>https://antoineboucher.info/CV/blog/fr/posts/software-engineering-journey/</guid><description>&lt;p&gt;La bio de ce site résume la facette du métier qui m’intéresse le plus : &lt;strong&gt;backend&lt;/strong&gt;, &lt;strong&gt;plateforme&lt;/strong&gt; et &lt;strong&gt;DevSecOps&lt;/strong&gt;. Cet article prolonge ce regard — pas une chronologie d’emplois, mais les idées qui reviennent quand on cesse de ne mesurer que « les features livrées ».&lt;/p&gt;
&lt;h2 id="des-features-aux-systèmes"&gt;Des features aux systèmes&lt;/h2&gt;
&lt;p&gt;Au début, le progrès semble linéaire : tickets fermés, endpoints ajoutés, écrans livrés. Ce travail compte. Avec le temps, les problèmes intéressants se situent un cran au-dessus : comment les services communiquent, comment les pannes se propagent, comment un changement dans le dépôt d’une équipe affecte tout le monde le lundi matin. Le backend cesse d’être « écrire le handler » et devient « concevoir quelque chose qui reste compréhensible quand vous n’êtes plus dans la pièce ».&lt;/p&gt;</description></item></channel></rss>