Ce billet introduit le premier volet d’une série dédiée à l’hébergement en self-hosted d’un grand modèle de langage (LLM) à l’échelle professionnelle, à partir de l’expérience d’une équipe ayant déployé un serveur GPU chez Ippon. L’objectif est de partager un retour d’expérience pratique sur l’écosystème technique entourant les LLM, incluant les composants matériels (GPU, infrastructure) et logiciels (vLLM, Kubernetes), sans entrer dans les détails complexes de l’entraînement des modèles. L’auteur, ingénieur système, aborde les principes fondamentaux des réseaux de neurones de manière vulgarisée, en simplifiant les aspects mathématiques pour se concentrer sur les concepts clés comme les poids et les biais, qui structurent les fichiers de modèles téléchargeables (ex. Ministral-3B). Le texte prépare le terrain pour des articles ultérieurs en expliquant la nature des LLM comme des fonctions massivement paramétrées, composées de couches de neurones interconnectés via des matrices de poids.

L’auteur partage son expérience de cohabitation entre Docker Compose et K3s dans son homelab, expliquant pourquoi il maintient les deux solutions plutôt que de tout migrer vers Kubernetes. Il souligne que Compose reste plus simple et efficace pour un serveur unique, grâce à sa transparence (fichiers de configuration clairs, volumes localisés, dépannage direct) et sa légèreté, tandis que K3s apporte une uniformisation des déploiements et une préparation pour une infrastructure évolutive, notamment pour des projets multi-nœuds ou nécessitant une montée en charge. Cependant, il note que K3s ajoute une complexité d'exploitation (ressources minimales requises, gestion du stockage et de la haute disponibilité non automatique) et que son utilité se limite à des cas spécifiques, comme l'apprentissage de Kubernetes ou des environnements devant grandir.

L’auteur insiste sur le fait que le choix entre les deux outils ne dépend pas du nombre de conteneurs, mais plutôt de la facilité de maintenance et de restauration en cas de panne. Il rappelle que Compose reste pertinent même avec une dizaine de conteneurs, à condition de respecter des conventions claires (volumes nommés, images taguées, documentation des sauvegardes), tandis que K3s devient intéressant pour des besoins de scalabilité ou de résilience, bien que son contrôle-plane et ses applications ne soient pas automatiquement hautement disponibles sans configuration avancée. Il conclut que la cohabitation des deux outils est un compromis pragmatique, évitant une migration brutale et permettant de tirer parti des avantages de chaque solution selon les besoins.

L’article explique comment la sécurité au niveau des lignes (RLS) dans PostgreSQL peut être contournée dans un projet Symfony en raison du rôle propriétaire des tables. Bien que les politiques RLS soient activées, le rôle qui exécute les migrations (et donc possède les tables) ignore ces restrictions par défaut, exposant toutes les données sans restriction. Un simple ALTER TABLE ... FORCE ROW LEVEL SECURITY est nécessaire pour appliquer correctement les politiques.

L’auteur souligne que cette faille est difficile à détecter en tests, car les connexions de test utilisent souvent un superutilisateur qui contourne aussi la RLS. La configuration par défaut de Symfony, où le même rôle gère à la fois les migrations et l’application, crée un risque de fuite de données. La documentation PostgreSQL mentionne ce comportement, mais il est souvent ignoré lors de la mise en place des politiques.

L’article critique l’approche traditionnelle des systèmes multi-agents en IA, qui se concentre souvent sur l’orchestration des agents plutôt que sur la modélisation du domaine métier. L’auteur souligne que les règles et contraintes (comme les seuils d’approbation) ne devraient pas être intégrées dans les prompts des agents, mais plutôt encapsulées dans un modèle de domaine bien défini. Cela permet aux agents d’agir dans un environnement structuré, recevant des retours immédiats en cas d’erreur, et favorise une autonomie plus robuste.

Plutôt que de concevoir des workflows complexes entre agents, l’article plaide pour une architecture où le domaine est modélisé en premier : processus, état, invariants et règles métier. Les agents interagissent ensuite avec ce modèle partagé, sans avoir à gérer eux-mêmes les contraintes. Cette séparation réduit les risques liés aux erreurs de compréhension des règles et évite les systèmes soit trop risqués, soit trop restrictifs.

