Pour répondre aux demandes de droit à l'effacement du RGPD dans une application Symfony utilisant Doctrine, il ne suffit pas de supprimer une entité avec EntityManager::remove(). Cette méthode implique la suppression totale de l'enregistrement, ce qui est souvent impossible pour les données commerciales soumises à des obligations légales de conservation, comme les commandes ou les factures. L'effacement consiste plutôt à "retirer la personne d'un enregistrement qui doit subsister", en anonymisant les informations personnelles tout en conservant la structure essentielle de l'entité.
Les approches courantes comme la suppression directe de l'entité ou la mise à null des champs ne sont pas suffisantes. EntityManager::remove() supprime l'entité entière, ce qui peut entraîner la perte de données essentielles ou des erreurs de contrainte de clé étrangère. La simple nullification des champs dans le code PHP ne garantit pas l'effacement effectif dans la base de données, car Doctrine pourrait ne pas enregistrer ces changements, laissant des données personnelles intactes dans des tables secondaires, des colonnes JSON ou des objets embarqués.
Il est donc recommandé de concevoir l'effacement comme une opération de domaine explicite au sein de l'entité elle-même. Cette méthode, par exemple un forgetPersonalData(), doit être responsable de la suppression de l'identité, de la préservation des enregistrements nécessaires et de la journalisation de l'événement. Cela assure que les données personnelles sont effectivement purgées des champs pertinents tout en maintenant l'intégrité des données commerciales essentielles.
Résumé pour Shaarli :
L'effacement des données RGPD dans Doctrine ne se limite pas à EntityManager::remove(). Pour les données commerciales soumises à conservation, il faut anonymiser les informations personnelles tout en gardant l'enregistrement. Ni la suppression directe ni la nullification des champs ne suffisent à garantir cet effacement. Il faut implémenter des opérations de domaine explicites au sein des entités pour masquer l'identité tout en préservant les données essentielles, et vérifier que Doctrine a bien appliqué les changements.
L'article aborde la modélisation des périodes de rétention des données personnelles dans le cadre du RGPD, en soulignant les limites d'une approche simpliste basée sur une seule colonne deleted_at. Il met en évidence que différentes entités liées à un même individu (client, commande, facture) ont des cycles de vie distincts et des obligations légales de conservation qui ne peuvent être gérés par une seule date de suppression.
La solution proposée consiste à créer des politiques de rétention explicites pour chaque contexte de donnée, dissociant clairement la décision de suppression de la simple inactivité de l'utilisateur. Cela permet de représenter de manière granulaire les raisons pour lesquelles une donnée doit être conservée ou supprimée, offrant ainsi une meilleure traçabilité et conformité.
Cette approche vise à remplacer les requêtes SQL implicites et difficiles à tester par des objets de décision inspectables et testables. Ces objets indiquent le statut de rétention (éligible, bloqué, programmé, déjà oublié), la raison associée et la date d'éligibilité éventuelle, rendant la politique de suppression transparente et gérable.
Cet article propose un workflow GitHub Actions idéal pour les applications Symfony. L'objectif principal est de garantir que le code et les dépendances livrés fonctionnent dans un environnement similaire à la production. Il met en avant un workflow de CI de base axé sur les tests, le linting, l'analyse statique et la sécurité des dépendances.
Le workflow présenté inclut des étapes essentielles pour une application Symfony typique. Il couvre la configuration de PHP, l'installation des dépendances via Composer avec mise en cache, la création et la migration de la base de données de test (PostgreSQL ou MySQL), ainsi que la validation de la cohérence du schéma de base de données avec le mapping Doctrine. Ce workflow est conçu pour s'exécuter lors des pull requests et des commits sur la branche principale, assurant une intégration continue fiable.
Le workflow CI utilise un environnement de test avec une version de PHP correspondant à celle de production, ainsi qu'un service de base de données (PostgreSQL ou MySQL) pour simuler un environnement réel. Il inclut également la gestion des étapes de validation de la base de données pour détecter et afficher les divergences entre le schéma attendu et celui généré par les migrations.
Résumé pour Shaarli:
Workflow GitHub Actions recommandé pour les applications Symfony, axé sur les tests, l'analyse et la validation dans un environnement proche de la production. Il automatise l'installation des dépendances, la gestion de la base de données de test et la vérification de la cohérence du schéma, assurant la fiabilité du code avant le déploiement.
eBPF s'est imposé comme une technologie d'infrastructure clé dans les environnements cloud-native, passant d'une fonctionnalité noyau "exotique" à un composant essentiel. Les données de la CNCF Cloud Native Survey 2026 indiquent que 67 % des équipes Kubernetes utilisent déjà des outils basés sur eBPF, et Cilium, un projet eBPF majeur, est devenu le plugin réseau standard pour les principaux services Kubernetes managés (GKE, EKS, AKS).
eBPF (Extended Berkeley Packet Filter) permet l'exécution sécurisée de programmes dans le noyau Linux, sans nécessiter de modules noyau ou de modifications du code source. La sécurité est assurée par un vérificateur noyau qui valide chaque programme avant son exécution, garantissant l'absence de crashs ou de boucles infinies. La communication entre ces programmes et les outils en espace utilisateur se fait via des structures de mémoire partagée appelées "BPF maps", permettant une observation et un contrôle du noyau avec une surcharge quasi nulle.
Cilium, en tant que cas d'usage eBPF le plus connu, remplace le kube-proxy par un traitement de paquets basé sur eBPF, offrant des performances significativement accrues par rapport à iptables, notamment pour la gestion de milliers de services. Au-delà de la redirection de paquets, Cilium propose Hubble pour l'observabilité réseau en temps réel, ainsi que CiliumNetworkPolicy pour des politiques réseau avancées au niveau de la couche 7. De plus, Cilium 1.19 introduit le support natif de mTLS sans conteneurs sidecar, réduisant drastiquement l'utilisation de la mémoire grâce à des programmes eBPF par nœud plutôt que par pod.
Les migrations sont présentées comme la solution essentielle et la plus évolutive pour gérer la dette technique dans les systèmes logiciels et les infrastructures. Alors que les améliorations mineures de la dette technique peuvent être gérées individuellement par les ingénieurs, les problèmes plus importants nécessitent souvent des efforts coordonnés entre plusieurs équipes, ce qui rend les migrations inévitables. Ces projets visent à créer un levier technique ou à réduire la dette, mais leur coût et leur complexité augmentent avec la taille des systèmes, les rendant souvent difficiles à prioriser malgré leur importance cruciale pour la vélocité future de l'entreprise.
Les migrations constituent la seule voie viable pour progresser significativement sur la dette technique à mesure qu'une entreprise et sa base de code se développent. L'incapacité à réaliser des migrations efficaces conduit inévitablement à un enlisement dans la dette technique, rendant potentiellement une réécriture complète nécessaire à terme. La gestion réussie des migrations suit un playbook standard en trois phases : la réduction des risques, l'activation et la finalisation.
La première étape, la réduction des risques, consiste à aborder la migration de la manière la plus rapide et la moins coûteuse possible. Cela implique la rédaction d'un document de conception détaillé et sa validation auprès des équipes susceptibles de rencontrer les plus grandes difficultés dans le processus de migration.
L'article souligne que l'accessibilité numérique est souvent considérée comme un sujet annexe, distinct du cœur de métier des équipes produit. Cette approche conduit à la marginalisation des utilisateurs ayant des besoins spécifiques, perçus comme n'appartenant pas à la "cible" principale. L'autrice illustre ce problème par un exemple concret de persona produit, où une personne âgée est exclue de la réflexion.
Cette perception erronée de l'accessibilité a des conséquences directes sur la conception des produits et services numériques. En ignorant les besoins des personnes âgées, qui représentent pourtant une démographie croissante et économiquement active, les entreprises se privent d'une part de marché significative. De plus, cette vision réductrice du handicap comme une catégorie homogène et permanente masque la diversité et la temporalité des limitations, qu'elles soient physiques, cognitives ou sensorielles.
En conclusion, l'article plaide pour une intégration de l'accessibilité numérique au sein des équipes produit dès la phase de conception. Il est essentiel de comprendre que les limitations ne sont pas l'apanage d'une minorité isolée, mais peuvent concerner une large partie de la population à différents moments de leur vie. Cela permettrait de créer des expériences numériques inclusives pour tous, et non pas comme un ajout tardif ou un effort ponctuel.
Un harnais en IA est l'ensemble des éléments qui entourent un modèle de langage pour lui permettre d'agir dans le monde réel. Il comprend tout ce qui se situe entre le modèle et l'environnement extérieur, comme les conventions de projet, les configurations de serveurs ou les systèmes qui déclenchent des actions spécifiques. Sans harnais, un modèle de langage ne peut que produire du texte, incapable d'exécuter des tâches concrètes.
La notion de "harness engineering" gagne en importance, soulignant la nécessité de concevoir et d'améliorer cet environnement pour optimiser le comportement des agents IA. Des outils comme DeepSeek Harness illustrent cette tendance en proposant des plateformes modulaires où même le modèle d'IA est traité comme un plugin, offrant une grande flexibilité dans la construction des agents.
Essentiellement, un agent IA est le résultat de la combinaison d'un modèle et de son harnais. Le harnais assure la gestion des appels au modèle, la capture des résultats et leur renvoi, permettant ainsi au modèle de choisir des outils, de maintenir un contexte persistant et de décider des actions à entreprendre.
Jev, développé par TypeSafe, se positionne comme un modèle de décision qui ne génère aucun texte, mais se concentre sur la classification de données brutes avec une latence inférieure à une seconde. Il opère comme un "Système 1" selon la théorie de Daniel Kahneman, privilégiant la rapidité et l'automatisation par rapport au raisonnement et à la génération de texte des LLM classiques ("Système 2"). Son approche "zero-shot" permet une grande flexibilité en modifiant les taxonomies directement dans le prompt, évitant ainsi le besoin de fine-tuning coûteux en temps et en ressources comme avec les modèles BERT.
Ce modèle innovant propose trois primitives en un seul appel API : "Noul" pour des évaluations binaires avec probabilité, "Choice" pour des sélections parmi une liste fermée, et "Score" pour des notations sur une échelle personnalisée. Ces fonctions sont particulièrement utiles pour automatiser des tâches de tri et de routage, notamment en combinant plusieurs critères en une seule requête. L'analyse de la "confiance" globale, distincte du score de probabilité, permet de discriminer les décisions nécessitant une automatisation directe et celles qui requièrent une intervention humaine.
En termes de coûts, Jev est significativement plus économique que les LLM traditionnels, avec un prix de 0,042 $ par million de tokens en entrée et des sorties gratuites, divisant ainsi le coût de traitement par environ 300. Cependant, il est important de noter son hébergement américain, qui soulève des questions potentielles liées au RGPD pour les données personnelles, et de comparer ses performances avec des solutions de machine learning classiques sur des jeux de données spécifiques.
Cet article présente une fonction Zsh nommée "update" conçue pour simplifier le nettoyage et la mise à jour des outils de développement. L'idée principale est de centraliser en une seule commande la gestion de plusieurs utilitaires courants tels que Homebrew, Docker, nvm et les worktrees Git. Cela permet de libérer de l'espace disque et d'éviter l'accumulation de données inutiles laissées par ces outils.
La fonction aborde le problème de l'espace disque saturé en identifiant et en supprimant les "déchets" spécifiques à chaque outil. Pour les worktrees Git, elle recherche et supprime ceux qui sont orphelins, c'est-à-dire qui ne correspondent plus à une branche active. Dans le cas de nvm, elle gère la suppression des versions de Node.js obsolètes ou inutilisées, tout en proposant des mécanismes de sauvegarde et de confirmation.
Enfin, la fonction "update" utilise topgrade pour orchestrer les mises à jour des différents paquets et applications. Elle intègre également des commandes spécifiques pour nettoyer les caches Homebrew, les images et volumes Docker non utilisés, et offre un bilan détaillé de l'espace récupéré en gigaoctets avant de confirmer les actions.
L'article propose un système de gestion des priorités pour les tâches, basé sur quatre niveaux de priorité avec des "tests d'entrée" écrits et des règles strictes. L'idée principale est que la définition claire de chaque niveau de priorité force des choix concrets et visibles, évitant ainsi la dévaluation des étiquettes de priorité, un problème courant où tout devient rapidement "urgent".
Ce système vise à surmonter la tendance des listes de tâches à se remplir d'éléments marqués comme urgents, rendant la priorisation inefficace. En exigeant des critères spécifiques pour chaque niveau de priorité, l'approche garantit que seules les tâches qui répondent réellement à ces critères accèdent aux niveaux supérieurs, imposant ainsi des arbitrages clairs lorsque de nouvelles demandes apparaissent.
Transitions.dev propose une collection de transitions d'interface utilisateur (UI) préconçues, destinées à être intégrées facilement dans des applications web, notamment celles interagissant avec des agents d'IA. Ces transitions couvrent une variété d'effets visuels, allant des animations de chargement aux transformations d'éléments interactifs, dans le but d'améliorer l'expérience utilisateur.
Le site met en avant des exemples concrets d'animations pour des éléments courants tels que les boutons, les notifications, les menus, les cartes, et les champs de texte. Il offre la possibilité de copier le code des transitions ou de les utiliser via une compétence d'agent de codage. Des fonctionnalités Pro sont également disponibles, proposant des animations plus élaborées et des effets physiques avancés.
L'objectif de Transitions.dev est de fournir aux développeurs un catalogue de transitions esthétiques et performantes, simplifiant ainsi l'ajout d'interactions dynamiques et engageantes aux applications web modernes.
L'article explore le rôle de l'intelligence artificielle dans le développement logiciel, en s'opposant à son utilisation systématique pour "automatiser les parties ennuyeuses" du codage. L'auteur met en avant l'importance de conserver le processus de résolution de problèmes comme un "artisanat" personnel, une pratique qui permet un apprentissage et une croissance profonds.
Face à l'essor de l'IA, l'auteur préconise un retour aux fondamentaux du codage, comparant ce processus à l'entraînement dans un "vieux gymnase" à la Rocky Balboa. L'idée principale est que la lutte directe avec les défis de programmation, même frustrante, est essentielle au développement des compétences et à la maîtrise, un aspect que l'IA ne peut remplacer.
L'IA est reconnue pour son utilité dans des tâches répétitives comme la génération de code boilerplate ou la résumé de documentation. Cependant, le cœur du métier de développeur, impliquant la pensée critique, la conception architecturale et la prise de décisions nuancées, doit être préservé comme un espace de développement personnel, par analogie, à travers le "vieux gymnase" cognitif.
L'article met en lumière dix leçons importantes tirées d'erreurs réelles en conception UX. L'idée principale est que des décisions de conception apparemment mineures peuvent avoir un impact significatif sur l'expérience utilisateur et le succès d'un produit numérique.
Parmi les leçons clés, la réduction de la charge cognitive des utilisateurs est primordiale pour améliorer la productivité. L'article souligne également que le minimalisme n'est pas une solution universelle et que le respect des conventions propres à chaque système d'exploitation reste pertinent. Prévenir les erreurs des utilisateurs avant qu'elles ne se produisent s'avère plus efficace que de se concentrer uniquement sur leur récupération, et le maintien de l'état actuel du design de l'interface utilisateur peut prolonger la durée de vie d'un produit.
En résumé, cet article partage des leçons précieuses issues d'erreurs de conception UX courantes. Il insiste sur l'importance de réduire la charge cognitive pour une meilleure productivité, tout en rappelant que le minimalisme n'est pas toujours la solution et que le respect des standards établis, comme ceux de l'OS ou la loi de Jakob, facilite l'adoption et augmente la durée de vie des produits numériques. La prévention proactive des erreurs utilisateur est également présentée comme une stratégie plus efficace que la correction a posteriori.
Cet article explique comment générer manuellement un certificat Let's Encrypt temporaire, une solution de contournement face aux difficultés de renouvellement automatique des certificats, particulièrement sur des environnements complexes ou restreints. Il présente les pré-requis nécessaires, notamment Python 3 et la capacité de modifier les enregistrements DNS du domaine, ainsi que la commande certbot avec les options pertinentes pour un renouvellement manuel via le challenge DNS.
L'approche manuelle permet de pallier temporairement les problèmes d'automatisation liés à l'ACME. Elle requiert la création d'enregistrements TXT spécifiques dans la zone DNS du domaine concerné pour valider la propriété, une étape vérifiable ensuite via des outils comme nslookup ou des plateformes en ligne. Une fois cette validation réussie, le certificat et sa clé privée sont générés, offrant une solution rapide pour résoudre les problèmes de certificat expiré.
Bien que cette méthode dépannage, elle n'adresse pas la cause profonde des échecs de renouvellement automatique. L'article souligne l'importance d'anticiper les futures contraintes, comme la réduction de la durée de validité des certificats à 47 jours d'ici 2029, et suggère l'adaptation des processus pour éviter ces problèmes à long terme.
La note aborde la problématique de l'autorisation légale pour analyser des données confidentielles, spécifiquement des secrets industriels, à l'aide d'un modèle linguistique de grande taille (LLM). L'objectif est de proposer des exemples de documents contractuels à faire signer par les clients, en fonction de cinq scénarios d'hébergement et d'accès au LLM, allant du SaaS hors UE à un serveur physique interne.
La distinction entre l'accès via une interface de chat et une API est soulignée, la note se concentrant exclusivement sur l'accès par API. Cette approche est motivée par la complexité et le coût d'hébergement des modèles LLM eux-mêmes, qui nécessitent une infrastructure matérielle spécifique comme des serveurs équipés de GPU, contrairement aux interfaces de chat plus légères.
Le contenu détaille ensuite les implications légales de chaque option, en classifiant les solutions par localisation du traitement des données, et non par juridiction du fournisseur. Cela permet de comparer les différentes approches et de comprendre leur impact sur la relation client, en identifiant celles qui pourraient potentiellement effrayer ou rassurer.
Hermes est présenté comme un framework d'agent IA "battery included" qui vise à combler les lacunes des agents de développement actuels. Contrairement à ses homologues qui nécessitent souvent une intervention manuelle continue, Hermes promet une plus grande autonomie, la capacité d'apprentissage et une configuration simplifiée, incluant des connecteurs et une intégration avec les plateformes de chat.
Son installation est conçue pour être accessible, avec la possibilité de le déployer sur des infrastructures modestes comme un vieux VPS ou un PC, plutôt que sur du matériel surdimensionné. L'auteur souligne l'approche open source de son éditeur, NousResearch, comme un atout majeur, permettant une personnalisation et une évolution du système sans être enfermé dans un écosystème propriétaire.
Bien que Docker soit une méthode d'installation courante, l'article aborde également la possibilité de l'installer sur d'autres environnements comme Kubernetes ou via Nix. L'auteur met en avant l'idée de pouvoir faire tourner Hermes sur des machines peu puissantes en n'utilisant pas de modèles locaux, mais en se connectant à des services externes.
FFmpeg Commander est un outil en ligne qui permet de générer des commandes FFmpeg pour des flux d'encodage vidéo courants sans avoir à mémoriser tous les drapeaux (flags). L'outil offre une interface visuelle pour construire des commandes en configurant des préréglages, les formats d'entrée et de sortie, les options vidéo, audio, les filtres et les conteneurs.
Il simplifie ainsi l'utilisation de FFmpeg, un logiciel puissant pour la manipulation de fichiers multimédias, en rendant ses fonctionnalités plus accessibles aux utilisateurs moins expérimentés en ligne de commande. L'outil propose également des options pour copier la commande générée, visualiser les réglages en JSON, sauvegarder des préréglages personnalisés et réinitialiser les configurations.
L'interface de FFmpeg Commander est conçue pour faciliter la création de commandes précises pour diverses tâches d'encodage et de traitement vidéo, tout en permettant un contrôle fin sur les différents paramètres.
L'auteur partage son parcours, passant d'un rôle de développeur à celui de manager, une promotion qu'il n'a pas pleinement choisie, motivée par la fidélité à son équipe et au projet, ainsi que par l'absence d'alternatives claires pour l'évolution de carrière. Il décrit le choc de la réalité managériale, accentué par la transition vers le télétravail imposé par la pandémie, et la difficulté de gérer des équipes aux besoins variés, ainsi que le stress des évaluations annuelles dans un système de quotas stricts.
Après trois années dans la gestion, l'auteur a ressenti le besoin de revenir à la technique. Il souligne que cette décision n'est pas une régression, mais une prise de conscience de son alignement plus fort avec le code et le développement. Il a trouvé son aboutissement dans le rôle de Staff Engineer, un poste qui, selon lui, manquait de définition à l'époque de sa promotion. Ce retour à la source lui a permis de mieux comprendre l'impact individuel au sein d'une équipe et de retrouver un épanouissement professionnel.
Les trois années passées dans le management ont paradoxalement enrichi sa perspective en tant que Staff Engineer. Elles lui ont apporté une meilleure compréhension des enjeux humains, de la dynamique d'équipe et des processus organisationnels, tout en lui permettant de retrouver sa place dans le cœur de métier technique. Il conclut que ce cheminement, bien qu'inattendu, a été formateur et lui a permis de trouver un équilibre professionnel plus satisfaisant.
Les requêtes de conteneur CSS sont sous-utilisées et mal comprises, en partie parce qu'elles sont traitées comme des requêtes média traditionnelles, alors qu'elles diffèrent fondamentalement. Les requêtes média interrogent la largeur du viewport, agissant comme un proxy pour l'environnement de l'élément.
Les requêtes de conteneur, quant à elles, permettent aux composants de s'adapter naturellement au contexte de leur conteneur parent, indépendamment de la largeur de l'écran. Elles répondent à la taille réelle du conteneur qui les héberge, offrant ainsi une réactivité plus granulaire et ciblée pour les composants réutilisables.
Cette distinction est cruciale pour exploiter pleinement le potentiel des requêtes de conteneur et construire des interfaces plus robustes et flexibles, capables de s'adapter aux différentes dispositions et tailles de blocs dans une page.
Le défi de l'alignement des icônes avec le texte dans les listes est qu'une fois que le texte dépasse une ligne, l'icône centrée visuellement peut paraître décalée. L'approche initiale consistant à utiliser align-items: start dans Flexbox déplace l'icône au sommet du conteneur, ce qui n'est pas idéal en raison de l'espace de ligne par défaut.
Pour résoudre ce problème lorsque l'icône est un élément HTML, il est recommandé d'ajuster la position verticale de l'icône. L'utilisation d'une valeur fixe avec transform: translateY() s'avère instable lorsque la taille de la police, la taille de l'icône ou la largeur du conteneur changent. La solution la plus robuste consiste à utiliser l'unité lh (line-height) pour calculer un décalage dynamique, assurant ainsi un alignement constant quelle que soit la taille du texte ou de l'icône.
Lorsque l'icône est ajoutée via un pseudo-élément comme image de fond, le même principe de calcul d'un décalage relatif s'applique pour garantir un alignement cohérent avec la première ligne de texte, même lorsque le texte se prolonge sur plusieurs lignes.