Blog

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.

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 ...

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

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

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

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 : ...

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 : ...

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 : ...

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 : ...

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.