L’auteur présente Mozaik, un framework qui adopte cette approche en introduisant un état partagé et concurrentiel pour les agents, tandis que le modèle de domaine garantit le respect des règles. L’objectif est de construire des systèmes plus fiables et évolutifs, en s’appuyant sur une modélisation précise du monde réel plutôt que sur des workflows artificiels.

DeltaChat est une application de messagerie chiffrée de bout en bout, comparable à WhatsApp ou Signal, mais avec des différences notables. Contrairement à WhatsApp, elle ne collecte pas les contacts des utilisateurs ni ne les transmet à des tiers comme Facebook. Son chiffrement est systématique, sans option à désactiver, et son identité repose sur une clé cryptographique stockée localement, sans mot de passe ni dépendance à un serveur spécifique.

L’absence de spam est un autre avantage majeur : les comptes ne sont pas énumérables, et les contacts ne peuvent être ajoutés que via un QR-code ou une URL d’invitation, ce qui limite les risques de sollicitations indésirables. DeltaChat propose aussi des relais par défaut (comme nine.testrun.org), mais permet d’en ajouter ou supprimer, voire d’héberger son propre serveur pour plus de contrôle.

Enfin, DeltaChat se distingue par sa simplicité de création de compte (un pseudo suffit) et son approche décentralisée, où l’identité numérique reste sous le contrôle exclusif de l’utilisateur. Cependant, la perte de l’appareil entraîne la perte définitive de cette identité, d’où l’importance de sauvegarder régulièrement son profil.

L’article souligne que le Domain-Driven Design (DDD) gagne en importance avec l’essor de l’IA générative, car cette dernière simplifie la partie technique du développement, mais ne remplace pas la nécessité de bien comprendre et modéliser le domaine métier. L’auteur, Miłosz Smółka, rappelle que le DDD, popularisé par Eric Evans en 2003, reste pertinent car la complexité centrale des projets logiciels réside dans la résolution des problèmes métiers, et non dans les détails techniques.

L’IA permet désormais de générer du code rapidement, réduisant l’importance des frameworks et des langages, mais elle ne peut pas remplacer le travail collaboratif entre experts métiers et développeurs pour construire un modèle précis. Le DDD insiste sur la knowledge crunching (affinage des connaissances) et des méthodes comme l’Event Storming pour capturer la logique métier, des étapes que l’IA ne peut automatiser entièrement.

Enfin, l’article met en garde contre la tentation de confier la modélisation du domaine à l’IA, soulignant que cette tâche reste un effort collectif et itératif. L’optimisation des outils d’IA pour générer du code doit s’accompagner d’une focalisation accrue sur la compréhension du domaine, sous peine de reproduire les erreurs passées où la technologie était privilégiée au détriment du problème à résoudre.

Plexus est une plateforme collaborative qui évalue la compatibilité des applications Android sur des appareils dé-Googlés, en s’appuyant sur les contributions de la communauté. Elle recense plus de 10 000 applications, notées selon leur fonctionnement sans dépendre des services Google : Gold pour un usage parfait, Silver pour des problèmes mineurs, Bronze pour des limitations notables, et Broken pour les applications inutilisables. Une distinction est également faite pour les appareils utilisant microG, une alternative open-source aux services Google Play.

Les statistiques montrent une majorité d’applications bien notées (12 517 Gold en dé-Googlé), mais un nombre significatif reste problématique (1 088 Broken). La plateforme permet aux utilisateurs de partager leurs retours pour améliorer la compatibilité des logiciels avec ces environnements alternatifs.

Développée par Techlore, Plexus propose des liens vers son code source, des téléchargements et des ressources complémentaires, tout en restant accessible via une API pour les développeurs.

Cette page de Chris Burnell illustre la puissance croissante du HTML natif, qui permet désormais des interactions dynamiques autrefois réservées à JavaScript. Elle présente des fonctionnalités comme les popovers, les modales <dialog>, les groupes <details> ou encore les attributs loading="lazy" et hidden until-found, démontrant comment le navigateur gère seul des comportements complexes sans code supplémentaire.

L’auteur souligne cependant les limites d’implémentation et d’accessibilité de certaines de ces fonctionnalités, comme le popover ou le hidden until-found, qui peuvent poser problème selon les navigateurs ou les outils d’assistance. Il encourage à les tester tout en veillant à les rendre accessibles.

