Lorsque l’on publie du code Go, l’habitude est d’en distribuer les sources directement depuis la forge qui l’héberge : github.com/org/projet, framagit.org/org/projet, etc. C’est pratique, mais cela lie durablement le chemin d’import au prestataire choisi. Le jour où l’on migre d’une forge à une autre, tous les utilisateurs doivent modifier leurs imports, et chaque fork historique continue de pointer vers l’ancienne adresse.

Heureusement, le mécanisme go-import permet de dissocier le chemin d’import du lieu d’hébergement réel du code. Il suffit pour cela d’exposer, sur le domaine de son choix, une page HTML contenant une balise <meta name="go-import"> décrivant où se trouvent les sources.

En informatique, la complexité est souvent perçue comme un signe de compétence.

En effet, un système simple paraît suspect, tandis qu’un système complexe paraît sérieux.

Quelle est la valeur d’une décennie de réussites ?

En dernière année d’école d’ingénieurs, j’ai construit une plateforme de CTF. À l’époque, il n’existait pas de logiciel comme CTFd. Il fallait donc tout faire soi-même.

Il m’a fallu beaucoup réfléchir pour débuter une architecture qui apparait simple a posteriori : servir des fichiers statiques, générés lorsque nécessaire, pour réduire la surface d’attaque. Les services Unix standards faisaient le lien entre les composants. Les conteneurs de bas niveau isolaient les services entre eux.

Lorsqu’on lit certaines discussions entre développeurs ou architectes logiciels, on pourrait croire que la moindre application web nécessite aujourd’hui une infrastructure distribuée, un environnement Kubernetes et plusieurs services cloud spécialisés.

Pourtant, de nombreux services web, y compris ceux qui accueillent plusieurs milliers de visiteurs par jour, peuvent fonctionner aussi bien avec une architecture beaucoup plus simple.

Voici un retour d’expérience sur l’infrastructure de mes projets en production, dont certains dépassent les 5000 visiteurs quotidiens. Je l’ai également appliquée pendant des années au profit d’une compétition de sécurité informatique avec plus de 250 participants en temps réel.

La Chine du Sud n’est pas une destination évidente pour les nomades numériques. Quand on pense nomadisme numérique, on imagine plutôt Bali, Lisbonne ou Chiang Mai. Pas Shenzhen, Guangzhou ou Huizhou. Et pourtant, j’ai passé trois semaines à explorer ces trois villes chinoises, une semaine dans chacune, et c’est une expérience que je ne suis pas près d’oublier !

Cet article n’est évidemment pas un guide touristique, mais un retour d’expérience sur ce que c’est vraiment de vivre et (d’essayer de) travailler en Chine du Sud quand on a le choix de son lieu de travail. Avec les difficultés, les surprises, et surtout ce Great Firewall dont je vais parler.

Vous souvenez-vous de l’époque où écouter de la musique était aussi simple que d’appuyer sur un seul bouton ? Ces jours où vous entriez dans une pièce, activiez un interrupteur sur votre amplificateur, et vous vous retrouviez instantanément entouré de vos morceaux préférés ? Il y avait quelque chose de magique dans cette simplicité — pas d’ordinateur à démarrer, pas d’applications à naviguer, pas d’interfaces numériques complexes avec lesquelles se débattre.

Les IA génératives répondent aujourd’hui à de nombreux usages, et il serait dommage de ne pas en tirer parti. Cependant, à l’heure du RGPD, il est légitime de se questionner sur l’exposition des données de ses clients ou partenaires lorsqu’on se repose uniquement sur des prestataires d’IA dont le traitement des données reste opaque.

Ayant moi-même participé à la construction de l’un de ces nouveaux services d’assistant virtuel, je vous propose ici un guide simple pour démarrer une machine et évaluer les performances de votre application IA, ou pour offrir à vos employés un accès à une IA souveraine, dans le but de comparer facilement les différents modèles disponibles.

Utiliser les IA génératives sans partager ses données avec des entreprises ou des États qui raffolent de nos données, c’est possible et accessible.

Le monde des logiciels libres regorge d’applications pour évaluer et utiliser les IA génératives. Après de nombreux tests, je vous présente ici le fichier cloud-init pour déployer votre propre instance de LocalAI en moins de 5 minutes.

Pourquoi LocalAI ?

LocalAI est un logiciel libre qui a pour vocation d’offrir une alternative locale, auto-hébergée, aux prestataires de services d’IA. Cette application expose une API compatible avec celle d’OpenAI. L’idée est de pouvoir remplacer en un clin d’œil les appels à OpenAI de n’importe quelle application existante : il suffit de changer le domaine où pointe l’API.

En tant qu’enseignant en école d’ingénieur et conférencier technique, je suis souvent amené à faire des démonstrations, en plus de la diffusion d’un classique diaporama. Comme tout conférencier organisé, je ne peux me passer de mes notes, du temps écoulé, … qui me sont données par un logiciel d’écran de présentateur. Ce genre de logiciel nécessite d’avoir un affichage étendu, c’est-à-dire que l’écran de l’ordinateur et le vidéo projecteur affichent 2 choses différentes.

Les unions de systèmes de fichiers sont un mécanisme permettant de fusionner deux ou plusieurs systèmes de fichiers, pour les présenter unifiés, sous un seul point d’accès à l’utilisateur.

L’idée principale derrière ce mécanisme est de pouvoir permettre d’altérer le contenu du premier système de fichiers (par exemple le contenu d’un CD-ROM) en inscrivant toutes les modifications (ajouts, suppressions, modifications) dans le second (qui pourra être une partition d’un disque).

J’ai installé le service d’intégration continue Woodpecker, afin de remplacer DroneCI, que l’entreprise l’ayant racheté a décidé de l’enterrer. Woodpecker étant un fork de la dernière version libre de Drone, son utilisation est globalement semblable.

Néanmoins, les équipes ont suivi des orientations différentes sur certains aspects, et la communication avec les agents/runners, qui se faisaient avant au moyen de websockets, est réalisée dans Woodpecker au moyen du protocole GRPC.

La solution proposée par la documentation de Woodpecker est d’utiliser 2 domaines : un sera utilisé pour l’interface web et l’API REST, le second pour GRPC. Est-ce vraiment nécessaire ?