Veille – semaine 42 – 2026

🇬🇧 LGTM (Looks Good to Me) – Claude Opus 5.5 music video

Pour commencer la semaine, un peu de musique 🎶

→ Accéder à la vidéo

🇬🇧 Looking forward to Git 2.56 — and 3.0

Quelques nouveautés pour la version 2.56 de Git :

  • git history drop : supprime un commit de l’historique et rejoue les commits suivants (ne fonctionne pas si l’historique de la branche contient des merge commits).
  • git refs : ajoute de nouvelles sous commandes (create, delete, update et rename).
  • git branch --delete-merged : supprime les branches locales déjà fusionnées dans leurs branches distantes.
  • git add --resolved : ajoute uniquement les fichiers dont les conflits de fusion ont été résolus.

Et pour la version 3.0, le calendrier semble s’orienter vers une sortie pour le premier semestre 2027.

Le nouvel algorithme de hachage par défaut est aujourd’hui le principal frein à la sortie de cette version, toutes les plateformes n’étant pas encore adaptées. On notera également, parmi les changements annoncés, des gains de performance pour les répos les plus volumineux.

→ Accéder à l’article

🇫🇷 dotAI 2026 : De l’illusion d’autonomie à la réalité du terrain, reprendre le contrôle sur nos agents

JoliCode nous présente ici un résumé des conférences ayant eu lieu durant la dotAI 2026.

Pour moi, cet article montre un usage au quotidien de l’IA qui gagne en maturité :

  • La nécessité de rester dans la boucle, tout en sachant où bien se « placer ».
  • De prendre le temps de bien cadrer et détecter les hallucinations pour avoir de réels gains.
  • L’appel à la sobriété et la souveraineté.

Dans la conclusion de l’article, un élément m’a marqué. Je vous le remets ci-dessous :

Face à ce changement brutal, la clé réside dans l’accompagnement des équipes. Cela implique de fournir des moyens techniques (crédits de jetons, accès aux modèles), d’aménager du temps effectif dédié à la veille et aux tests, et de renforcer les échanges collectifs (pair-programming augmenté, ateliers pratiques).

Je pense qu’aujourd’hui des entreprises sous-estiment l’investissement nécessaire à l’adoption de ces outils et des nouvelles pratiques qui en découlent, tout en s’attendant à des gains immédiats.

Ce rappel rejoint parfaitement ma vision sur le sujet.

→ Accéder à l’article

🇬🇧 Symfony 8.2

🇬🇧 OpenID Connect Login

Il s’agit ici d’une implémentation native du OIDC login (« se connecter via … ») dans Symfony, avec des comportements par défauts qui peuvent être surchargés.

→ Accéder à l’article

🇬🇧 Sudo Mode

Le sudo mode consiste à vérifier si une authentification récente ou très récente a eu lieu avant de valider une action destructive.

Avec sa version 8.2, Symfony vient proposer une implémentation native de ce mode.

// Exemple d'usage

use Symfony\Component\Security\Http\Attribute\IsGranted;

// moins de 2h par défaut
#[IsGranted('IS_AUTHENTICATED_RECENTLY')]
public function changeEmail(): Response
{
}

// moins de 5min par défaut
#[IsGranted('IS_AUTHENTICATED_VERY_RECENTLY')]
public function deleteAccount(): Response
{
}

A noter que par défaut, c’est une 403 qui est retournée si l’authentification est trop ancienne mais il est possible d’implémenter une nouvelle interface (ReAuthenticationEntryPointInterface) pour avoir un comportement ajusté à nos besoins.

→ Accéder à l’article

🇬🇧 More Flexible Serialization Groups

Côté sérialisation, de nouvelles options viennent simplifier l’usage au quotidien :

  • Configurer le nom et path d’une propriété en fonction du groupe de sérialisation utilisé.
  • Ignorer certains groupes.
  • Inclure les propriétés sans groupes.

→ Accéder à l’article

🇬🇧 Targeted Cache-Control and Cache-Status Headers

Deux nouveautés ici :

  • Permettre de configurer le header CDN-Cache-Control pour distinguer le cache CDN du cache navigateur.
  • Implémentation de l’entête Cache-Status permettant d’indiquer le statut du cache et si la réponse a été générée par l’application.

→ Accéder à l’article

🇬🇧 Relative Ordering for Listeners and Services

Jusqu’à présent, pour ordonner nos listeners, nous ne pouvions agir que sur une notion de priorité adossée à un chiffre.

Afin d’être plus fin dans la configuration et éviter les mauvaises surprises si une priorité change, il va être possible d’ordonner les listeners (AsEventListener), les services taggués (AsTaggedItem), les firewall listeners (FirewallListenerOrder), les listeners doctrine (AsDoctrineListener prochainement) ou encore les messages handlers (AsMessageHandler) via des notions de before ou after pour s’assurer de l’ordre d’exécution.

Côté décorateurs (AsDecorator), même principe via within ou around.

Deux comportements sont à souligner :

  • Il est possible de configurer des before/after en ciblant des éléments n’ont existants, sans déclencher d’erreur. L’objectif est de permettre à une lib A de cohabiter facilement avec une lib B, lib C, etc sans déclencher d’erreur si au final seul la lib A est présente dans le projet.
  • Si la configuration des priorités et des before/after entrent en conflit, Symfony déclenchera une erreur à la compilation.

→ Accéder à l’article

🇬🇧 Compiled Event Dispatcher

Parmi les différents gain de performances prévus, il y en a un qui peut avoir un impact sur votre code.

Symfony 8.2 introduit CompiledEventDispatcher. Au lieu de préparer l’event dispatcher et les listeners au runtime (donc à chaque exécution), l’ensemble est préparé à la compilation une seule fois et profite de l’OPcache.

Cela s’accompagne d’un changement de namespace pour EventDispatcherInterface.

De plus, changer les listeners durant le runtime devient déprécié.

→ Accéder à l’article

🇬🇧 EntityExists, Cron and Audio Constraints

Trois nouvelles contraintes côté Validator :

  • EntityExists via Doctrine : vérifie l’existence d’une entité à partir de son identifiant.
  • Assert\Cron : valide le respect du format des cron expression.
  • Assert\Audio : valide les fichiers audio (durée, codec, etc).

→ Accéder à l’article

🇬🇧 Single-Use and Safer Signed URLs

Pour terminer, côté url signée, l’argument $version a été ajouté permettant de rendre une url signée à usage unique.

On a également la possibilité de définir une expiration pour les urls via la configuration, plutôt qu’à chaque appel de sign().

Et pour tous les paramètres supplémentaires passés dans un lien de connexion, il est maintenant possible de les prendre en compte à la génération de la signature.

Cela peut être utile pour passer un lien de redirection et empêcher toute modification après coup. Ce lien est ensuite récupérable via $request->attributes->get('_login_link_parameters')['param_name'].

→ Accéder à l’article