Enfin, des éléments comme command et commandfor ouvrent la voie à des interactions encore plus poussées, bien que leur support reste partiel. La page sert à la fois de démonstration et de rappel sur l’évolution continue des standards web.

L’article de JoeCode défend l’idée que SQLite, souvent sous-estimé, peut remplacer de nombreux outils spécialisés grâce à ses fonctionnalités étendues et sa simplicité. L’auteur souligne sa stabilité exceptionnelle, illustrée par un historique de 25 ans, une couverture de test quasi parfaite et une adoption massive dans des environnements critiques comme les smartphones ou les avions. Contrairement aux bases de données traditionnelles, SQLite se distingue par son absence de dépendances, son intégration native dans de nombreux langages et systèmes, et son modèle public domain, garantissant une liberté d’utilisation sans contraintes.

L’auteur met en avant la polyvalence de SQLite, capable de servir de moteur de recherche full-text, de base de données JSON, de file d’attente, de base de données vectorielle pour l’IA, ou même de système de cache, réduisant ainsi la complexité des architectures IT. Son installation et son déploiement sont quasi instantanés, car il est déjà présent sur la plupart des systèmes, et son utilisation en mémoire (:memory:) simplifie grandement les tests unitaires. Pour les environnements serveurs, SQLite s’exécute directement sans configuration supplémentaire, bien que ses performances verticales (sur un seul serveur) soient limitées par le matériel.

Enfin, l’article souligne que SQLite évolue constamment avec des fonctionnalités modernes comme les window functions ou le support JSONB, tout en restant rétrocompatible. Bien que l’auteur plaisante sur sa capacité à remplacer même une PlayStation 5, il reconnaît que son véritable atout réside dans sa fiabilité et son intégration transparente, faisant de lui un choix judicieux pour des applications où la simplicité et la robustesse priment.

L’article défend l’idée que PostgreSQL peut remplacer de nombreux outils spécialisés grâce à ses fonctionnalités étendues. L’auteur, Raphael Bauer, souligne sa stabilité, sa facilité d’installation et de scalabilité, ainsi que sa capacité à simplifier les infrastructures IT en intégrant des fonctions comme la recherche full-text, le stockage JSON, le traitement de séries temporelles ou même le caching. Il évoque aussi son rôle potentiel dans les workflows d’IA ou comme base pour des microservices.

L’auteur partage son expérience depuis 2003, comparant PostgreSQL à MySQL de l’époque, plus limité en fonctionnalités malgré sa popularité. Il illustre son propos par des cas concrets, comme l’utilisation de TimescaleDB pour l’analyse de données web dans son outil Privatracker, évitant ainsi la maintenance de systèmes multiples.

Enfin, Bauer met en avant la maturité de PostgreSQL, soutenu par une communauté active qui enrichit régulièrement le logiciel sans compromettre sa stabilité. Il recommande des ressources complémentaires, comme les travaux de Stephan Schmidt ou Hazel Bachrach, pour approfondir les possibilités de cet outil polyvalent.

L’article analyse les hacks récents ayant ciblé des services publics français en 2026, soulignant que trois des quatre attaques ont exploité des comptes légitimes sans nécessiter de compétences techniques avancées. Il met en avant l’importance de la défense en profondeur : pare-feu, cloisonnement, double authentification et contrôle strict des droits d’accès, tout en rappelant que la minimisation des données (RGPD) limite les risques de fuite. L’exemple de la DGFIP illustre un retard de six semaines dans la détection de l’exfiltration de données, malgré une coupure immédiate des accès, soulignant l’importance de surveiller à la fois l’intrusion et la sortie des informations.

Les attaques se divisent en deux catégories : les cibles spécifiques (phishing, mots de passe volés, comptes obsolètes) et les scans automatisés exploitant des failles connues dans des logiciels populaires. L’article cite l’exemple d’une faille de conception (IDOR) sur le portail ANTS, où une simple modification d’URL permettait d’accéder à des dossiers non sécurisés. Les robots malveillants, eux, ciblent indistinctement les serveurs vulnérables, souvent en quelques secondes après l’enregistrement d’un nom de domaine.

Enfin, l’auteur insiste sur la nécessité d’une approche globale, combinant prévention (mises à jour, configuration par défaut restrictive) et détection rapide des intrusions ou fuites. Il rappelle que le RGPD impose une notification rapide des victimes, mais que certains organismes peinent à identifier une exfiltration de données, retardant ainsi les mesures correctives.

