Blog on Antoine Sauvinet - Blog & Portfolio

Le(s) rôle(s) du CTO dans une DSI : un titre, des réalités multiples

Tue, 06 Jan 2026 00:00:00 +0000

Derrière le titre ‘CTO’, des missions et périmètres très différents selon les organisations. Décryptage des réalités terrain et framework pour clarifier son rôle.

Build vs Buy en 2026 : le paradigme a changé

Mon, 05 Jan 2026 00:00:00 +0000

Il y a dix ans, la question “make or buy” se résumait souvent à un calcul simple : est-ce qu’on a les devs pour le faire ? Aujourd’hui, avec l’IA agentique qui accélère les développements et standardise les pratiques, l’équation mérite d’être revisitée.

Non pas que la réponse soit devenue plus simple. Elle reste “it depends”. Mais les critères sur lesquels ça dépend ont évolué.

Vue d’ensemble du framework de décision

SD Generator CLI : fini le cargo cult avec Stable Diffusion

Tue, 21 Oct 2025 00:00:00 +0000

J’open-source SD Generator CLI, un outil pour arrêter de se battre avec les workflows Stable Diffusion.

SILK-CLI : un workflow d'écriture intégrant les LLMs

Tue, 17 Jun 2025 00:00:00 +0000

Présentation de SILK-CLI, un outil CLI pour auteurs intégrant les LLMs dans leur workflow d’écriture.

Les LLMs remplaceront-ils les développeurs ?

Wed, 04 Sep 2024 00:00:00 +0000

La réponse est non. Les LLMs ne remplaceront pas les développeurs, du moins dans leur forme actuelle.

[EnhanceYourCode] : le Builder Pattern, Partie 2

Wed, 16 Sep 2015 09:59:55 +0000

Bonjour,

Dans l’article précédent, nous avons exploré la théorie du Builder pattern.

Voyons un exemple plus concret :

Supposons que nous construisons le modèle de base d’un jeu de rôle (RPG). Voici les règles de base :

Un joueur peut être un Héros : un Guerrier, un Mage, ou un Voleur (on garde ça simple)
Chaque Héros a 4 caractéristiques principales : Santé, Force, Esprit et Vitesse, comptées en points.
Les Héros ont un Niveau, et les caractéristiques de départ sont basées sur ce niveau (Santé commence à Niveau * 10, Force et Esprit commencent à Niveau * 5, et Vitesse commence à Niveau * 3)
Le Guerrier a un Modificateur (+2 Force, -2 Esprit), le Mage a un Modificateur (+2 Esprit, -2 Force)
Le joueur peut améliorer 2 Caractéristiques de 1 point chacune ou 1 caractéristique de 2 points, afin de personnaliser son Héros.

Une implémentation naïve de la classe Hero serait :

[EnhanceYourCode] : le Builder Pattern

Wed, 09 Sep 2015 14:58:47 +0000

Bonjour,

Dans cet article, j’aimerais vous présenter le Builder pattern et comment je l’utilise dans mon code C#.

Le Builder Pattern est un Creational design pattern, comme le Factory Method Pattern que j’ai déjà couvert dans cet article précédent. Son objectif principal est de fournir un DSL léger pour construire des objets en définissant des propriétés de démarrage, en séparant le processus de construction d’un objet de l’objet lui-même.

Essentiellement, l’idée est de créer une classe avec des champs mutables, qui seront initialisés avec des méthodes dédiées, et une méthode finale qui crée l’objet lui-même à partir de ces valeurs. Voici un exemple abstrait :

Canopy : Automatisez vos tests navigateur en F# !

Mon, 31 Aug 2015 10:15:15 +0000

Bonjour,

J’aimerais vous présenter Canopy, une surcouche Selenium écrite en F#. Elle vous apporte la concision et la clarté de F# pour vos tests Selenium.

Tout d’abord, nous devons créer une nouvelle application console F#, puis nous installons canopy dans notre projet :

Comme vous pouvez le voir, le package NuGet de canopy va récupérer l’écosystème Selenium.

Créons notre premier test. Il vérifiera qu’une recherche de “canopy F#” dans Google affichera le site officiel de Canopy comme premier résultat. Voici le petit bootstrapping nécessaire pour Canopy :

[Node.js] Construire un gestionnaire de processus propre

Sun, 30 Aug 2015 12:06:56 +0000

Dans cet article, je vais démontrer comment construire un gestionnaire de processus simple et maintenable pour Node.js, en tirant parti de son Event Loop.

L’idée principale est d’avoir un processeur central capable d’exécuter une série de tâches, de manière synchrone. Comme vous le savez peut-être, JavaScript est par essence un langage asynchrone. Prenons un exemple simple :

1
2
3
4
5
6
7
8


function CrawlingAWebPageAndGetLinks(){
 // do the stuff the method pretend;
}

(function program(){
 var result = CrawlingAWebPageAndGetLinks();
 console.log(result);
})();

Comme le flux d’exécution est asynchrone, la variable result ne sera pas valorisée avant que la méthode de crawling ne se termine, et l’utilisation de la variable se produira avant sa valorisation. La solution standard en JavaScript pour gérer ce problème est d’utiliser une méthode callback :

[EnhanceYourCode] : the Factory Method Pattern

Wed, 22 Jul 2015 21:33:31 +0000

Le Factory Method pattern est l’un des design patterns de création les plus utiles. Il permet de déléguer la création d’un objet à une classe dédiée, améliorant la testabilité et respectant le principe de responsabilité unique.

Les estimations sont-elles critiques pour le business ?

Tue, 16 Jun 2015 09:12:27 +0000

Grâce à mon premier article, j’ai eu la chance d’avoir des discussions très intéressantes avec certains collègues.

L’une des principales préoccupations concernait l’aspect obligatoire des estimations dans certaines situations, principalement pour arbitrer entre deux projets.

Tout d’abord, permettez-moi de clarifier ma pensée sur les estimations. Pour fournir une estimation fiable, les critères suivants doivent être réunis :

L’équipe doit se connaître parfaitement, sachant précisément quelles sont les forces et faiblesses de chaque membre.
Le codebase de l’équipe doit être soit vierge, soit sans défauts.
Le produit doit être entièrement identifié et spécifié, et le Product Owner, en tant qu’expert du domaine, doit être sûr à 100% de ce que le produit final doit être.

Je posterai plus à ce sujet plus tard, mais à mon avis, ces conditions sont au mieux anti-agiles et au pire impossibles à obtenir.

(No)Estimates !

Mon, 08 Jun 2015 18:12:39 +0000

C’est un combat quotidien pour le développeur d’aujourd’hui : donner des estimations précises du travail que nous faisons, ou que nous devrons faire. Quand avez-vous réussi pour la dernière fois à donner une estimation vraiment précise ? Vous savez, celle qui correspond parfaitement à la quantité de travail à faire, dans le délai exact, avec une vision claire de ce que vous deviez accomplir ? Ça fait un moment, n’est-ce pas ?