L’article de Smashing Magazine explore l’utilisation de SMIL (Synchronized Multimedia Integration Language) pour animer des SVG, une alternative méconnue aux animations CSS ou JavaScript. SMIL permet d’animer intégralement un SVG, y compris via la balise <img>, sans recourir à JavaScript, bien que certaines propriétés comme viewBox ne disposent pas encore d’équivalents CSS. L’auteur souligne que SMIL, malgré sa syntaxe verbeuse, offre une solution native pour des animations complexes, notamment lorsque JavaScript est bloqué.

Pour simplifier la gestion des animations SMIL, souvent alourdies par des balises répétitives (une par propriété et élément), l’auteur propose de planifier les animations à l’avance en utilisant des timing charts (diagrammes de timing). Ces diagrammes, inspirés de segments de ligne, aident à visualiser les séquences, chevauchements et synchronisations entre animations, facilitant ainsi leur conception et leur maintenance. Une approche visuelle qui rappelle les principes de parallélisme et de séquencement en animation.

Cette page présente treize balises et attributs HTML5 méconnus ou sous-utilisés, avec des exemples concrets et leur niveau de compatibilité. Parmi les éléments mis en avant, la balise <details> permet d’afficher un contenu masqué par défaut, avec la possibilité de créer un accordéon via l’attribut name pour gérer l’ouverture exclusive d’un seul élément à la fois. L’attribut popover, récemment ajouté, simplifie l’affichage de fenêtres modales sans JavaScript, tandis que <data> facilite l’association entre une valeur lisible par l’humain et un identifiant machine.

D’autres fonctionnalités comme <meter> et <progress> offrent des solutions natives pour représenter visuellement des proportions ou des avancements, bien que leur affichage doive être géré manuellement. Les attributs comme loading="lazy" optimisent le chargement des ressources en différé, et poster permet de définir une image de prévisualisation pour les vidéos. Enfin, les types d’input natifs (date, color, range, etc.) améliorent l’expérience utilisateur sans recourir à des bibliothèques externes.

Ce tutoriel explique comment configurer Codex, l'agent IA d'OpenAI, pour l'utiliser avec un modèle de langage local (LLM) hébergé via llama.cpp. L'idée principale est d'éviter les abonnements payants des plateformes cloud en auto-hébergeant le LLM, tout en conservant les fonctionnalités de Codex. L'auteur insiste sur l'importance d'installer Codex sur une machine dédiée pour limiter les risques liés à son accès au système.

L'installation de Codex se fait via un téléchargement manuel depuis GitHub, suivi de son déplacement dans /usr/local/bin. L'outil bubblewrap est requis pour sécuriser l'exécution de Codex en mode bac à sable. La configuration repose sur un fichier config.toml où l'utilisateur définit le fournisseur de modèle (llamacpp), un nom personnalisé et l'URL locale de l'API de llama.cpp.

L’article explore l’évolution des pseudo-classes CSS qui, bien que conçues pour gérer des états, peuvent parfois imiter le comportement des écouteurs d’événements JavaScript. L’auteur souligne que des pseudo-classes comme :hover, :active, :focus ou :checked réagissent à des interactions utilisateur (clic, survol, focus), offrant une alternative à JavaScript pour des cas simples. Par exemple, :focus-visible utilise des heuristiques pour déterminer si un élément doit afficher un indicateur de focus, une logique difficile à reproduire efficacement en JavaScript.

L’auteur aborde aussi des pseudo-classes plus avancées comme :focus-within et :has(), qui permettent de cibler des éléments parents en fonction de l’état de leurs enfants, réduisant ainsi le besoin de scripts. Ces fonctionnalités illustrent comment CSS gagne en expressivité, notamment avec des spécifications émergentes comme les Animation Triggers, qui pourraient un jour permettre de déclencher des animations via des événements. Cependant, ces innovations restent encore en développement.

Enfin, l’article mentionne des pseudo-classes liées aux formulaires (:valid, :invalid, etc.), qui simplifient la gestion des états de validation sans recourir à JavaScript. L’auteur conclut que, malgré ces avancées, CSS et JavaScript restent complémentaires, chacun ayant ses forces pour gérer les interactions et la logique applicative.

Cette page présente une sélection de ressources pour la réparation électronique, à la fois pour les particuliers et les professionnels. Elle met en avant des plateformes collaboratives comme iFixit, qui propose des tutoriels et pièces détachées, ainsi que des services spécialisés comme Murfy pour la réparation d’électroménager à domicile.

Elle recense également des acteurs professionnels tels qu’AdExcel pour la maintenance électronique industrielle ou Repturn, spécialisé dans la réparation de composants électroniques. Les liens sont soumis à modération avant publication sur OpenNews, qui compte plus de 12 000 références partagées.

L’article souligne que l’IA facilite la génération de code, mais que la véritable difficulté réside dans la production de code de qualité, maintenable et évolutif. L’auteur, développeur expérimenté, rappelle que les problèmes actuels (logique dispersée, tests inefficaces, architectures mal conçues) existaient déjà avant l’IA, simplement amplifiés par son usage massif. Il insiste sur l’importance des bonnes pratiques d’ingénierie logicielle, comme l’abstraction, le découplage et la responsabilité métier, plutôt que sur l’outil utilisé.

L’article de Romain Lanz explore une méthode pour utiliser efficacement l’IA dans le développement logiciel sans déléguer la réflexion stratégique. Il souligne que, contrairement à une idée reçue, déléguer l’écriture du code à l’IA ne signifie pas renoncer à la maîtrise du processus, à condition d’adopter une approche structurée.

L’auteur détaille trois concepts clés : le modèle (le LLM utilisé), le contexte (les informations fournies pour guider la réponse) et le harness (l’environnement technique qui encadre l’IA). Il insiste sur l’importance de limiter le contexte, car un excès d’informations dégrade la qualité des réponses, et sur le rôle du harness, qui agit comme un intermédiaire entre le modèle et les outils concrets (lecture/écriture de fichiers, exécution de commandes).

Enfin, Lanz rappelle que l’IA reste un outil prédictif, incapable d’agir sans ces extensions techniques. Sa méthode vise à optimiser l’interaction avec ces outils pour en tirer le meilleur parti tout en conservant le contrôle sur les décisions techniques.

La suppression de la revue de code est parfois perçue comme une simplification justifiée par l’efficacité, mais l’auteur souligne que cette approche repose sur des raisonnements erronés. Si l’IA et les outils automatisés accélèrent la production, ils ne remplacent pas l’expertise humaine pour détecter des erreurs d’intention, de logique ou de cohérence dans le code. Une revue superficielle ou simulée, où les développeurs se contentent d’approuver sans analyser, crée une fausse sécurité et aggrave les risques en production.

L’écart entre la vitesse de production et la capacité de relecture humaine est devenu ingérable. Un relecteur ne peut examiner que quelques centaines de lignes par heure, tandis qu’un agent IA génère des milliers en quelques secondes. Cette asymétrie rend la revue traditionnelle caduque, poussant les équipes soit à ralentir le processus avec des revues longues et inefficaces, soit à adopter une approbation de complaisance, pire que l’absence totale de contrôle.

L’auteur propose une alternative : assumer l’absence de revue pour forcer l’équipe à trouver des solutions alternatives, comme des outils de validation automatisée ou des tests renforcés. Plutôt que de supprimer la revue par facilité, il faudrait repenser son rôle et ses méthodes pour qu’elle reste pertinente dans un contexte où l’IA domine la production de code.

L’auteur explique avoir réduit le nombre d’agents IA qu’il utilise simultanément après avoir constaté que cette pratique créait une surcharge décisionnelle. Malgré une méthode de travail structurée (spécifications, tests d’acceptation), il a progressivement lancé plusieurs agents en parallèle, se retrouvant submergé par leurs questions et incapable de prioriser efficacement.

Il illustre ce problème avec la théorie des contraintes, soulignant que multiplier les tâches en amont d’un goulot d’étranglement (ici, sa capacité à arbitrer) ne fait qu’accumuler du stock invisible (branches ouvertes, PR en attente) sans améliorer la productivité. La fatigue décisionnelle qui en résulte affecte la qualité du travail, notamment la relecture de code généré par IA.

L’auteur conclut que cette dérive, bien que non imposée, révèle un défaut de gestion des priorités, aggravé par l’illusion de productivité offerte par les agents. Il compare cette situation à l’effet contre-productif d’ajouter des développeurs à un projet déjà en retard.