En résumé :

Cet article explore le nouvel outil HubSpot Agent CLI, une interface en ligne de commande conçue pour connecter les agents d’IA (Claude, ChatGPT) et les équipes techniques aux données du CRM HubSpot. Nous analysons ses fonctionnalités, la gestion des permissions par les administrateurs et ses cas d’usage concrets pour étendre le CRM et optimiser le travail des responsables CRM et chefs de projet digital.

L’écosystème de la gestion de la relation client (CRM) franchit une nouvelle étape stratégique avec la convergence de l’intelligence artificielle et du développement local. Récemment dévoilé par l’éditeur, le HubSpot Agent CLI marque un tournant dans la manière d’interagir avec votre base de données. Cet outil en ligne de commande (actuellement disponible en version Beta) permet aux agents d’IA autonomes et aux équipes techniques de manipuler, analyser et automatiser les données directement depuis leur environnement de travail local.

Pour les entreprises soucieuses de maintenir des plateformes d’expériences digitales fluides et performantes, cette innovation ouvre de nouvelles perspectives d’extension et de productivité. Nous allons découvrir ensemble ce qu’apporte concrètement cet agent CLI, comment il garantit une gouvernance stricte de vos données et en quoi il transforme le quotidien de vos responsables CRM et chefs de projets digitaux.

Comprendre le HubSpot Agent CLI : l’interface de commande conçue pour l’IA

Le HubSpot Agent CLI est une interface en ligne de commande développée sur mesure pour permettre aux agents IA de codage ou d’assistance (tels que Claude Code, Claude App ou l’application ChatGPT) et aux utilisateurs techniques d’effectuer des opérations directement dans le CRM HubSpot.

Contrairement aux connecteurs API traditionnels ou à l’interface graphique habituelle, l’agent CLI s’exécute dans un espace de travail local ou un terminal d’agent IA. Grâce à une bibliothèque de compétences dédiées (HubSpot Agent CLI Skills installables via npx skills add hubspot/agent-cli-skills), l’agent IA comprend la structure du CRM et sait exécuter des commandes complexes pour interroger ou mettre à jour la plateforme.

hubspot --help
hubspot objects list
hubspot auth login

Un niveau d’accès étendu aux données CRM

L’outil permet de manipuler un périmètre très large de données au sein de votre compte HubSpot :

• Objets CRM standards et personnalisés : contacts, entreprises, transactions (deals), tickets et objets sur mesure.
• Workflows et pipelines : interrogation et gestion des étapes de transactions ou de tickets.
• Propriétés et métadonnées : lecture et mise à jour des champs et des structures de données.
• Données de revenus (lecture seule) : devis, factures, abonnements, commandes et contrats.

En associant le traitement en langage naturel des agents IA à la vitesse d’exécution d’une interface CLI, vos équipes peuvent désormais exécuter en quelques secondes des opérations de masse ou des analyses poussées qui nécessitaient auparavant plusieurs heures de travail manuel ou des scripts d’intégration complexes.

2. Gouvernance et sécurité : le rôle clé de l’administrateur CRM

L’introduction d’un outil permettant des modifications de données à grande échelle via une interface de commande exige une rigueur absolue en matière de sécurité et de gouvernance. HubSpot a structuré l’Agent CLI afin que les administrateurs et super administrateurs conservent un contrôle total sur l’accès et les actions exécutées.

Contrôle des accès et permissions (App Governance)

Par défaut, le HubSpot Agent CLI respecte scrupuleusement la gestion des droits d’accès basée sur les rôles. Un utilisateur qui s’authentifie via la commande hubspot auth login ne dispose que des périmètres et permissions attribués à son propre compte utilisateur HubSpot.

De plus, grâce aux fonctionnalités de gouvernance des applications, les super administrateurs peuvent valider ou restreindre l’installation de l’Agent CLI sur le compte entreprise. Si un utilisateur ne possède pas l’autorisation d’installer des intégrations, une demande d’approbation est directement transmise aux administrateurs.

Les fonctionnalités de sécurité pour éviter les pertes de données

Parce que les opérations d’écriture (create, update, delete) modifient la base de données réelle, HubSpot inclut des garde-fous essentiels pour vos équipes :

1. L’option –dry-run : elle permet de simuler une commande de modification ou de suppression. L’agent IA ou le chef de projet peut ainsi visualiser le plan d’action précis (le digest) avant d’appliquer réellement les changements.
2. Utilisation recommandée des comptes Sandbox : les équipes sont fortement encouragées à tester leurs requêtes et leurs prompts dans des environnements de test isolés avant tout déploiement en production.

3. Des cas d’usage concrets pour chaque rôle métier

L’un des atouts majeurs du HubSpot Agent CLI réside dans sa capacité à traiter des tâches opérationnelles récurrentes et gourmandes en temps. Voici comment vos équipes métiers peuvent exploiter cette solution au quotidien.

Pour le responsable CRM : qualité de donnée et analyses prédictives

Le responsable CRM fait face quotidiennement à des enjeux d’hygiène de la donnée et d’aide au pilotage commercial. L’Agent CLI devient un assistant puissant pour :

• Le nettoyage et la déduplication de la base : identifier automatiquement les tickets de support ou les fiches contacts en double pour le même client, fusionner le contexte des échanges et réacheminer la fiche vers le bon pipeline.
• L’analyse du pipeline commercial : interroger l’IA pour repérer les transactions à forte valeur stagnantes depuis plus de 30 jours, résumer l’historique des réunions et des e-mails, et générer un rapport quotidien des opportunités approchant de la date de clôture sans activité récente.
• La prévention du churn : analyser l’engagement des comptes clients, croiser les données de support avec les volumes de contrats et faire remonter proactivement les fiches présentant un risque de résiliation.

Pour le chef de projet digital : extension du CRM et automatisation

Le chef de projet digital cherche continuellement à étendre les capacités du CRM et à connecter l’outil aux processus métier de l’entreprise. Grâce au chaining de commandes via les tuyaux Unix (pipes) et au format JSONL, il devient très simple de :

• Exécuter des mises à jour en masse : importer et mettre à jour des milliers de propriétés CRM à partir d’un fichier .jsonl en une seule ligne de commande.
• Prototyper des extensions de schéma : créer et tester rapidement des objets personnalisés ou des groupes de propriétés directement depuis l’environnement de développement local.
• Automatiser les flux entre outils : concevoir des scripts légers combinant le CLI avec d’autres briques de l’écosystème digital pour alimenter le CRM ou synchroniser des données transversales.

Bâtir une stratégie d’extension CRM durable

L’arrivée du HubSpot Agent CLI illustre parfaitement la transformation des outils de relation client : l’IA ne se contente plus de rédiger du contenu, elle devient un véritable agent d’exécution capable de comprendre la structure de votre CRM et d’exécuter des actions techniques en langage naturel.

Pour tirer le meilleur parti de ces nouveautés sans compromettre l’intégrité de vos bases de données, une démarche structurée reste indispensable. Définir des règles d’attribution des droits claire, former vos équipes aux bonnes pratiques du dry-run et intégrer ces nouveaux flux dans une architecture globale d’expérience client sont les clés d’un projet réussi.

Nous espérons que cet article vous sera utile pour appréhender ces nouvelles possibilités et faire évoluer votre plateforme CRM vers plus d’agilité et de performance.

Besoin d’accompagnement dans la transformation de votre CRM ?

Vous souhaitez moderniser l’architecture de votre CRM, explorer les possibilités offertes par l’IA ou former vos équipes aux meilleures pratiques d’administration HubSpot ? Nos experts vous accompagnent dans la co-conception de vos projets digitaux pour maximiser l’efficacité de vos opérations.

Découvrez notre expertise en conseil et intégration CRM

Cet article HubSpot Agent CLI : la révolution de l’automatisation et de l’IA au service du CRM est apparu en premier sur Synolia, agence e-commerce, CRM, Data, PIM/DAM, OMS.

À travers cet article, nous allons passer en revue les plus grands enseignements de ces deux journées à Disneyland Paris.

Les nouveautés de Symfony 8.2

Impossible de passer à côté : le backlog de Symfony a changé de tête ces trois derniers mois :

Avoir plus de 300 pull requests ouvertes, en attente de review, était un état normal et sain dans la vie du projet - mais depuis que Nicolas GREKAS a adopté le développement et la review agentique, c'est du passé ! Il n'y a plus que 19 PR ouvertes à l'heure actuelle. Toutes les autres n'ont pas simplement été fermées 👋 - mais précieusement relues, testées et enfin mergées ; pour certaines, des années après leur ouverture 🎉

Ce préambule annonce donc du lourd pour la version à venir de Symfony (8.2), qui va bénéficier de plus de 375 features (contre ~180 d'habitude). En termes de sécurité aussi, les choses ont pris de l'ampleur, avec plus de 200 rapports de sécurité traités (un mélange de vraies failles et de hardening : des améliorations de robustesse).

Nicolas utilisait déjà l'IA depuis 2025, mais juste en babysitting. Depuis août, il a crafté des skills très précis basés sur tout son historique de code review, de contribution et de traitement des sujets. Aujourd'hui, rien n'est fait sans intervention humaine, mais l'agent s'occupe de tout ce qui est évident : les rebases, les checks basiques, et une review profonde en se réappropriant tout le sujet de A à Z.

Quelques fonctionnalités que nous avons hâte d'utiliser

• Demandé depuis 2019, l'attribut #[SerializedName()] prend maintenant en charge un nom différent en fonction du groupe de sérialisation !
• Un mode « sudo » pour forcer une re-saisie du mot de passe (ou autre) dans certains endroits très sensibles de votre application ;
• Le support natif d'OpenID Connect pour gérer la connexion des utilisateurs via des providers d'authentification (Google, Apple...) ;
• Le composant KeyManagement pour parler avec HashiCorp Vault, Azure Key Vault ou AWS KMS, et chiffrer les données de façon sécurisée !
• Consommer des messages en parallèle avec un seul worker Messenger via amphp/parallel. Une seule connexion backend et N threads de traitement 💪
• Le BatchDispatcher dans Messenger, capable d'envoyer plusieurs messages d'un coup dans la queue, plus rapidement que des ajouts unitaires (à l'exception d'AMQP) ;
• Le ChainStamp pour créer des enchaînements de messages qui se traitent les uns après les autres ;
• L'unique APP_SECRET, utilisé pour tout ce qui concerne les signatures, les cookies, les jetons... est désormais séparé par fonctionnalité, et il devient possible de le faire tourner (donc d'utiliser plusieurs secrets en même temps : le premier configuré signe, et tous valident) ;
• Le RecorderHttpClient est enfin mergé. Nous l'avions déjà vu à l'Afup Day Paris et nous avions hâte de pouvoir l'utiliser. Un attribut #[UseRecord] permet d'enregistrer le HAR du trafic réel, qui est ensuite rejoué dans nos tests ;
• L'attribut #[AsFormType] sur un DTO qui crée le formulaire correspondant pour nous 🤯
• Pareil avec #[AsWorkflow] : les transitions sont directement définies sur nos constantes. Bravo à Grégoire, qui avait commencé cette feature en 2024, et l'a terminée avec Claude !

Enfin, une nouvelle page d'exception a été intégrée, mais tout va bien, notre GifExceptionBundle supporte déjà le nouveau design, merci Loïck.

Exposer son métier aux agents IA avec API Platform

Antoine BLUCHET nous a fait une démo sympa d'un agent IA vocal qu’il a développé en side project pour son garage : gestion documentaire, wireframes 3D des voitures, estimation de devis auto, le tout semblait très complet !

Sous le capot, on retrouve évidemment plusieurs APIs comme l'accès au SIV pour récupérer les infos via la plaque d'immatriculation, mais aussi le vecteur principal de son assistant : le MCP.

Antoine nous explique que pour faire du MCP en PHP aujourd’hui, on a des librairies bien pratiques :

• le SDK PHP de bas niveau qui permet de lancer un serveur avec transport, chaque outil mis en avant est une méthode en PHP ;
• l’abstraction Symfony, qui permet, entre autres, d’utiliser des attributs sur les méthodes et de configurer le transport (HTTP, stdio) ;
• une abstraction API Platform avec des attributs au niveau des classes et une exposition plus simple des APIs sur le MCP.

Nous nous sommes donc attardés sur ce que propose l'abstraction d'API Platform :

• de la validation avec des Asserts et des Constraints ;
• du typage, y compris avec des choices ;
• la réutilisation des processors existants ;
• de la sécurité, avec le support des isGranted ;
• du retour en markdown et le branchement de providers.

La liste est longue, et l'idée derrière est simple : exposer un métier à un agent, ce n'est pas réécrire une API, c'est la rendre lisible pour lui.

Vient alors la vraie question, celle que nous retenons : comment parler à un agent sans lui noyer le contexte ? Antoine écarte les appels HTTP à l’API en direct. Faire des allers-retours avec l’API est assez bavard et gourmand en tokens. Il propose à la place d'exposer la documentation de l'API sur sa racine /, au format hypermédia, pour que l'agent s'y renseigne seul et aille droit au but, en un seul appel.

Reste le flux : PHP synchrone n'aime pas rester ouvert, ce qui tombe mal pour tenir une connexion avec un agent. La réponse avancée est Mercure.

Nous avons mis en place le [MCP fourni par API Platform sur redirection.io] (https://redirection.io/mcp) avec succès et nous recommandons chaudement son utilisation.

En pratique, Antoine fait cohabiter plusieurs modèles selon les besoins. Avec Symfony AI, on peut limiter certains tools à un modèle précis, par exemple limiter la recherche web à Gemini 2.5 qui le fait très bien et propose un free tier.

Un mot pour finir sur le testing, où rien n'est vraiment sûr. Tester les choix d'un agent est difficile et coûteux, et si les LLM Judges existent, Antoine les trouve fragiles : on ajoute du déterminisme sur du non-déterminisme. Bref, pas encore de solution solide.

Est-ce que le futur sera fait de pleins de "Jarvis" ? Pas forcément, mais quoi qu’il en soit, c’est autour des APIs qu’il sera construit !

PHP Défensif : Arrêtez de faire confiance, défendez votre code !

Thomas DUTRION nous ouvre son talk avec une citation de Léonard de Vinci :

L'expérience prouve que celui qui n'a jamais confiance en personne ne sera jamais déçu.

Le code défensif, ce n’est pas une question de compétence, mais de posture : ne faire confiance à personne, même pas à soi-même. L’idée directrice du code défensif, comme nous le présente Thomas, c’est de déplacer la responsabilité de l'humain vers la machine. On ne compte plus sur la discipline et la mémoire de chacun ; on écrit les règles noir sur blanc dans le projet pour que l'outillage les fasse respecter à notre place. Ce qui n'est pas explicite n'existe pas.

Côté pratique, on retient plusieurs vraies actions :

• Poka-yoke : rendre l’erreur humaine impossible et très facilement détectable si elle arrive (typage, readonly, logging). Préférer la prévention, prévoir la détection ;
• un type par concept : unions, intersections, DNF, tant qu'à faire. Si une union dépasse deux types, c'est sûrement qu'il manque un Enum ou un DTO ;
• des types dédiés plutôt que des primitifs : on type les IDs, on passe par brick/money pour les prix au lieu de floats, par une classe Uri au lieu de concaténer des strings ;
• on bannit les @, on passe aux comparaisons strictes, en gardant en tête que, dans le legacy, les loose comparisons sont parfois des features ;
• on ne fait jamais confiance aux valeurs externes : une couche de sécurité et de cohérence, on vérifie puis on valide ;
• et les petits réflexes qui comptent : des enums plutôt que des constantes, la config injectée plutôt qu'un fichier .env lu directement, des classes complètes dès leur création (logique dans le constructeur) et final pour éviter les changements de comportement abusifs, des conventions d'équipe sur le nommage (get ou find ?).

Pour appliquer toutes ces règles, ce sont finalement des outils que nous connaissons déjà qui entrent en jeu : PHP CS Fixer pour le style, PHPStan pour le typage, Deptrac pour les frontières d'architecture, Valinor pour valider les valeurs externes et les collections, et d'autres encore. Le tout est de les mettre en place sur nos projets et de les y tenir dans la durée.

Le fil rouge, en soi, c’est que moins on s’appuie sur l’humain, plus on s’appuie sur la machine. À l’ère des agents qui produisent du code en volume, les bonnes pratiques deviennent une nécessité et la machine devient essentielle pour ne pas faillir là où la discipline et la mémoire humaines fatiguent.

Vos coding agents en mode YOLO… mais en toute sécurité

Le mode YOLO, c'est ce qui permet à vos agents de pouvoir lancer toutes les commandes sans vous demander la permission. C'est donc... un peu dangereux 😜 Cependant, il a pour gros avantage de laisser l’agent travailler sans avoir à valider chacune de ses opérations. L’agent va plus vite, mais nous sommes moins en sécurité !

Guillaume LOURS travaille chez Docker et il nous a présenté leur solution : Docker Sandboxes, avec une démo basé sur Symfony Demo.

L'idée est de pouvoir laisser votre agent faire ce qu'il veut mais dans une sandbox où :

• il n'aura pas accès à tout Internet, configurable locale ou par l'organisation ;
• il ne verra pas vos secrets applicatifs, vos jetons, etc. ;
• il n'aura accès qu'aux fichiers de votre projet.

En interne, c'est comme du Docker-in-Docker : nos projets qui tournent actuellement déjà avec Docker sont cette fois démarrés dans le Docker Sandboxe, avec l'agent et tous les outils dont nous avons besoin.

Nous pouvons noter que Guillaume n’a pas parlé du mode "auto" de Claude. Ce mode se situe entre le mode "manual" et le mode "yolo". Il classifie chaque opération, et ne demande pas de validation tant que l’opération est jugée non dangereuse. Est-ce que ce mode permet d’éviter la complexité de faire tourner son agent et sa stack dans une micro VM ?

C'est plutôt un outil à destination des grands groupes qui ont besoin de contrôler ou limiter les capacités des agents de leurs collaborateurs - à retenir !

La lucidité comme architecture

Bastien JAILLOT a présenté un retour d'expérience à deux voix avec Joël GOMEZ CABALLE, lead dev chez Aropixel. Le point de départ est une billetterie en ligne lancée en 2014 par un développeur seul, qui apprend Symfony 2 en même temps. Le succès arrive vite : rachat, 150 sites en production, plusieurs millions d'euros par mois.

Avec le succès, Joël a voulu une architecture « sérieuse » : microservices, DDD, interfaces partout. Chaque choix avait une bonne raison. Mais ajouter un champ téléphone imposait de traverser un DTO, un transformer, un handler, un repository et un event listener. Le code était réparti sur quatre dépôts. Une développeuse junior devait publier une version de la librairie front, sans tests ni review, juste pour pouvoir avancer. Et on ne déployait qu'une fois tous les quinze jours : le lundi après-midi, plus personne ne committait.

Le talk prend le temps de nommer ce qui bloquait vraiment, et ce n'est pas la technique. À l'écran, les affects s'affichent comme des lignes de log : la confusion et le déni en [WARN], la honte en [ERROR], la peur en [FATAL].

Appelé pour un classique « le site est lent » (nous intervenons régulièrement dans ce genre de contexte), Bastien commence par un constat sans affect : un wrapper d'API n'a aucune raison de tomber avant l'API qu'il enveloppe. Varnish et le user context hash absorbent le trafic qui ne rapporte rien. Mais le vrai chantier est ailleurs : rendre les petits changements faciles avant de simplifier toute l'architecture.

• un monorepo, fait en une heure ;
• un environnement Docker lancé avec Castor ;
• Datadog, que Joël a rebaptisé « Data-drogue » 😂 ;
• du trunk-based development, avec dix déploiements par jour pour une équipe de trois devs ;
• des feature flags activés sur un shop, puis dix, puis tous.

C'est seulement ensuite que Mercure, Memcache, Elasticsearch et toute une API intermédiaire ont pu disparaître, sans feature freeze.

Le dernier chapitre parle des agents IA. Tout ce qui avait été mis en place leur profite à plein. Mais l'enthousiasme de ceux qui s'éclatent avec eux peut, une seconde fois, empêcher de voir ceux qu'on laisse sur le bord du chemin. La conclusion : la lucidité ne se décrète pas, elle se construit, comme une architecture. Le talk se termine sur une question à la salle : et chez vous, qui donne l'alerte ?

Les slides et leurs notes sont en ligne.

Avant que PHP n'exécute ton premier echo : ce que la couche réseau coûte vraiment

Dans son talk, Nicolas PERUSSEL est parti d’un constat. FrankenPHP est arrivé en prod chez beaucoup de monde, et il active par défaut HTTP/3, 0-RTT, Early Hints et les certificats automatiques. Or on ne sait pas toujours ce que ces fonctionnalités font vraiment. L’idée est de suivre ce qui se passe quand un client se connecte, avant même que PHP n’entre en jeu. Ça vaut aussi pour Nginx et Apache.

Le talk commence par un rappel des bases en présentant le modèle OSI (Open Systems Interconnection) pour aider à situer chaque couche du réseau. Vient ensuite le three-way handshake TCP : avant d’échanger la moindre donnée, client et serveur font un aller-retour complet pour établir la connexion.

Nicolas a ensuite évoqué la fameuse notion de RTT (Round Trip Time), rien à voir avec vos congés 🙂. Elle exprime combien coûte un dialogue avec une autre machine sur le réseau. Chaque étape de la connexion se compte en RTT, et c’est ce qu’on cherche à réduire.

Le chiffrement TLS ajoute ses propres RTT par-dessus TCP. TLS 1.2 en coûte 2, TLS 1.3 n’en coûte plus qu’1. Passer en 1.3 est donc déjà un gain direct sur chaque nouvelle connexion. Le RTT est généralement très variable sur mobile comparé à la fibre. Économiser quelques RTT a donc un impact bien plus visible pour les utilisateurs mobiles que pour ceux sur une connexion fixe.

Nous avons ensuite parlé de HTTP/3 et QUIC qui remplace TCP par UDP et englobe TLS 1.3. La connexion et le chiffrement se font en 1 seul RTT au total, contre 2 avec TCP + TLS 1.3. QUIC est implémenté en userspace et non dans le noyau. C’est donc souvent un peu plus gourmand en CPU, avec un p90 légèrement plus élevé. En contrepartie, une perte de paquet n’immobilise plus tous les flux. Avec TCP, un seul paquet perdu bloquait tout le monde. C’est aussi très pratique pour la reprise de connexion lors des changements d’antenne 5G : la connexion survit au changement de réseau au lieu de devoir tout renégocier.

Grâce au 0-RTT, si un client se reconnecte à un serveur déjà connu, il peut envoyer sa requête dès le premier paquet, sans attendre la fin du handshake. Cependant, le 0-RTT expose aux replay attacks : une requête peut être rejouée par un attaquant. Il faut donc le limiter aux routes idempotentes (GET) et ne pas l’accepter sur un POST qui modifie des données.

Avec sa conférence, Nicolas nous a non seulement permis de comprendre ce qu'il se passait dans le réseau lorsque l'on se connecte à un serveur, mais aussi nous a donné plusieurs pistes pour optimiser nos infrastructures. Car même si les réglages par défaut des logiciels aident beaucoup, certains paramètres doivent tout de même être faits à la main : restreindre le 0-RTT, s’assurer que l’infra laisse passer QUIC, activer l’OCSP stapling, etc.

L’Ecosystem Security Team de la PHP Foundation de l’intérieur

Alexandre DAUBOIS est Core Security Engineer à la PHP Foundation. Son rôle est de relire, de tester et de vérifier les différentes failles qui sont découvertes et signalées à la fondation.

Le monde de la sécurité a beaucoup changé cette année. L'avènement des agents a provoqué un afflux massif de rapports, à tel point que les programmes de bug bounty s'arrêtent : ils ne peuvent plus suivre ! Curl, Google, Internet Bug Bounty (IBB)… sont suspendus sous le poids des propositions.

Le goulot d'étranglement, c'est l'humain, car chaque notification doit être vérifiée. Beaucoup de mainteneurs font des burnouts ou n'arrivent pas à suivre. La solution pour ces mainteneurs qui n'ont pas toute une core team, c'est l'Ecosystem Security Team de la fondation, dont Alexandre fait partie.

Un des outils qu'ils utilisent est scrutineer d'Alpha-Omega. C'est un outil pour scanner les projets open source à la recherche de failles, via des agents LLM et des skills, et gérer le processus de divulgation proprement, sans doublons et sans les tartines de texte que les LLM adorent nous faire lire.

Leur premier job avec l'outil a été de scanner les 300 projets les mieux classés en nombre de téléchargements sur Packagist. En un mois, ils ont contacté 35 mainteneurs avec des rapports bien structurés, prouvés et qualitatifs, provoquant plus de 100 corrections !

Lors du scan d'API Platform, une faille a été trouvée. Il a fallu vérifier humainement, car c'est une lourde responsabilité de déclarer une faille : on demande un ID unique mondial, c'est propagé partout, les distributions Linux doivent se mettre à jour, les scanners de dépendances signalent la version concernée… CVE-2026-54164 est né, validé par des humains. On ne peut pas tout automatiser. L'humain voit tout : les conditions que le LLM n'a pas vues, le contexte, la véracité. Merci Alexandre 💪

Les lighting-talks ⚡ !

Bravo à Baptiste LEDUC, qui a présenté PABLO, son orchestrateur maison d’agents et de tâches (vous pouvez en lire plus dans sa série d’articles ici-même).

Xavier LACOT a présenté, pour sa part, une petite liste d’en-têtes HTTP méconnus. Nous y avons, par exemple, découvert les User-Agent Client Hints, avec Sec-CH-UA, ou Sec-GPC, qui remplace le Do Not Track. Et un clin d’œil à redirection.io avec le bien ancien en-tête Refresh: <time>; url=<url>, qu’on vous recommande de ne jamais utiliser 😀

Nous avons aussi découvert nektos/act par l’intermédiaire d’Estelle GAITS, pour exécuter nos GitHub Actions en local 🙏 Outil particulièrement pertinent à mettre en place à un moment où ce sont les agents qui écrivent nos actions !

Enfin, citons Grégoire PINEAU, qui a expliqué son clone du site bien connu « De Gauche ou de Droite ? », mais qui tourne à 100 % dans le navigateur avec un petit modèle d’IA embarqué. Les slides expliquent la démarche, ce qui a fonctionné et ce qui a raté - à lire !

Souveraineté numérique à l'ére de l'IA

Avec Quentin ADAM, CEO de Clever Cloud, pas de langue de bois. Dès les premières minutes, on comprend que le propos sera tranché, et il l'assume pleinement. Il commence par la révolution industrielle : le moteur a remplacé les muscles. Avec un tracteur de 400 chevaux, ce sont 400 chevaux et une centaine de personnes pour s'en occuper qui sont remplacés par seulement une personne pour conduire et une personne pour l'entretien. Puis l'ordinateur a commencé à remplacer les cerveaux.

Selon lui, l'Europe est en train de rater cette nouvelle révolution. Il en donne plusieurs raisons : une gouvernance trop centralisée, une politique qui préserve les emplois des vieilles entreprises au lieu de laisser émerger les jeunes, et une fiscalité qui marche sur la tête (8 % pour les GAFAM, 18 % pour nos grands groupes, 23 % pour nos PME). Les chiffres font mal : sur 100 € dépensés en informatique en Europe, 83 € partent aux États-Unis. Et le Cloud Act donne en prime aux autorités américaines un accès permanent à nos données.

Son message tient en une phrase, qu'il répète sans détour : diversifiez vos achats, achetez local, et écrivez à vos député·es, parce qu'à Bruxelles, en face d'un lobbyiste comme Clever Cloud, il y en a cent payés par les géants américains. Il pousse la logique jusqu'à sa « clause de souveraineté finale » : si Clever Cloud est racheté par un acteur étranger, ses clients obtiennent une licence perpétuelle, ce qui enlève tout intérêt au rachat.

Le seul adversaire qu'il n'a pas réussi à faire plier ce matin-là, c'est le vidéoprojecteur. À chaque GIF, l'écran se figeait et il devait débrancher puis rebrancher le câble HDMI. Cloud souverain ou GAFAM, tout le monde a ses limites, surtout face à la connectique 🔌.

Speed is a byproduct of trust

D’après Sebastian BERGMANN, travailler avec un agent, c’est un peu comme jouer à un jeu d’aventure textuel, sauf que la grande majorité des commandes se résume à "Accept all". Nous finissons par nous y perdre, jusqu'à devoir repartir de la base. Ce talk parle justement des filets de sécurité qui nous permettent de faire confiance à la vitesse des agents qui produisent du code en masse.

La vraie question d’ailleurs, n'est pas de savoir si nous faisons confiance à l'agent, mais si nous faisons confiance à notre pipeline pour garantir que ce qu'il génère est valide.

Sebastian nous présente deux façons de se planter :

• Recklessness (témérité) : de la vitesse sans contrôle. La dette s'accumule plus vite, les erreurs sont les mêmes qu'à la main, elles arrivent simplement plus vite ;
• Stagnation : du contrôle sans vitesse. Le marché nous largue, et la review devient un goulot d'étranglement.

Les deux mènent dans le mur, mais le message central est ailleurs : les équipes ne vont pas plus vite malgré leur quality control, elles vont plus vite parce qu'elles ont confiance en leur quality control. La confiance n'est pas un sentiment, c'est un track record, une suite de résultats observés et reconnus.

Dans un exemple concret, voici ce que nous pouvons mettre en place :

Un domaine isolé dans quelques fichiers PHP qui ne dépendent de rien + un dossier "Application" où l'agent travaille en le respectant sans jamais y toucher.

L'idée : isoler le métier dans quelques fichiers PHP qui ne dépendent de rien, pour que le cœur reste stable et lisible, et laisser l'agent travailler dans un dossier dédié en le respectant sans jamais y toucher. Il gagne un terrain de jeu où produire vite, et une frontière qu'il ne franchit pas.

Le filet tient dans des outils connus (PHP CS Fixer, PHPStan niveau 10, Deptrac, PHPUnit, mutation testing, une CI qui bloque le merge), avec quatre réflexes :

1. Observer le filet attraper des choses ;
2. Transformer les tests en specs ;
3. Inverser le rapport : c’est nous qui spécifions, et c’est l’agent qui implémente ;
4. Puis durcir notre gate.

Et évidemment, écrire les règles en dur dans l'outillage, sinon nous ne les rattrapons jamais.

Côté tests, Sebastian conseille de nommer les tests comme des phrases de ce qui est attendu, et de préférer le TDD (un test venu du code n'est qu'un log). De plus, le coverage ne suffit pas : d'où le mutation testing, où nous cassons le code exprès pour voir si les tests réagissent.

Reste la "Definition of Done", qu’il faut définir, sinon l'agent s'en choisit une tout seul, avec assurance et souvent à tort : plutôt que de dire "écris une classe pour faire X", demandons "fais passer ce test sans le modifier", en lui interdisant de toucher aux tests.

L'humain spécifie le comportement et l'architecture une fois, l'agent implémente jusqu'au vert, l'humain relit.

En résumé, nous ne faisons pas confiance à l'agent, mais au filet construit autour de lui. Les tests sont nos specs, la CI est l'arbitre, l'agent est un outil et pas un collègue. C'est ce track record, et non un sentiment, qui rend la vitesse tenable et qui transforme la fameuse commande « Accept all » en décision.

La vitesse, au bout du compte, n'est qu'un sous-produit de la confiance. ⚡

L'expérience agentique, ou comment tirer le maximum des IAs sur votre code

François ZANINOTTO nous a présenté une série de bonnes pratiques pour coder avec des agents. En voici quelques-unes qui nous semblent intéressantes :

• Donner le contexte métier : le décrire dans AGENTS.md, dans les commentaires du code... Si la documentation est ailleurs, connecter un MCP (coucou Jira / Confluence / Notion...) ;
• Les agents ne peuvent pas mettre tout le code dans le contexte. Ils font des grep en permanence. Il faut donc rendre le code facile à trouver. Utiliser des DTO, du LSP, documenter les synonymes, éviter les noms dupliqués ;
• Il faut être concis, car le contexte de l'agent est limité. Des fichiers courts, des logs peu verbeux, pas de commentaires inutiles, pas de code mort, du Markdown plutôt que du HTML/PDF/DOCX...
• Les modèles ont été entraînés sur du vieux code. Il est donc préférable de choisir des boring tech !
• Aider l'agent à trouver la documentation de vos outils sans parser le Web : ajouter le MCP Context7 ou fournir la documentation directement dans les vendors ;
• Renforcer les garde-fous avant que le code arrive dans la CI ; la boucle agentique doit être capable de tout tester / valider avant d'envoyer le code ;
• Garder la revue de code 💯 ;
• Améliorer le monitoring de production et les procédures de rollback en cas de soucis ;
• Entretenir la mémoire : mettre à jour la documentation en fin de session, faire des skills, nettoyer le harnais agentique.

Pour finir, François confirme ce que nous avons aussi constaté : écrire des tonnes de skills n'est pas nécessaire quand le code de votre projet est déjà clair / bien fait 👍

La review qu'on aurait dû faire depuis toujours : reprendre sa place de reviewer humain à l'ère des agents IA

Gaël CRISPYN délègue maintenant la première review à des agents et il a profité de ce talk pour nous présenter ses bonnes pratiques.

Bien sûr, cela passe par un Skill (de notre côté, nous voyons souvent passer celui-ci) et par des descriptions de PR complètes. Une information que nous trouvons très intéressante, c’est de forcer le développeur à préciser dans chaque PR deux choses :

• ce qu’il a vérifié ;
• ce qu’il n’a pas vérifié !

Ce deuxième point est critique et l’agent pourra focus son étude dessus.

Tout ce qui concerne les coding standards, l’indentation et la cosmétique doit être ignoré par l’agent. L’agent doit aider l’humain à faire sa review, en mettant le doigt sur les points faibles et en questionnant tout ce qui n’est pas carré. Pour que ça fonctionne, il faut donner à l’agent le contexte, les spécifications, l’intention et des PR de taille raisonnable.

Un dernier point d’attention : quand l’agent dit « C’est OK, tout va bien », ce n’est pas OK ! L’humain doit toujours valider.

L’IA dans l’image : La mort du réel ou le moment qu’on attendait toutes et tous ?

La conférence s'est terminée avec Niels ACKERMANN, photographe de presse depuis plus de 20 ans, qui nous a parlé de la transformation de son métier face à l'IA générative. Bien que les générateurs d'images intègrent des filigranes, ils ne sont pas fiables et détecter une vraie photo d'une fausse devient impossible avec les derniers modèles.

Pourtant aujourd'hui, les grandes entreprises de l'IA ne font pas leurs publicités avec l'IA. L'IA ne sait pas innover. Tout ce qu'elles montrent est basé sur des choses qui ont déjà été faites. Donc pour les photos les plus évidentes / consensuelles, les IA remplacent le photographe, et il ne reste que l'innovant et l'inattendu.

Là où la vérité est importante (les médias !), le vrai, le réel, restent aussi importants. Mais pour autant, utiliser l'IA générative pour corriger une photo, l'améliorer ou la recomposer ne devrait pas être un problème tant que c'est dit.

Il a donc créé DALIA Scale, un moyen simple de noter un travail, sans jugement, en fonction de l'utilisation de l'IA générative dans son processus de création. Avec des questions simples (« Qui a l'idée ? », « Qui exécute ? » et « Qui valide ? »), nous pouvons obtenir une note.

• D0 : tout est fait à la main ;
• D5 : l'IA est autonome, elle a tout fait.

Il pousse ses clients à l'utiliser dans leurs appels d'offres, pour demander un « maximum Dalia 2 », par exemple. Cet article est D1 (les agents ne vont pas encore en conférence à notre place !).

Le mot du président de l'AFUP

Benjamin : pour cette année 2026, je suis président de l'AFUP, l'association organisatrice du Forum PHP.

L'évènement existe et rassemble la communauté depuis plus de 25 ans maintenant et est organisé en grande partie par des bénévoles sur leur temps libre : négociation avec la salle, le traiteur, rédaction du CFP et sélection des conférences, gestion du planning et des venues des conférenciers et conférencières, billetterie, beaucoup de coordination logistique, et vous l'avez sûrement vu, beaucoup de pas parcourus pendant un jour de préparation et deux jours de conférences.

Merci à tous les bénévoles et à Amélie pour tout ce travail 💪

À cause des budgets plus serrés que d'habitude ainsi que du profond changement que notre secteur connaît, cette année a été compliquée, et l'AFUP a publié une lettre ouverte pour en parler.

Cependant, cette édition a été une vraie réussite :

• les quelques conférences auxquelles j'ai pu assister m'ont appris des choses et m'ont donné envie de tester tout ça dès mon retour, d'autres m'ont aidé à prendre du recul sur différents sujets : des projets, du code, de l'organisation ;
• j'ai pu retrouver des bénévoles, mais aussi en croiser de nouveaux (qui eux, ont pu découvrir la quantité d'énergie nécessaire pour tenir 3 jours !) ;
• j'ai discuté avec des conférenciers et des conférencières, des responsables d'antennes de l'AFUP qui organisent des meetups régulièrement près de chez vous, des sponsors dont le soutien est indispensable au fonctionnement de l'association, des confrères et consœurs avec qui on a partagé des bières, et évidemment de nombreux visiteurs.

L'AFUP travaille maintenant pour s'adapter également, et nous nous revoyons aux prochains événements AFUP en 2027 🎉

En conclusion 🐘

Merci à l'AFUP pour ces deux jours riches en échanges, en discussions et en IA ! C'était clairement le sujet de l'année, et peu de gens dans la salle lèvent encore la main quand on demande "qui code sans IA". Notre métier change très vite et vivre de telles conférences nous aide à nous orienter dans ce paysage mouvant.

Comme dirait un bénévole à la fin d'un talk : On a plus le temps pour les questions ! Merci pour votre attention !

Et à l'année prochaine 🙏

Dans AutoMapper, notre solution pour accélérer tous vos mappings de données dans vos projets (sérialisation, object mapping, etc.), nous supportons déjà 2 composants de Symfony en proposant une implémentation alternative :

• symfony/object-mapper : Faire un mapping entre 2 objets
• symfony/serializer : (Dé)sérialiser dans différents formats

Ajouter la gestion des flux JSON de la même façon (être une implémentation de l’interface) nous a paru naturel, tous ces composants font exactement la même chose : passer de la donnée de A vers B avec une représentation ou un format légèrement différent.

Nous supportons déjà depuis quelque temps le fait d’avoir un mapping Lazy, a.k.a le mapping s’effectue uniquement au moment où on a besoin du champ (si jamais on ne touche à rien : rien n’est mappé). Le fait de pouvoir passer d’un objet à un flux json fut donc très facile à réaliser.

Mais en travaillant sur l’autre sens : lire un flux pour le transformer en objet, l’implémentation nous a paru beaucoup plus complexe, il fallait revoir toute la partie où on lit la donnée dans la source (le flux JSON).

Lazy JSON

AutoMapper possède déjà toute la connaissance nécessaire pour transformer un tableau vers un objet.

L’idée était donc de lui fournir quelque chose qui se comporte comme un tableau PHP, sans réellement décoder tout le JSON.

C’est cette idée qui a donné naissance à une nouvelle librairie.

json-stream-polyfill : une première implémentation en PHP

joelwurtz/json-stream-polyfill est la première implémentation, entièrement écrite en PHP.

L’objectif était d’avoir une API aussi simple que json_decode() :

$data = json_stream_decode($json);

avec une différence importante : on peut également lui passer directement un flux.

$data = json_stream_decode(
    fopen('huge.json', 'r')
);
echo $data['user']['name'];

Le résultat est un JsonStream\Document, qui se comporte comme un tableau PHP classique grâce notamment à ArrayAccess, IteratorAggregate et Countable, mais dont les données sont résolues de manière lazy.

L’appel à json_stream_decode() est quasiment instantané. Le JSON est parsé au fur et à mesure des accès : demander user.name fait avancer le flux jusqu’à cette donnée et seules les valeurs nécessaires sont matérialisées en PHP. Un champ a au final trois états :

• Non lu : on ne l’a pas encore vu dans le flux
• Bufferisé : on est passé dessus mais on garde toujours sa représentation en JSON (chaîne de caractères)
• Parsé : le champ a été lu, parsé et transformé en valeur PHP

Pour AutoMapper, c’est particulièrement intéressant : son code généré peut continuer à lire la donnée comme il le fait déjà, tandis que le parsing JSON reste complètement lazy.

Le polyfill introduit également JSON_STREAM_TRANSIENT :

$data = json_stream_decode(
    $stream,
    JSON_STREAM_TRANSIENT
);

Dans ce mode, les données déjà parcourues peuvent être libérées. On peut donc lire un document arbitrairement gros avec une consommation mémoire stable.

La contrepartie est importante : la lecture devient forward-only. Une donnée déjà dépassée peut être définitivement perdue. Ce mode est donc surtout intéressant lorsque l’on parcourt tout le document dans son ordre naturel, typiquement une grosse collection JSON.

Cette première implémentation fonctionne bien et valide l’API, mais elle possède une limite assez évidente : scanner un énorme JSON en pur PHP reste lent, surtout lorsqu’on finit par lire l’intégralité du document.

Il fallait donc aller plus bas.

json-stream : la même chose, mais en extension PHP

joelwurtz/json-stream expose exactement la même API :

$data = json_stream_decode($json);

mais directement sous forme d’extension PHP, installable avec pie via pie install joelwurtz/json-stream.

L’intérêt n’est pas uniquement de déplacer le code en natif. L’extension utilise également SIMD pour scanner rapidement la structure du JSON, avec différentes implémentations suivant le CPU : AVX2, SSSE3 ou SSE2 sur x86-64, NEON/PMULL sur ARM64, ainsi qu’un fallback scalaire.

Le fonctionnement reste le même : le document est lazy et seules les valeurs effectivement demandées sont matérialisées.

C’est important parce que le parsing n’est finalement qu’une partie du coût d’un json_decode(). Une fois le JSON compris, PHP doit encore créer les zval, strings, arrays et HashTables correspondants.

JSON → parsing → zval / arrays / strings → objets

SIMD permet d’accélérer fortement la première étape, mais pas de faire disparaître les suivantes.

C’est pourquoi json-stream peut être plus rapide que json_decode() dans certains cas, notamment lorsque seule une partie du document est utilisée, sans pour autant être magiquement dix fois plus rapide lorsque tout doit être matérialisé.

Et comme le polyfill et l’extension partagent la même API, le code ne change pas selon l’environnement : le polyfill fonctionne partout et l’extension peut être installée lorsque les performances deviennent importantes.

AutoMapper 10.3

Tout cela nous ramène à AutoMapper.

Avec la 10.3, AutoMapper intègre le support de symfony/json-streamer. Le bundle peut remplacer l’implémentation de Symfony et utiliser le moteur de mapping généré d’AutoMapper.

automapper:
    json_streamer:
        enabled: true

On continue ensuite à utiliser l’API JsonStreamer :

$users = $reader->read($stream, $type);

Le mapping passe par AutoMapper et bénéficie de toute la configuration : ObjectMapper, Serializer et JsonStreamer utilisent désormais le même moteur de mapping. Les attributs et fonctionnalités supportés par AutoMapper fonctionnent donc quelle que soit la porte d’entrée utilisée. Cela inclut également les attributs Symfony Serializer supportés par AutoMapper : il n’est plus nécessaire de maintenir une configuration ou avoir des objets différents simplement parce que l’on passe au streaming.

Benchmarks

Pour la release de cette nouvelle version nous avons aussi mis en place des benchmarks que vous pouvez exécuter vous-même si besoin.

AutoMapper propose de nombreuses options pour optimiser le code généré. La désactivation des checks sur les attributs en est un bon exemple : ils ne servent que si vous faites du mapping dynamique, typiquement un appel d’API qui choisit lui-même les champs à retourner. Par souci de cohérence avec le comportement par défaut du serializer de Symfony, ces checks restent malgré tout activés par défaut, et les benchmarks permettent justement de mesurer ce qu’ils coûtent.

Plutôt que de dérouler tous les scénarios, voici les quatre comparaisons qui correspondent aux portes d’entrée de Symfony. Les trois premières lignes mappent un objet Person unique ; les trois dernières lisent ou écrivent une collection de 20 000 Person, en mode streamé des deux côtés (STREAM pour AutoMapper, iterable / getIterator() pour Symfony), chaque objet étant entièrement hydraté à la lecture.

L’écriture ne décode rien : elle est strictement insensible à l’extension, et c’est le seul scénario où Symfony reste devant — de 2.5× par défaut, de 1.4× une fois l’attribute checking désactivé. C’est logique : son writer compilé lit les champs directement sur l’objet, là où AutoMapper fait passer chaque élément par le pipeline de mapping complet — renommages, transformers, #[MapTo], propriétés privées, discriminateurs… C’est le prix de la cohérence entre les trois portes d’entrée, et il nous paraît raisonnable.

La lecture, en revanche, passe de 1.112 s à 152.6 ms avec l’extension, soit 7.3× de gain : c’est elle qui fait basculer le streamer d’AutoMapper de « à peine plus rapide » à « un ordre de grandeur plus rapide » que celui de Symfony. Dès que vous lisez du JSON avec le streamer, installez-la.

Côté mémoire, les deux streamers gardent un pic plat quelle que soit la taille de la collection — environ 10 MB pour Symfony, 21 MB pour AutoMapper avec l’extension en lecture, 7.2 MB pour les deux en écriture — c’est tout l’intérêt. Encore faut-il demander le bon type à Symfony : avec Type::list(...) au lieu de Type::iterable(...), le reader matérialise tout et le pic monte à 682 MB sur les mêmes 20 000 objets.

Enfin, la colonne « opti. (sans attribute checking) » parle d’elle-même : c’est de loin le levier le plus rentable côté AutoMapper, avec 2 à 3× sur les scénarios unitaires, 1.7× en lecture streamée et 1.8× en écriture streamée. Et c’est une fonctionnalité rarement utilisée.

La fonctionnalité est encore jeune : testez-la sur vos gros JSON et faites-nous vos retours !

En résumé :

Cet article détaille les évolutions majeures de la plateforme développeur HubSpot concernant la gouvernance des applications, la gestion des APIs et la sécurité. Il présente l’introduction du versioning prédictif par date, le passage obligatoire aux granular scopes (principe du moindre privilège) et la mise à disposition d’outils d’aide à la migration (HubSpot CLI, onglet de migration dédié). Destiné aux DSI et chefs de projets digitaux, ce guide permet d’anticiper la mise à jour des intégrations CRM et d’assurer une gouvernance SI optimale.

L’écosystème d’intégrations de votre CRM est le cœur battant de votre SI. Avec les dernières évolutions de sa plateforme développeur, HubSpot opère un tournant majeur en matière d’app governance, d’architecture API et d’habilitations. Entre l’instauration d’un versioning horodaté prédictif, la transition vers les granular scopes et le déploiement d’outils d’aide à la migration automatisés, les DSI et chefs de projets digitaux disposent de nouveaux leviers pour sécuriser leurs flux de données. Nous allons découvrir ensemble comment ces nouveautés renforcent la stabilité de votre SI et quelles démarches suivre pour faire évoluer vos applications en toute sérénité.

Une feuille de route connue pour l’évolution des APIs

Pendant longtemps, le cycle de vie des APIs pouvait générer des incertitudes techniques au sein des équipes informatiques. Pour offrir une prédictibilité maximale aux DSI et aux responsables informatiques, HubSpot adopte désormais un modèle de versioning basé sur les dates. Concrètement, les versions des APIs et de la plateforme (par exemple la version 2026.03) atteignent un statut stable à une date fixe et connue. Après le lancement d’une version, seules des corrections de bugs peuvent intervenir, aucun changement majeur ne peut intervenir. HubSpot instaure des fenêtres de support de 18 mois et regroupe les changements majeurs (breaking changes) à un rythme semestriel prévisible.

Pour une DSI, cette évolution change la donne :

• Prévision budgétaire et technique : Vous planifiez la maintenance applicative dans votre feuille de route sans subir des interruptions inopinées.
• Fin des ruptures brutales : Les fenêtres de migration de 18 mois vous laissent le temps d’auditer et de mettre à niveau vos connecteurs.
• Standardisation des projets : Grâce au framework Projects et au fichier de configuration hsproject.json, l’ensemble des scripts et fonctions serverless est versionné de manière explicite et rigoureuse.

Scopes granulaires et gouvernance : appliquer le principe du moindre privilège

La sécurité des données et le respect de la conformité (RGPD) sont au centre des préoccupations des entreprises. Jusqu’à présent, l’installation d’une application nécessitait souvent la validation de périmètres d’accès très larges (comme un accès global au hubdb ou aux tickets).

HubSpot remplace ces périmètres génériques par des granular scopes (ou périmètres granulaires) fondés sur le principe du moindre privilège. Par exemple, au lieu d’autoriser un accès général au CRM, une application doit solliciter des autorisations précises telles que hubdb.tables.read ou crm.objects.tickets.write.

Cette approche apporte des avantages concrets pour la gestion de vos projets :

1. Contrôle d’accès ciblé : Chaque intégration ne lit et ne modifie strictement que ce dont elle a besoin pour fonctionner.
2. Adoption facilitée et confiance : Les responsables métier et administrateurs valident les applications plus rapidement, sachant que le périmètre est restreint.
3. Traçabilité et responsabilité : Chaque application connectée est désormais rattachée à un propriétaire formel (app owner). Un journal d’activité (activity log) permet de suivre les autorisations et prévient les ruptures de flux lors du départ d’un collaborateur.

Quelles aides à la migration pour faire évoluer vos applications ?

Faire évoluer un écosystème applicatif existant peut sembler complexe. HubSpot a déployé des fonctionnalités et des outils de migration avancés pour guider les équipes techniques à chaque étape.

1. Un onglet de migration centralisé dans votre portail

Dans le portail développeur, un nouvel onglet dédié aux migrations vous donne une vision consolidée de votre dette technique. Vous identifiez immédiatement :

• Les applications et les clés de services utilisant encore des APIs historiques.
• Les connecteurs devant passer sur le framework Projects.
• L’échéance exacte des fenêtres de support pour planifier vos interventions.

2. Migration automatisée via la HubSpot CLI

Pour les développeurs et chefs de projets digitaux, le passage au framework moderne s’effectue directement en ligne de commande via la HubSpot CLI (version 7.6.0 ou supérieure). Deux commandes spécifiques permettent de vous aider à migrer vos apps legacy et les apps dans des anciennes versions du framework Projects. Les apps les moins complexes seront migrées sans aucune intervention de votre. Et côté backend de votre application aucune modification ne sera nécessaire car les clés d’authentification sont préservées sans interruption de service pour vos utilisateurs.

3. L’outil d’évaluation automatique des scopes (Scope Migration Tool)

Concernant la transition vers les granular scopes, HubSpot propose un outil d’analyse automatisé. En observant l’historique d’appel de vos APIs en environnement réel, l’outil suggère exactement les scopes granulaires nécessaires à votre application, évitant ainsi toute phase de re-paramétrage manuel fastidieux.

L’accompagnement Synolia pour la pérennité de votre plateforme CRM

Gérer le cycle de vie des APIs, effectuer les montées de version et garantir la sécurité des flux entre HubSpot et le reste de votre système d’information exige une méthodologie rigoureuse.

Spécialisée en data integration et en déploiement CRM, Synolia accompagne vos équipes à chaque étape :

• Audit applicatif : Analyse de votre parc d’applications privées et publiques pour identifier les endpoints obsolètes.
• Refonte d’architecture : Migration de vos scripts vers le framework Projects et sécurisation des accès par les scopes granulaires.
• Gouvernance SI : Alignement des règles d’habilitation avec la politique de sécurité globale de votre entreprise.

Nous espérons que cet article vous sera utile pour anticiper ces évolutions. Si vous souhaitez sécuriser l’architecture de vos applications ou faire évoluer votre plateforme CRM, les équipes de Synolia sont à votre écoute pour vous conseiller ! 

Contactez-nous !

Foire aux questions (FAQ)

Cet article Nouveautés HubSpot apps et APIs : versioning, granular scopes et aides à la migration pour sécuriser votre SI est apparu en premier sur Synolia, agence e-commerce, CRM, Data, PIM/DAM, OMS.

Depuis plus de 15 ans, nous construisons des logiciels et des architectures robustes : des API, des applications web, des infrastructures cloud. Nous avons créé et maintenons API Platform, FrankenPHP, Mercure, et nous contribuons quotidiennement à PHP, Symfony, Caddy, Go… Des outils libres que des dizaines milliers d’équipes utilisent chaque jour dans le monde entier. Le 17 septembre dernier, lors de la keynote d’ouverture de Kévin Dunglas à l’API Platform Con 2026, nous avons annoncé le lancement de Tilia, notre structure spécialisée dans l’intelligence artificielle.

Notre constat

Presque toutes les organisations que nous avons accompagnées ces derniers mois ont testé l’IA générative : un assistant de rédaction, une preuve de concept, un prototype. Et souvent, l’expérience s’arrête là. L’outil ne communique ni avec le CRM, ni avec le groupware, ni avec l’ERP, ni avec l’outil de ticketing, ni avec la base documentaire… Les données sensibles ne peuvent pas être envoyées vers n’importe quel cloud tiers. Et les équipes hésitent, à juste titre, à confier leurs processus métier à une boîte noire qui ne fonctionne pas de manière déterministe. Le problème n’est pas l’IA, c’est son intégration, et l’intégration c’est notre expertise depuis toujours.

Connecter l’IA à ce qui existe déjà, en gardant le contrôle

Tilia part des systèmes que vous faites déjà tourner. Nous connectons vos données et vos applications à des assistants IA en développant des serveurs MCP sur mesure, nous concevons des workflows où des agents prennent en charge les tâches répétitives, nous construisons vos RAG, nous créeons des modèles personnalisés (fine tuning) ou entrainés sur mesure. Nous déployons et maintenons les architectures cloud souveraines qui vont avec, 24 heures sur 24. Et nous formons vos équipes, avec des formations adaptées à tous les niveaux, dispensées par notre organisme certifié Qualiopi.

À travers ces services, vous gardez le contrôle : un agent IA est un assistant très rapide, pas un décideur. Il pré-remplit, vous contrôlez. Cette rigueur évite les erreurs coûteuses et garantit une chose simple : que la technologie reste au service de vos métiers, et pas l’inverse.

15 ans d’expertise web à votre service 

L’IA en entreprise est d’abord une problématique d’ingénierie. Elle demande des modèles de données et des API propres, des systèmes robustes, des bonnes pratiques de sécurité, de l’observabilité. C’est ce que nous faisons depuis 15 ans, et nos contributions au cœur des logiciel qui font tourner le web le montrent publiquement. Nous sommes aussi une coopérative, détenue à 100 % par ses 80 salarié·es et certifiée B Corp, engagée pour un numérique responsable. Nous n’avons pas d’actionnaires à satisfaire en vendant de l’IA partout. Nous avons des clients à servir, et une conviction : la technologie doit rester au service des personnes qui l’utilisent.

Découvrez Tilia

Tilia a son propre site web. Vous y trouverez nos domaines d’expertise, nos formations, nos études de cas. Et c’est toujours notre équipe de 80 expert·es aux manettes. Vous avez un cas d’usage en tête, ou simplement des questions ? Écrivez-nous à notre équipe !  

Cet article, Les-Tilleuls.coop annonce le lancement de Tilia, son offre d’accompagnement sur mesure en intelligence artificielle, est paru en premier sur Les-Tilleuls.coop.

Où nous en étions

Dans mon article précédent, je décrivais mon environnement de travail : un Agent Development Environment, non pas un IDE avec un panneau de conversation greffé, mais un outil construit autour de tâches, de worktrees et d'agents. Je prends une issue, l'ADE ouvre un worktree isolé avec un agent déjà en cours d'exécution, et je dirige cet agent au lieu de taper du code. Par-dessus se trouvent les agents que j'ai affinés pendant des mois, tous en lecture seule par construction ; build est le seul autorisé à modifier le code.

Les gains de ces agents se concentrent en un point : la compréhension. À mon travail, nous n'avons pas d'équipes spécialisées, donc n'importe qui peut se voir confier n'importe quelle tâche : un bug de synchronisation de stock le matin, une fonctionnalité dans une partie du code que je n'ai jamais ouvert l'après-midi, le prochain ticket dans l’application retail. Chaque tâche pourrait être un domaine différent avec ses propres règles métier, et je bascule entre elles trois ou quatre fois par jour. L'agent task-analyst lit le ticket, ses parents et le code associé, puis me livre l'ensemble en une seule lecture.

Comprendre un ticket est une chose, mais une fonctionnalité n'est pas terminée quand la branche est poussée. Entre le code et la production se trouve un second métier fait d'attente et de vérifications : le statut de la CI, les reviews, la QA. Tout cela vit dans GitHub et Jira, en dehors de mes worktrees. J'avais automatisé la réflexion et gardé l'attente.

Cet article porte sur l'outil que j'ai construit pour combler ce fossé : PABLO, une application Symfony. En son cœur se trouve une machine à états, quelque chose que les développeurs PHP livrent depuis une décennie sous un nom moins à la mode que celui qu'utilise l'écosystème IA aujourd'hui.

Les corvées que personne n'a automatisées

Voici à quoi ressemblait réellement mon matin : avant d'écrire la moindre ligne, je devais traiter une checklist mentale sur 5 ou 6 pull requests ouvertes et deux ou trois projets.

• La CI est-elle verte ? L'ADE n'affiche le statut que pour la PR du worktree courant ; les autres vivent dans des onglets de navigateur.
• Quelqu'un les a-t-il reviewées, et est-il temps de redemander sans devenir la personne qui demande toutes les 90 minutes ?
• La QA les a-t-elle planifiées, ou cassées ?
• Du feedback est-il arrivé sur le ticket ? Le trouver, recréer un worktree pour une branche supprimée la semaine dernière.
• La CI est-elle rouge ? Alors tout ce que les agents font pour moi est inutile tant que je ne relance pas les choses moi-même : remarquer l'échec, créer un worktree, choisir l'agent, le lancer, attendre.

Rien de tout cela n'est difficile, et c'est exactement le problème : chaque point coûte un changement de contexte, la chose que j'avais passée un an à éliminer. Ce ne sont jamais les minutes qui faisaient mal ; ce qui faisait mal, c'était l'entrelacement : vérifier la CI, revenir à une tâche, se rappeler que personne n'a reviewé, revenir encore.

Mes agents avaient éliminé le bruit, rendant le travail facile à comprendre. Mais le coût du suivi de toutes ces tâches restait le mien. Une douzaine de pièces mobiles à travers trois outils, et dans ce système, quelque chose doit poller. C'était moi.

PABLO

Alors j'ai fait : PABLO, pour Personal Assistant for Boring Logic & Operations. L'acronyme est venu après le nom, mais « boring » (ennuyeux) est le mot honnête dedans. Rien de ce que fait PABLO n'est malin : il regarde les pull requests, lit les dates, les compare avec 10 minutes auparavant, et conclut que quelque chose a changé (ou pas).

L'ADE reste l'endroit où je travaille, et PABLO reste un niveau au-dessus, répondant en boucle à une seule question : étant donné l'état de cette pull request, y a-t-il quelque chose qu'un agent devrait faire, et si oui, lequel ? Quand la réponse est oui, PABLO lance automatiquement cet agent via le binaire de l'ADE, dans le bon worktree, exactement comme je l'aurais fait.

Sous le capot se trouve une application console Symfony avec trois points d'entrée :

• un binaire pablo ;
• la console Symfony ;
• un petit dashboard.

Il y a une exception à ce tableau : /pablo-commit-and-pr est une commande OpenCode, pas une commande PABLO. L'agent écrit le message de commit et la description de la pull request (la seule partie du flux où un agent bat du simple code), puis rend la tâche à PABLO, qui déplace la tâche vers l'état draft et prend le relais.

Et enfin, un scheduler en arrière-plan (systemd sur Linux ou launchd sur macOS) met à jour les informations sur les pull requests toutes les cinq minutes.

Cette séparation compte plus qu'il n'y paraît. PABLO ne demande jamais qu'à lancer un agent dans un worktree et à être prévenu quand le run se termine, donc tout ce que PABLO sait de l'ADE tient derrière une seule interface : AgentLauncherInterface. L'interface rend l'ADE remplaçable : si un meilleur arrive le mois prochain, je réécris une classe. Le remplacement a déjà eu lieu une fois : je travaillais avec Orca avant, et je travaille avec OpenChamber aujourd'hui. Un couplage va plus loin : quand l'ADE refuse un worktree, la porte de secours est un opencode run headless. PABLO ne dépend vraiment que d'OpenCode.

Pourquoi PHP pour un daemon en arrière-plan en 2026 ? C'est le langage dans lequel je pense le plus vite, et le seul utilisateur, c'est moi.

Une dernière décision : PABLO ne stocke aucun token et ne parle à aucune API. Tout passe par des CLIs déjà authentifiés sur ma machine (gh, acli, linear, orca, openchamber), donc il n'y a rien à faire tourner ou à fuiter. Quand quelque chose manque, pablo system:doctor le dit, avant qu'un cron n'échoue silencieusement à 3 heures du matin.

L'intelligence a toujours été dans les agents. Ce qui manquait, c'était quelque chose d'assez bête pour tourner toutes les cinq minutes pour toujours sans s'ennuyer.

Graph engineering, ou : une machine à états avec un meilleur nom

Si vous avez lu sur les agents IA récemment, vous avez vu le terme « graph engineering » : modéliser le travail en nœuds et en arêtes au lieu d'un seul énorme prompt. Enlevez le vocabulaire à la mode, et ce n'est qu'une machine à états. Parce que le développement logiciel est brouillon, la machine à états de PABLO doit être flexible. Plusieurs états doivent facilement retomber sur draft, et une commande manuelle peut extraire une tâche d'un état à tout moment. Les frameworks de machines à états lourds exigent de déclarer à l'avance chaque transition autorisée et bloquent tout le reste. C'est trop rigide pour mon workflow, alors j'ai sauté les frameworks et construit un moteur simple : des états, des transitions, et une règle souple sur ce qui est autorisé depuis où.

Dans la plupart des frameworks d'agents, les nœuds sont des étapes de raisonnement (plan, search, summarize, critique), et le graphe vit à l'intérieur de la tâche. Dans PABLO, les nœuds sont les états qu'une pull request traverse dans une vraie équipe : drafted, CI en échec, attente de review, changes requested, attente de QA. Le graphe n'est pas l'agent : c'est le processus dans lequel je travaille déjà. C'est ce qui garde le graphe stable après la prochaine sortie de modèle, les prompts et les modèles vivant à l'intérieur des nœuds.

Donc la machine à états est une table. Littéralement une table, dans une classe :

State::Draft->value => ['emoji' => '📝', 'label' => 'draft',
                        'onEnter' => [self::class, 'enterDraft'], 'polled' => true],
State::CiRed->value => ['emoji' => '🔴', 'label' => 'ci-red',
                        'onEnter' => [self::class, 'enterCiRed'], 'polled' => true],

Chaque ligne de la table déclare comment afficher l'état, ce qui s'exécute à l'entrée, et si le poller le surveille. À côté de la première table, une seconde dit ce que chaque état peut vérifier :

public const POLL_CHECKS = [
    State::Draft->value         => ['checkCiRed', 'checkCiGreen'],
    State::CiRed->value         => ['checkCiGreen'],
    State::ReadyToReview->value => ['checkCiRed', 'checkReviews'],
    State::WaitingReview->value => ['checkCiRed', 'checkReviews'],
    State::NeedsTesting->value  => ['checkFailureSignal'],
];

C'est tout le moteur. Ajouter une étape est une ligne et une méthode, pas un refactoring. Le handler on-enter unique est partagé par le poller, les commandes et les overrides manuels, donc les transitions ne divergent jamais. Même idée pour les trackers : une interface de provider, et la machine à états n'a aucune idée de quel tracker elle parle.

Les états, et ce qui les réveille

Il y a neuf états. Pas de todo, pas d'init, exprès : une issue que je n'ai pas commencée n'a pas de tâche et apparaît simplement dans la liste de ce qui m'est assigné. Entrer dans in-progress crée la tâche, la branche, le worktree et le premier run d'agent ; un merge ferme la tâche depuis n'importe où et supprime le worktree.

La forme de la chose, en graphe :

Regardez les flèches, pas les boîtes : chaque flèche vers draft est une commande que j'ai tapée ; chaque autre flèche est le poller. Je décide quand le travail quitte mes mains ; la machine gère le reste.

Trois détails ont demandé bien plus d'itérations que prévu.

Le premier : ce qui compte comme une review. Mes propres reviews sont exclues : répondre à un commentaire sur ma propre pull request crée une review à mon nom, ce qui me renverrait sinon en draft juste pour avoir répondu à une question. Les reviews de bots sont ignorées sauf whitelist. Seules les reviews postérieures au dernier événement timeline ready_for_review de GitHub comptent (un vrai timestamp, contrairement au verdict du summary), donc une approbation périmée ne peut pas fuiter dans ce tour. La dernière review par reviewer gagne, et tout ce qui n'est pas une approbation bat toutes les approbations : si quelqu'un a pris la peine d'écrire, je lis le feedback avant que la QA ne le fasse.

Le deuxième : exactement un seul chemin de retour vers draft, et c'est une commande. Pas de détection de push : un git push brut ne déplace rien. Cela semble restrictif jusqu'à ce qu'on considère que je pousse des dizaines de fois par jour, souvent juste pour lancer la CI. Une commande explicite est un signal. Un push est du bruit.

Le troisième : ce que j'ai délibérément choisi de ne pas traiter comme des événements. CI pending ne déclenche rien. CI rouge dans needs-testing ne déclenche rien non plus : un build cassé apparaîtra au moment du merge, et interrompre la QA n'aide personne. La moitié de la conception d'une machine à états, c'est choisir ce qui n'est pas un événement, et cette moitié ne reçoit presque aucune attention.

Ce que « vert » veut réellement dire

Deux de ces transitions pendent à une question : la CI est-elle verte ? Cela ressemble à un fait qu'on vérifie. Ça n'en est pas un.

Ma première version : rouge en échec, vert quand tout passe, en attente sinon. Cette règle fonctionnait partout sauf sur le projet où j'avais le plus besoin de PABLO.

Ce projet tourne sous CircleCI, qui publie ses deployment gates sur GitHub comme status contexts : deploy-code-approval-ppr, deploy-code-approval-qlf. Ce sont des gates manuelles sur chaque pipeline, y compris les branches de feature où personne ne clique dessus (nous ne déployons pas en qualification à chaque commit). Elles restent à PENDING pour toujours, ou arrivent en ACTION_REQUIRED, que ma règle comptait comme échec, donc « La CI est-elle verte ? » n'était jamais oui.

Le correctif est une ligne de configuration dans PABLO :

ci:
  ignore_checks: ["approval"]

Tout check dont le nom, le workflow ou le status context contient cette sous-chaîne est retiré de la question entièrement : il ne peut ni rendre le verdict rouge, ni le retenir en attente pour toujours. Deux gates, un mot.

Cette unique clé de configuration m'a forcé à réaliser quelque chose : une CI verte est une règle, pas un fait. Ce que GitHub appelle un « CI check » est en réalité un tas bruyant de tests unitaires, de gates de déploiement manuelles et de bots bavards. Comme aucun outil ne peut deviner magiquement lesquels comptent réellement pour une branche donnée, PABLO pousse cette décision vers le fichier YAML du projet. Pour garder le moteur simple, j'ai ajouté deux autres règles brutales : un dépôt avec zéro check est considéré comme vert, et le matching par sous-chaîne reste volontairement bête.

La seule exception à mon propre dogme

Dans mon article précédent, j'ai fait un point sur le fait que mes agents sont en lecture seule, pas par instruction mais par construction : le frontmatter (voir mon article précédent pour comprendre ce qu'est un frontmatter) refuse edit et write. Les quatre analystes de PABLO suivent la même règle : modèle pas cher et rapide, interdit en écriture.

Mais il y a cinq agents. Le cinquième agent est rebase-conflict-resolver, le seul endroit où j'ai cassé ma propre règle exprès. Toutes les douze heures, un job de sync rebase chaque worktree de mes tâche sur la branche primaire. En cas de conflit, git abandonne et réinitialise le worktree, et un agent est lancé pour refaire le rebase et résoudre chaque conflit. Son frontmatter montre le coût : edit: allow, write: allow, git push*: allow.

Pourquoi le laisser entrer ? La sync est un dry run par défaut. Une clé de configuration transforme le rapport en action : auto_apply: true, posé seulement là où je suis sur que j’ai le moins de risques possibles.

Son rayon d'action est borné comme tout le reste. Il peut écrire du code et pousser, mais toute commande agissant sur le processus plutôt que sur le code (merging, approving, commenting) est refusée. Il peut réécrire ma branche ; il ne peut ni l'approuver, ni la merger, ni parler en mon nom. La permission dangereuse n'a jamais été edit ; c'était agir en tant que moi devant d'autres personnes. Deux garde-fous de plus : une branche sale (fichiers non commités restants) n'est jamais rebasée, et quand l'agent prend le relais d'un rebase, PABLO affiche une commande claire et copiable pour voir la session de l'agent dans OpenCode.

Git fait le travail de sécurité restant. Le push est toujours --force-with-lease, jamais un --force nu. Si j'ai poussé moi-même pendant que le cron tournait, la vérification de lease échoue, le worktree revient en arrière, et le job réessaie douze heures plus tard. Mon push gagne toujours. Quand un conflit nécessite vraiment un humain, l'agent affiche PABLO_CONFLICT_UNRESOLVABLE et ne pousse rien.

La partie honnête : cet agent peut faire des dégâts, contrairement aux quatre autres. J'accepte ce risque parce que tout ce qu'il écrit atterrit dans une pull request que je review avant le merge. C'est mon propre code. En échange, je n'ai pas eu de pull request en conflit depuis un moment.

Tout ne mérite pas un LLM

Dans mon article précédent, je décrivais deux de mes commandes d'agent préférées : des prompts quotidiens qui appelaient le CLI gh, lisaient mes pull requests ouvertes, et utilisaient un LLM pour écrire un message Slack demandant à l'équipe des reviews et de la QA. Ça ressemblait à de la magie à l'époque. Aucune des deux n'a survécu. Elles sont maintenant simplement pablo show:prs : un script PHP lisant depuis le cache du poller, affichant exactement le même markdown prêt pour Slack avec une file de review, un séparateur, et une file de QA. Aucun LLM impliqué.

Le même instinct a façonné le dashboard web, rendu depuis le cache du poller, et cela mène à quelque chose à quoi je ne m'attendais pas. Un outil construit pour orchestrer des agents IA s'avère être des timestamps, des file locks, du CLI parsé et une table de transitions autorisées. L'intelligence est dans cinq fichiers markdown ; tout le reste est de la plomberie sans éclat qui décide quand ouvrir le robinet.

Ce qui a réellement changé

La différence la plus claire : je n'ai pas vérifié moins, j'ai arrêté de vérifier moi-même.

Plus de tour de mes pull requests pour des pipelines rouges, plus de chasse aux reviews. Une liste, pablo tasks ou le dashboard web, me dit ce qui m'attend ; tout le reste est le tour de quelqu'un d'autre.

Le cas de la CI à lui seul a valu la construction de PABLO. La CI passe rouge à onze heures du soir, le poller le remarque en moins de dix minutes et lance ci-analyst dans le bon worktree ; au matin, le diagnostic attend. L'analyse était déjà automatisée par mes agents ; ce qui a changé, c'est que le fait de remarquer et l'attente sont automatisés aussi.

Une tâche complète se passe maintenant ainsi : pablo task:start sur un lien Jira, travailler avec l'agent, /pablo-commit-and-pr, et arrêter d'y penser.

pablo task:start https://acme.atlassian.net/browse/XXX-123

Le temps de cerveau est la ressource

Le coût caché du développement moderne, ce ne sont pas les trois minutes que prend la vérification d'un pipeline CI ; c'est la taxe cognitive de garder cet onglet ouvert à l'arrière de votre tête. Le deep work exige de longues périodes d'attention ininterrompues. Quand vous le fracturez avec un ping-pong administratif : rafraîchir GitHub, courir après des approbations, se demander si la QA a pris votre ticket. Vous ne perdez pas seulement du temps, vous brûlez l'énergie mentale exacte dont vous avez besoin pour résoudre des problèmes difficiles. Je n'ai pas construit PABLO juste pour taper moins de commandes bash, ni pour automatiser pour automatiser. Je l'ai construit pour qu'il serve de bouclier cognitif. En déléguant la bureaucratie de la mise en production à une boucle PHP bête et inlassable, j'ai cessé d'être un routeur humain pour mes propres tâches. Je peux de nouveau être simplement un ingénieur.

PABLO est public

PABLO est public : github.com/korbeil/pablo. Il est construit pour exactement un utilisateur, le workflow de mon équipe, mes CLIs, ma tolérance à l'attente ; rien de tout cela n'est universel. Le publier revient à tendre à quelqu'un un fichier de config bien tenu : quelque chose à lire, à emprunter et à casser. La machine à états est une table précisément pour que la vôtre remplace la mienne sans combat.

Si vous voulez l'essayer, la version courte :

git clone https://github.com/korbeil/pablo && cd pablo
./bin/install.sh        # deps, liens agents/commandes, démarre le scheduler,
                        # finit avec pablo system:doctor
pablo system:doctor     # quel CLI manque ou est déconnecté
pablo project:new       # ajouter un projet ; ou déposer un YAML dans ~/.pablo/projects/

Vous avez besoin de PHP 8.4+ et des CLIs (gh, acli, linear, opencode) chacun déjà authentifié. Puis pablo task:start <issue-url> sur quelque chose de petit, /pablo-commit-and-pr, et arrêtez d'y penser. Si vous préférez un dashboard web au CLI, pablo web le sert sur le port 8321.

La 1.8 casse un peu ce rythme : 81 commits et 33 pull requests depuis la 1.7.0 de début août, et presque aucun n'ajoute de helper. Le travail est parti dans les recoins de Castor que vous ne regardez jamais : comment il arrive sur votre machine, comment il se met à jour, et ce qui prouve que le binaire que vous lancez est bien celui que notre CI a construit. Ah, et il tourne sous Windows maintenant 🪟.

Ce que vous avez peut-être raté depuis la 1.0.0

Sept versions mineures sont passées depuis l'article sur la 1.0, et certaines méritent mieux qu'une ligne dans le changelog. Au cas où vous en auriez sauté quelques-unes :

• PHP 8.4 est le minimum depuis la 1.6, et les binaires statiques embarquent PHP 8.5 depuis la 1.3. Si vous êtes coincés en 8.2 ou 8.3, Castor vous le dit et vous oriente vers le binaire statique ;
• #[AsArgsAfterOptionEnd] (1.2) donne à une tâche tout ce qui est tapé après --, tel quel. Pratique pour un castor phpunit -- --filter foobar qui transmet le reste à une autre CLI ;
• Le contexte a appris deux choses en 1.4 : input, pour alimenter le stdin d'un process (un mot de passe, plutôt que de le mettre sur la ligne de commande), et supportsInteraction(), pour savoir si vous êtes dans un TTY ou dans une CI avant d'appeler toInteractive() ;
• Un fichier .castor.context à la racine du projet définit le contexte par défaut, derrière --context et CASTOR_CONTEXT (1.6). Commitez-le, ou gitignorez-le pour un défaut personnel ;
• L'autocomplétion des chemins est devenue plus maligne : #[AsPathArgument] et #[AsPathOption] acceptent un directory et un filter (1.4) ;
• dispatch() et event_dispatcher() (1.7) laissent vos tâches dispatcher leurs propres événements, en plus de ceux que Castor émet déjà ;
• Le repack n'a plus besoin de jolicode/castor dans votre composer.json (1.3), et --castor-file pointe Castor vers un fichier racine qui ne s'appelle pas castor.php (1.1) ;
• Plus petits : terminal() pour la taille du terminal, slug() pour slugifier une chaîne, un lien vers la définition de la tâche dans castor help, et un en-tête silencieux quand Castor tourne dans un agent IA (moins de tokens gachés !).

Le changelog contient le reste. Passons à la 1.8.

Castor sous Windows

Castor fournit un phar Windows depuis les premières releases. Mais un phar a besoin de PHP, et « installer PHP sous Windows » n'est pas aussi fluide que sur les autres plateformes. Les binaires statiques, ceux qui embarquent PHP, n'existaient que pour Linux et macOS.

La 1.8 ajoute castor.windows-amd64.exe à chaque release : un fichier, PHP 8.5 dedans, rien à installer. Déposez-le dans un dossier de votre PATH et c'est terminé :

curl.exe "https://github.com/jolicode/castor/releases/latest/download/castor.windows-amd64.exe" -Lso C:\<un dossier de votre PATH>\castor.exe

Si vous distribuez votre propre CLI construite sur Castor (repack, puis compile), castor:compile a gagné une option --os=windows : vos tâches peuvent devenir un exécutable Windows elles aussi.

La première tentative pour supporter les binaires Windows remonte à octobre 2025, juste après la 1.0, et il a fallu quelques impasses avant d'aboutir à une solution fonctionnelle. Nous construisons les binaires statiques avec static-php-cli, un super outil sous Linux et macOS, mais moins évident sous Windows. Dans le désordre : le runner windows-latest embarque un Visual Studio que static-php-cli ne reconnaît pas (il veut le 2019 ou le 2022), le tar de git bash réécrit les chemins Windows dans votre dos, et MSVC abandonne sur les chemins de sources de plus de 260 caractères. Chacun de ces soucis se corrige en cinq minutes. Chacun coûte aussi un run de CI complet pour être découvert 😅. Si vous aimez ce genre d'archéologie, toute l'histoire est dans la pull request.

Installer et mettre à jour Castor

castor self-update

Jusqu'ici, mettre à jour Castor voulait dire relancer l'installeur, ou aller chercher le nouveau phar à la main sur la page des releases. Castor se met maintenant à jour tout seul, comme le font Composer et PHPStan :

castor self-update

Il retrouve comment il a été installé, télécharge le phar ou le binaire statique qui correspond à votre plateforme, et se remplace lui-même. La version précédente est conservée à côté : un --rollback la remet en place si la nouvelle se comporte mal. Vous avez installé Castor globalement avec Composer ? La commande lance composer global update pour vous.

Castor vous disait « une nouvelle version est disponible » depuis deux ans. Il peut enfin y faire quelque chose.

Snapshots

Chaque push sur main publie maintenant une pre-release snapshot. C'est le chemin le plus court pour essayer un correctif avant sa sortie :

castor self-update --snapshot
# ou, en partant de zéro
curl "https://castor.jolicode.com/install" | bash -s -- --version=snapshot

Un snapshot affiche une version du type v1.7.0-14-g4531440 : la dernière release, le nombre de commits depuis, et le commit à partir duquel il a été construit. castor self-update sans l'option vous ramène sur la dernière stable.

Égoïstement, c'est aussi pour nous : « tu peux essayer le snapshot ? » se demande bien plus facilement dans une issue que « tu peux cloner le dépôt et construire le phar ? ».

Des binaires vérifiables

Un task runner tourne sur votre laptop et dans votre CI, et pour certains d'entre vous sur des serveurs de production. Un task runner qui se met à jour tout seul télécharge du code et l'exécute. Ça mérite mieux qu'un curl | bash et un acte de foi.

Chaque phar et chaque binaire statique est maintenant publié avec une attestation d'artefact GitHub : une déclaration signée que ce fichier précis a été construit par le workflow GitHub Actions de Castor, à partir de ce commit. Chaque release contient aussi un fichier SHA256SUMS, attesté lui aussi.

Ensuite, tout ce qui télécharge Castor les vérifie :

• l'installeur et self-update comparent le checksum du binaire avec SHA256SUMS ;
• si la CLI GitHub (2.49 ou plus) est installée et connectée, les deux lancent en plus gh attestation verify dessus ;
• castor:repack refuse un phar Castor sans attestation (il existe un --allow-unattested pour les releases publiées avant les attestations) ;
• castor:compile vérifie le checksum de l'archive static-php-cli qu'il télécharge.

Vous pouvez aussi le faire à la main, sur n'importe quel fichier d'une release :

gh attestation verify castor.linux-amd64 --repo jolicode/castor

Dans vos tâches

Des helpers plus sûrs

Tant que nous étions dans un mood sécurité, nous sommes repassé sur les helpers avec une seule question : et si cette valeur venait d'une saisie utilisateur ? Une poignée de comportements ont changé. Aucun ne devrait casser une tâche existante, et ils sont tous dans le changelog, mais quelques-uns valent le coup d'être mis en avant :

• http_download() ne garde que le dernier segment du nom de fichier envoyé par le serveur : un téléchargement atterrit toujours dans le dossier de votre projet, quoi qu'en dise le serveur ;
• ssh_run() échappe le chemin distant, et refuse un hôte, un utilisateur ou un chemin de clé contenant un métacaractère shell ;
• zip() avec un mot de passe préfère l'extension PHP zip au binaire zip : le binaire prend le mot de passe sur sa ligne de commande, lisible par tous les utilisateurs de la machine pendant la création de l'archive. zip_binary() le fait toujours, et prévient désormais ;
• run_php() passe son script au process enfant en argument, au lieu d'une variable d'environnement que n'importe quel process Castor aurait ramassée sans se poser de question ;
• le dossier de cache est créé en 0700, respecte XDG_CACHE_HOME, et le binaire du watcher derrière watch() y est extrait plutôt que dans un chemin fixe de /tmp partagé avec tous les utilisateurs de la machine ;
• encrypt_with_password() dérive sa clé avec les limites « moderate » de libsodium (Argon2id, 3 passes, 256 Mio) au lieu des « interactive ». Ce qui a été chiffré par un Castor plus ancien se déchiffre toujours. Ce qui est chiffré par la 1.8 demande la 1.8 ou plus.

Intercepter les signaux

Retour au quotidien. Un classique : une tâche démarre un serveur, et vous aimeriez que CTRL+C arrête le serveur, pas la tâche. Jusqu'ici, le SIGINT arrêtait Castor lui-même, et ce que vous aviez prévu après le serveur ne s'exécutait jamais.

Le contexte a gagné withTrappedSignals(), qui transmet le signal au process en cours à la place :

use Castor\Attribute\AsTask;

use function Castor\context;
use function Castor\run;

#[AsTask()]
function serve(): void
{
    // A CTRL+C stops the server, but not the task
    run('./my-server', context: context()->withTrappedSignals()->withAllowFailure());

    run('echo "the server has been stopped"');
}

Sans argument, il intercepte SIGINT et SIGTERM. Passez votre propre liste si besoin, withTrappedSignals([\SIGINT, \SIGQUIT]) par exemple. Les détails sont dans la documentation des signaux.

Monter un paquet distant

Castor a deux façons d'amener des tâches externes dans un projet. import() ajoute des fonctions et des tâches dans votre application. mount() branche un sous-projet entier, avec son propre préfixe de namespace et son propre dossier de travail. Seul import() connaissait les paquets Composer, mount() ne fonctionnait qu'avec des dossiers locaux. Ils partagent maintenant la même résolution :

use function Castor\mount;

mount('composer://vendor/package', 'project:package');

Les tâches du paquet apparaissent sous project:package: et s'exécutent depuis le dossier du paquet installé, exactement comme un mount local. C'est le montage que nous voulions pour une boîte à outils qu'une équipe maintient dans son propre dépôt (un kit de déploiement, une stack Docker) et monte dans chaque projet.

Un correctif est tombé de ce chantier : un import() distant ne change plus le dossier de travail des tâches qu'il définit. Il n'aurait jamais dû. Seul un mount() explicite fait ça.

Une dépréciation pour préparer la 2.0

Celle-ci mérite une minute, parce que vous dépendez peut-être de l'ancien comportement sans le savoir.

Aujourd'hui, seul run() s'exécute dans le dossier de travail du contexte. Tout le reste, fs(), finder() et les fonctions PHP natives comme mkdir() ou file_get_contents(), résout les chemins relatifs depuis l'endroit où vous avez tapé castor. Lancez castor build depuis un sous-dossier : file_get_contents('composer.json') cherche au mauvais endroit alors que run('cat composer.json') non. Pas terrible.

Castor 2.0 changera son propre dossier courant pour le dossier de travail du contexte : un chemin relatif voudra dire la même chose partout. Il suit aussi les blocs with(workingDirectory: ...), et restaure le dossier précédent quand ils se terminent.

Vous pouvez l'activer dès aujourd'hui avec une ligne en haut de votre castor.php :

defined('CASTOR_USE_CHDIR') || define('CASTOR_USE_CHDIR', true);

Ledefined() n'est pas décoratif : un projet monté ou un paquet importé peut définir la constante lui aussi, et un second define() nu lève une erreur.

Ne pas définir la constante est déprécié en 1.8, et le nouveau comportement devient le défaut en 2.0. Pour garder l'ancien comportement encore un moment sans la dépréciation, définissez-la à false.

Le mot de la fin

Si vous ne retenez qu'une chose de la 1.8 : le binaire que vous lancez est le nôtre, preuve à l'appui, et il se met à jour tout seul. Vos collègues sous Windows ont le même outil que tout le monde. En bonus, CTRL+C fait enfin ce que vous attendez devant un serveur.

La mise à jour tient désormais en une commande :

castor self-update

La liste complète des changements est dans le changelog. Et si l'histoire de static-php-cli vous a donné envie de savoir comment sont construits les binaires Linux, macOS et Windows, dites-le-nous : ça pourrait être le prochain article 🦫

Face à une actualité internationale qui nous pousse à réduire nos dépendances technologiques vis-à-vis des acteurs américains (infrastructure comme IA), on peut construire un agent IA pleinement opérationnel 100 % hébergé et exécuté en Europe. Notre assistant de conférence tourne sur une stack open source européenne, du runtime jusqu’à l’application, fait son inférence en France avec Mistral, et ne stocke que le strict nécessaire côté données utilisateur·ices. La souveraineté, ici, c’est le résultat d’une série de choix d’architecture pris dès le développement. On détaille ces choix dans cet article. Vous pouvez retrouver la partie 1 et la partie 2 de ce retour d’expérience sur notre blog.

Contexte et enjeux

Le choix devenu commun est de passer par AWS, GCP, Azure et OpenAI ou Anthropic quand il s’agit d’un projet basé sur l’IA et qui nécessite un hébergement. Toutes ces entreprises étant soumises au cadre juridique des États-Unis, les données de l’application et de ses utilisateurs deviennent accessibles. Pour beaucoup d’organisations européennes, issues du secteur public, santé, ou simplement soumises au RGPD, ça pose des questions de conformité et de dépendance stratégique.

Inférence locale avec Mistral

Le modèle qui fait tourner l’assistant vient de Mistral AI, une entreprise française, et l’inférence a lieu sur le territoire de l’UE. Côté intégration, ça se résume à déclarer la plateforme et utiliser une clé d’API dans l’application.

Toutes les données (requêtes des utilisateur·ices, contexte de l’événement, appels d’outils générés par le modèle) restent dans la juridiction européenne. Pour un responsable de traitement au sens du RGPD, ça simplifie beaucoup les choses : plus besoin d’analyse d’impact sur les transferts hors UE (AIPD), plus de clauses contractuelles types pour les flux d’inférence, plus d’incertitudes sur où le traitement a lieu.

Réversibilité et interopérabilité

Une souveraineté qui enfermerait l’application chez un seul prestataire ne ferait que déplacer le problème de dépendance. On a donc pensé l’architecture pour garantir la réversibilité à chaque niveau.

• Le modèle est interchangeable : Symfony AI abstrait le fournisseur d’inférence derrière une interface générique. Passer de Mistral à un autre fournisseur, ou à un modèle à poids ouverts auto-hébergé sur une infrastructure GPU dédiée, c’est une simple modification de configuration et non pas une réécriture du code métier. Le prompt, les outils et l’interface restent inchangés.
• Le client est interchangeable aussi : comme le produit s’articule autour d’un serveur MCP (voir la Partie 1), les échanges passent par un protocole ouvert, sans SDK propriétaire entre l’agent et le serveur. L’interface de chat sous Symfony pourrait être remplacée par n’importe quel autre agent compatible MCP sans toucher au code serveur.

Une stack technologique européenne et open source

Le tableau ci-dessous récapitule la stack complète. Il n’y a aucune dépendance logicielle ni infrastructure hors d’Europe :

Chaque composant open source est auditable et peut être auto-hébergé intégralement, sans communication cachée vers des tiers hors Europe.

Minimisation des données dès la conception

La conformité RGPD est plus simple à gérer quand on ne collecte que l’essentiel dès le départ.

• Identités éphémères : à l’authentification via GitHub, le jeton est validé auprès de l’API tierce pour instancier un utilisateur en mémoire, le temps de la requête. Cette identité n’est jamais persistée en base, seul l’identifiant numérique stable de GitHub est conservé, pour l’associer aux votes et commentaires.
• Données minimales stockées : un vote ou un commentaire, c’est l’identifiant GitHub, le pseudo public, le contenu et un horodatage. Rien d’autre.
• Pas de stockage d’IP : le rate limiting s’appuie sur l’identifiant GitHub de l’utilisateur·ice connecté·e, pas sur l’adresse réseau. Les outils d’écriture sont protégés sans qu’on ait besoin de journaliser la moindre IP.
• Masquage des données sensibles : la couche temps réel peut faire transiter des jetons d’autorisation dans les paramètres de requête, donc le serveur filtre explicitement ces variables avant qu’elles atterrissent dans les logs.

Cohérence entre résidence et sécurité des données

Héberger les données en Europe ne sert à rien si l’application a des failles de sécurité par ailleurs. La Partie 2 détaille les mesures concrètes : validation systématique des tokens GitHub, rate limiting par utilisateur·ice, Content-Security-Policy à base de nonce, et commentaires marqués comme données non vérifiées pour limiter les risques d’injection de prompt indirecte.

Conclusion

On perçoit parfois la souveraineté comme une contrainte qui réduit les performances ou complique le développement. Ce projet montre le contraire : une stack open source européenne combinée à l’inférence Mistral a suffi pour livrer un agent fonctionnel (streaming, appels d’outils, persistance) sans les barrières réglementaires liées aux transferts de données.

Cinq principes ont guidé la démarche :

1. Une inférence localisée, isolée derrière une couche d’abstraction logicielle.
2. Un protocole ouvert, pour éviter le verrouillage technologique.
3. Des briques open source auditables (FrankenPHP, Symfony, API Platform, Mercure).
4. Un hébergement basé en Europe.
5. La minimisation des données intégrée directement dans le code.

On se retrouve la semaine prochaine ?

L’assistant est en ligne dès maintenant, avant même l’ouverture des portes : de quoi préparer votre venue, repérer les talks à ne pas manquer et construire votre agenda à l’avance. Rendez-vous les 17 et 18 septembre à EuraTechnologies pour la sixième édition de l’API Platform Conference !

Cet article, Souveraineté : de l’IA agentique qui garde vos données en Europe, est paru en premier sur Les-Tilleuls.coop.

La première partie de ce retour d’expérience expliquait le choix d’architecture : construire un serveur MCP plutôt qu’un chatbot isolé, pour que le service soit accessible à n’importe quel agent IA, l’interface de chat devenant simplement son premier client. Cet article rentre dans le détail technique de ce service et du client qui s’y connecte. La partie 3 évoque les outils souverains qu’on a utilisés.

La décision d’architecture la plus structurante a été de s’appuyer sur l’écosystème existant plutôt que d’écrire du code de transport MCP à la main. Pas de dispatcher JSON-RPC, pas de sérialiseur de schéma, pas de routeur d’outils développés maison : API Platform expose maintenant les ressources d’API comme des outils MCP via un seul attribut. La couche State, qui alimente déjà le REST et le GraphQL, fait le travail de handler d’outils sans qu’on ait rien à changer. Le reste de la stack : FrankenPHP, Mercure, Symfony AI et Mistral s’articule autour de cette brique centrale. On détaille chaque composant dans les sections qui suivent.

La forme du système

L’interface de chat n’est qu’un client parmi d’autres. Claude Desktop, un assistant d’IDE ou un script maison, du moment qu’ils parlent MCP, ils se connectent au même serveur et accèdent aux mêmes 21 outils. Cette interopérabilité découle directement des choix d’architecture qu’on a faits au départ.

Un attribut transforme une ressource en outil

Le support MCP d’API Platform permet de déclarer des outils directement dans les métadonnées de la ressource. Voici la ressource Feedback, qui gère les votes et les commentaires, avec deux de ses outils :

#[ApiResource(
    operations: [],
    mcp: [
        'talk-feedback' => new McpTool(
            name: 'talk-feedback',
            description: 'Read the community feedback for an API Platform Conference 2026 talk: number of votes, average rating and the comments (with author). Public — no authentication needed.',
            input: FeedbackInput::class,
            processor: TalkFeedbackProcessor::class,
            structuredContent: true,
        ),
        'vote-talk' => new McpTool(
            name: 'vote-talk',
            description: 'Rate an API Platform Conference 2026 talk (1–5). Requires a GitHub access token (sent as a Bearer token); one vote per talk per user — voting again updates your rating. Returns the updated feedback.',
            input: VoteInput::class,
            processor: VoteTalkProcessor::class,
            structuredContent: true,
        ),
        'comment-talk' => new McpTool(
            name: 'comment-talk',
            description: 'Post a comment on an API Platform Conference 2026 talk. Requires a GitHub access token (sent as a Bearer token); the comment is attributed to your GitHub login. Returns the updated feedback.',
            input: CommentInput::class,
            processor: CommentTalkProcessor::class,
            structuredContent: true,
        ),
    ],
)]
final class Feedback {/* properties */}

final readonly class VoteTalkProcessor implements ProcessorInterface
{
public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): Feedback
{
    /* Security & validation */

    $talk = $this->conference->findTalk($data->slug)
        ?? throw new \RuntimeException(\sprintf('Unknown talk "%s".', $data->slug));

    $existing = $this->em->getRepository(Vote::class)->findOneBy([
        'talkSlug' => $talk->slug,
        'authorId' => $user->githubId,
    ]);

    /* Upsert logic: adding or replacing existing vote for user */

    return $this->feedback->summary($talk->slug, $talk->title, $message);
}
}

{$SERVER_NAME:localhost} {
    root /app/public
    mercure { /* Configuration des jetons JWT et accès anonymes */ }
    php_server {
        worker {
            file ./public/index.php
        }
    }
}

final class CspNonceProvider implements ResetInterface
{
    private ?string $nonce = null;

    public function getNonce(): string
    {
        return $this->nonce ??= bin2hex(random_bytes(16));
    }

    public function reset(): void
    {
        $this->nonce = null;
    }
}

// Prepare context window
$messageBag = $this->buildMessageBag();
$execution = $this->conference->call($messageBag, ['stream' => true]);

foreach ($execution->asTextStream() as $delta) {
    $text = $delta->getText();

    if ('' === $text) {
        continue;
    }

    $answer .= $text;
// Publishes longest valid-UTF-8 prefix & leaves the incomplete tail for the next call
    $this->bufferAndPublish($topic, $byteBuffer, $text);
}
// Flush whatever was buffered
$this->flush($topic, $byteBuffer);

ai:
  platform:
    mistral:
      api_key: '%env(MISTRAL_API_KEY)%'
  agent:
    conference:
      platform: 'ai.platform.mistral'
      model:
        name: '%env(AI_MODEL)%'
        options:
          temperature: '%env(AI_TEMPERATURE)%'
      prompt:
        text: |
          You are the assistant for the API Platform Conference 2026
          (17–18 September 2026, EuraTechnologies, Lille — organized by Les-Tilleuls.coop).
          You help attendees explore the agenda, talks, speakers, schedule, partners and practical information.
          Rules:

Cet article, Transformer une API en boîte à outils pour agents : l’architecture de notre assistant de conférence, est paru en premier sur Les-Tilleuls.coop.

Trouver le talk qui correspond à vos objectifs, savoir qui va briller sur la scène FrankenPHP, caler votre agenda… La billetterie de l’API Platform Conference 2026 ferme dans quelques jours, et on a voulu vous accompagner jusqu’au bout avec un nouvel outil : un assistant IA avec qui échanger directement sur la conférence. On vous raconte ce projet en trois articles : celui-ci pose le contexte général, le second détaille l’architecture, et le troisième revient sur notre choix d’outils souverains. Prêt·es à tester ?

Les prémices du projet

Chaque année, l’API Platform Conference propose à Lille deux jours de programme chargé : des dizaines de conférences sur plusieurs tracks, des intervenant·es venu·es du monde entier, des ateliers, et toute la logistique qui va avec un événement en pleine croissance. Et chaque année, les mêmes questions reviennent côté participant·es : qu’est-ce qui se passe en ce moment, c’est quoi la prochaine conférence en salle 2, qui parle de tel sujet, où sont les stands des partenaires… On a voulu y répondre avec un assistant conversationnel.

La façon évidente de faire, c’est un chatbot classique : une interface, un LLM, un prompt, un accès aux données câblé derrière. C’est d’ailleurs par là qu’on a commencé. Mais en cours de route, une question de conception a fait bifurquer tout le projet, et la réponse s’est révélée beaucoup plus réutilisable qu’une simple fenêtre de chat. C’est ce recadrage qu’on raconte dans cet article, parce que c’est la leçon la plus transposable qu’on en a tirée, et elle ne doit presque rien à la technique.

L’idée de départ vient de techready.live, qui a montré tout ce qu’un bon compagnon d’événement peut apporter aux participant·es. Notre question a été : à quoi ça ressemble, cette expérience, à l’heure des agents IA ?

Une question qui a changé la conception

La question qu’on s’est posée : quand l’assistant doit savoir « quelle est la prochaine conférence en salle 2 », où vit cette connaissance ?

Si la réponse est « dans le chatbot », alors le chatbot, c’est le produit. Et toute autre façon d’accéder à la même info (Claude Desktop, un assistant d’IDE comme Cursor, le bot Slack d’une équipe, le script perso d’un·e collègue) devrait être reconstruite de zéro, avec sa propre copie de l’accès aux données, des règles métier et du prompt. La fenêtre de chat deviendrait à la fois l’interface et le plafond de verre.

On a donc inversé la logique. On a d’abord construit la connaissance de la conférence et les actions possibles pour un·e participant·e comme un service autonome, et traité l’interface de chat comme son premier client et pas comme le produit lui-même. Ce service s’appuie sur le Model Context Protocol (MCP), le standard ouvert pour exposer des outils à des agents IA. Le chat en est un consommateur parmi d’autres ; n’importe quel agent compatible MCP peut en être un autre.

Des capacités, pas des endpoints

Concevoir un serveur MCP, ça change subtilement la manière de penser par rapport à une API REST classique. Au lieu de raisonner en ressources et en endpoints, on raisonne en capacités et en verbes les actions concrètes qu’un·e utilisateur·ice fait vraiment.

Notre serveur s’organise autour des besoins réels d’un·e participant·e pendant l’événement :

• Explorer le programme : lister et rechercher des conférences, récupérer les détails d’une session ou d’un·e intervenant·e, parcourir l’historique d’un·e speaker, lister les catégories et les partenaires, lire les infos générales de l’événement.
• Se repérer dans le temps : savoir ce qui se passe maintenant et ce qui vient ensuite.
• Participer : noter une conférence, laisser un commentaire, lire les retours de la communauté.
• Planifier : ajouter une conférence à son agenda personnel, la retirer, le consulter.

Le projet compte vingt outils au total. Ce qui compte, c’est qu’ils portent des noms d’actions humaines, pas des noms de tables SQL. « Les prochaines conférences », c’est une capacité que n’importe quel·le participant·e comprend ; une query string avec un offset et une limite, c’est de la tuyauterie. Et quand celui qui consomme l’API est un modèle de langage qui doit décider quel outil appeler, c’est ce cadrage sémantique qui l’aide à choisir le bon outil et à lui passer les bons arguments.

La description de l’outil est l’interface

Le plus surprenant dans ce développement, c’est la documentation. Sur une API classique, la doc de référence s’adresse aux développeur·euses et reste, dans les faits, optionnelle : le code marche, que la doc soit bonne ou non. API Platform fait déjà mieux avec une doc OpenAPI générée automatiquement à partir du code, toujours à jour. Mais sur un serveur MCP, la description de chaque outil est lue par le modèle à chaque décision qu’il prend. Ce n’est plus de la documentation sur l’interface, c’est l’interface. Elle décide si l’agent appelle l’outil, et s’il l’appelle correctement.

Une description du genre « Voter pour une conférence » n’apprend quasiment rien au modèle. Voici celle qu’on a fini par écrire pour l’outil de notation :

Rate an API Platform Conference 2026 talk (1–5). Requires a GitHub access token (sent as a Bearer token); one vote per talk per user — voting again updates your rating. Returns the updated feedback.

En trois phrases, le modèle sait quelle plage de notes est valide, qu’une authentification est requise, que revoter met à jour la note au lieu de la dupliquer, et à quoi ressemble la réponse. On a passé plus de temps à écrire et réécrire ces descriptions que sur n’importe quel handler. Sur un projet MCP, ce sont elles qui font la différence entre un projet qui marche et un qui ne marche pas, ça vaut le coup de les traiter comme du vrai prompt engineering.

L’authentification comme frontière produit

L’essentiel du serveur est accessible sans création de compte : lire le programme ne demande rien. Écrire, en revanche : noter une conférence, laisser un commentaire ou se construire un agenda  demande une connexion GitHub. C’est un choix assumé, pas un détail technique : il définit qui a le droit de modifier les données et garde une trace des contributions.

Cette règle est portée par l’outil lui-même, pas par un client en particulier. Un agent qui essaie de voter sans token reçoit une réponse en langage clair lui expliquant qu’une connexion est nécessaire. Notre interface de chat traduit ça par un bouton « Se connecter avec GitHub » ; un autre client le présenterait autrement. Mais la règle vit à un seul endroit, sur le serveur, donc chaque client l’applique sans avoir à la réécrire.

Bring your own agent

Quand le produit est un service et non une appli figée, la distribution change de nature : ce n’est plus un app store, mais un petit bout de configuration. Un·e développeur·euse ajoute quelques lignes à son client IA préféré, et son assistant sait répondre aux questions sur la conférence et enregistrer ses votes. Pareil pour un assistant d’IDE ou un script écrit pour un besoin précis : chaque client accède aux mêmes vingt outils et au même comportement, sans qu’on ait à redévelopper quoi que ce soit de notre côté.

Pour que ce soit concret, on publie une page statique avec des instructions d’installation copier-coller pour les clients les plus courants. Le « bring your own agent », ça ne marche que si ça prend deux minutes à mettre en place.

Notre interface de chat garde toute son utilité : c’est le point d’entrée que la plupart des participant·es utiliseront, et on détaille sa construction dans la Partie 2. Mais ce n’est qu’une porte d’entrée parmi d’autres, pas là où se concentre la valeur du projet.

Retours d’expérience et bonnes pratiques

Quelques principes qui ont tenu la route, et qu’on appliquerait à n’importe quel projet MCP :

• Modéliser le domaine par des verbes. Quand les capacités portent le nom des actions de l’utilisateur·ice, les frontières entre outils se dessinent toutes seules, et le modèle choisit plus fiablement quel outil appeler.
• Traiter les descriptions comme de l’UX. Ça prend du temps à écrire et à tester contre le comportement réel du modèle.
• Préférer la sortie structurée à la prose formatée. Du contenu typé laisse chaque client (bulle de chat, panneau d’IDE, interface vocale) libre de le présenter comme il veut.
• Mettre la logique de contrôle côté serveur. Un client peut oublier l’authentification, les rate limits ou la validation ; le serveur, lui, doit les appliquer systématiquement.
• Voir l’interface comme un client, pas comme le produit. Ça reste utile d’en soigner une, mais ça ne doit pas devenir le seul moyen d’interagir.

Au final, ce qui compte dans ce projet, ce n’est pas tellement la fenêtre de chat qu’on a construite, mais le socle technique sur lequel n’importe quel futur client IA peut venir s’appuyer..

La suite du cheminement

Dans la Partie 2, on rentre dans le détail technique : comment API Platform transforme une ressource en outil MCP avec un seul attribut, comment le mode worker de FrankenPHP garde le serveur actif, et comment les réponses sont streamées jusqu’au navigateur avec Mercure. La Partie 3 montre que toute cette infrastructure peut tourner sur une stack entièrement européenne et open source, inférence comprise. 

Cet article, Comment nous avons créé un assistant IA pour l’API Platform Conference 2026, est paru en premier sur Les-Tilleuls.coop.

Webpack Encore arrive en fin de vie, et Symfony a publié son successeur officiel pour Vite et Rsbuild : Reprise. Le bundle était encore marqué expérimental quand nous avons migré (en 0.7, puis 0.8), mais c'était clairement la direction que prend le framework. Nous avons donc sauté le pas. Et depuis, la 1.0 est sortie, apportant ainsi la même promesse de rétrocompatibilité que Symfony.

Je vais vous raconter dans cet article comment s'est passée cette migration. Nous verrons d'abord ce que fait Reprise et ce qu'implique la migration mécanique, puis les vrais sujets qui nous ont occupés : le contrat implicite que notre base de code avait avec Webpack, une collection de « webpack-ismes » qui ne se révèlent qu'au runtime, et enfin la mise en place du hot reload dans notre stack Docker. Pour vous donner envie de lire jusqu'au bout : le build est passé de 75-100 secondes à une quinzaine de secondes, et nous avons supprimé 583 packages npm au passage 🎉.

Vous avez dit Reprise ?

Contrairement à Encore qui réimplémentait toute la chaîne de build par-dessus Webpack, Reprise ne fournit que la glue Symfony : la génération d'entrypoints.json et de manifest.json, les fonctions Twig reprise_entry_*, et le support du dev server. Tout le reste (Sass, TypeScript, React, code splitting, minification), c'est Vite qui le fait nativement.

La migration mécanique est vite pliée :

composer remove symfony/webpack-encore-bundle
composer require symfony/reprise
yarn add --dev vite @symfony/reprise

Un vite.config.ts par build, encore_entry_script_tags qui devient reprise_entry_script_tags dans les templates, et c'est à peu près tout. Sur le papier, quelques heures de travail.

Le contraste entre les deux configs illustre bien la philosophie. Avant, nous avions 200 lignes d'API chaînée Encore, où chaque capacité du bundler doit être déclarée explicitement :

// webpack.config.js (extrait)
Encore.setOutputPath('web/build/')
    .setPublicPath('/build')
    .addEntry('js/app', './assets/scripts/main.tsx')
    .addStyleEntry('css/app', './assets/styles/main.css')
    // … 6 autres entrées
    .disableSingleRuntimeChunk()
    .enablePostCssLoader()
    .enableReactPreset()
    .enableTypeScriptLoader()
    .autoProvideVariables({ 'bazinga-translator': 'Translator' })
    .addPlugin(new ESLintPlugin())
    .addPlugin(new StylelintPlugin({ /* … */ }))
    .copyFiles([{ from: './assets/images', to: 'images/[path][name].[ext]?[hash:8]' }])
    .configureFilenames({ js: '[name].js?[chunkhash]', /* … */ });

Après ? Une cinquantaine de lignes où Vite fait le gros du travail nativement. TypeScript et React n'ont plus besoin de loader, et les plugins ESLint/Stylelint sont remplacés par les scripts lint déjà présents dans la CI :

// vite.config.ts (extrait)
export default defineConfig(({ mode }) => ({
    build: {
        sourcemap: mode !== 'production',
        rollupOptions: {
            input: {
                'js/app': './assets/scripts/main.tsx',
                'css/app': './assets/styles/main.css',
                // … 6 autres entrées
            },
        },
    },
    plugins: [
        react(),
        tailwindcss(),
        symfony({ outputPath: 'web/build', publicPath: '/build/' }),
        copyStable([{ from: 'assets/images', to: 'images' }], '/build/', 'web/build'),
    ],
}));

Vous remarquez le copyStable sur la dernière ligne ? Il n'est pas fourni par Reprise, et c'est justement le sujet du chapitre suivant. Car comme nous allons le voir, le vrai sujet d'une migration de bundler n'est pas la config du bundler en elle-même.

Le contrat implicite avec Webpack

Vite hashe les noms de fichiers par défaut, c'est son modèle de cache-busting : app.js devient app-B7fAYn0O.js, et le manifest.json fait la correspondance. Sauf que notre projet avait un contrat exactement inverse, invisible tant qu'on ne le cherche pas :

• plus de 300 templates référencent des images en dur, façon asset('/build/images/logo.svg'), sans jamais passer par un manifest ;
• près de 250 templates utilisent un filtre Twig maison |inline qui lit les SVG directement sur le disque pour les inliner dans le HTML ;
• le cache-busting est global, par query string, à partir d'un fichier REVISION produit au déploiement.

Autrement dit, les chemins physiques des fichiers copiés doivent rester stables, et ce depuis des années. Réécrire 300 templates n'était évidemment pas envisageable. De plus, les emails envoyés par l'application utilisent également certains de ces assets (notamment les fonts), ils doivent donc rester disponibles aux mêmes urls.

Reprise proposait bien (en 0.7) une option copy pour remplacer le copyFiles() d'Encore, mais elle hashait systématiquement les noms de fichiers copiés, sans opt-out. Encore laissait choisir son pattern (images/[path][name].[ext]?[hash:8] chez nous : chemin stable sur disque, hash en query string). Notre réponse initiale a tenu en un plugin Vite d'une quarantaine de lignes, qui reproduisait le contrat d'Encore :

// vite-plugin-copy-stable.ts (extrait)
generateBundle(_options, bundle) {
    for (const { file, logicalName } of files(entries)) {
        const source = readFileSync(file);
        const hash = createHash('sha256').update(source).digest('hex').slice(0, 8);
        // Le fichier garde son chemin logique…
        this.emitFile({ type: 'asset', fileName: logicalName, source });
        // … et le hash part dans la valeur du manifest, en query string
        manifestEntries[keyPrefix + logicalName] = `${publicPath}${logicalName}?${hash}`;
    }
    // puis fusion de manifestEntries dans le manifest.json émis par Reprise
}

Résultat : zéro template modifié (hors les 4 layouts de base), le JS et le CSS profitent du hashing natif de Vite via entrypoints.json, et tout le reste garde ses chemins stables.

Ce besoin nous a semblé suffisamment universel pour le proposer upstream : symfony/reprise#81 ajoute une option hash: false par entrée copy, qui reproduit exactement ce contrat. Elle a été mergée et publiée dans Reprise 0.8 quelques jours plus tard : nos quarante lignes de plugin ont disparu au profit d'une ligne de config, avec des arborescences et des manifests strictement identiques.

Les webpack-ismes qui ne se voient qu'au runtime

Une fois le build vert, nous pensions être tirés d'affaires. Mais la CI nous attendait au tournant, avec de nombreux scénarios Behat en échec. Tous les problèmes que je vais lister ici ont le même point commun : le build passe, le typecheck passe, et pourtant le site ne fonctionne plus au runtime.

global n'existe pas

global.Translator = Translator;

Webpack aliasse silencieusement global vers window. Vite, non :

Uncaught ReferenceError: global is not defined

L'erreur survient au top-level du module, donc c'est tout le bundle qui meurt : plus une seule ligne de JS ne s'exécute sur le site. Le plus vicieux : @types/node étant installé, global est parfaitement typé et tsc ne bronche pas. Le fix est trivial (window.Translator = …), encore faut-il savoir que ces assignations existent.

Les require() dynamiques

<ReactSVG src={require(`../../../images/icons/${path}`)} />

Ce pattern repose sur les context modules de Webpack, qui embarquait tout le dossier icons/ pour résoudre l'expression au runtime. Vite ne les implémente pas :

Uncaught ReferenceError: require is not defined

L'exception éclate au premier rendu d'un composant avec icône, et React réagit en démontant tout l'arbre : pages de résultats intégralement vides, sans un message pour l'utilisateur. Nos icônes étant déjà copiées à chemins stables (voir plus haut), une URL directe a suffi : src={/build/images/icons/${path}}.

Les url() CSS qui ne suivent pas

Avec @tailwindcss/postcss, les @import CSS sont inlinés sans rebaser les chemins relatifs. Un url('../../fonts/brand-400.woff2') écrit dans un fichier importé se retrouve tel quel dans le CSS final, se résout depuis la racine et répond 404 : webfonts et images de fond ont disparues.

Le plugin officiel @tailwindcss/vite réécrit ces mêmes URLs vers l'asset émis ( url(/build/brand-400-Dm0XPNJo.woff2)) en plus d'être plus rapide. C'est l'intégration que Tailwind recommande quand on build avec Vite. Le rebasing côté PostCSS a bien été corrigé à plusieurs reprises upstream (voir l'issue #16636, fermée depuis), mais un fichier importé depuis notre propre code nous rejouait toujours le problème en 4.3.3. Je ne peux que vous recommander de ne plus passer par PostCSS si vous utilisez Tailwind v4 avec Vite.

Le fichier vendor en CommonJS

import Routing from '../../../vendor/friendsofsymfony/jsrouting-bundle/Resources/public/js/router.min.js';

Celui-là est retors : il fonctionne en build (le plugin commonjs de Rollup fait l'interop), mais crashe uniquement en dev :

The requested module '…/router.min.js' does not provide an export named 'default'

Vite ne prébundle que node_modules, et sert donc le fichier CJS de vendor/ tel quel à un navigateur qui attend un module ES. La solution est le package npm fos-router, qui est exactement le même que celui packagé dans le bundle Symfony. En prime, le package npm est en typescript : tsc a immédiatement débusqué une dizaine de window.location = url qui dormaient depuis des années (le module vendor étant any, tout ce qui en sortait échappait au typage).

Quand le site dépend d'un bug du bundler

Voici mon anecdote préférée de cette migration. Après le passage à Vite, un test de régression visuelle refusait obstinément de passer : sur une déclinaison du site, le logo s'affichait 60 % trop grand.

Nous avons tout vérifié : le fichier SVG copié, identique ; les règles CSS, identiques et dans le même ordre ; le HTML, identique. En dernier recours, le manifest Webpack de production, qui racontait une drôle d'histoire :

"build/images/logo-pro.svg": "/build/images/logo-pro.e42c1969.svg"

Un hash dans le nom de fichier, là où toutes les autres entrées copiées utilisaient une query string. Et le contenu de ce fichier hashé n'était pas le fichier demandé : c'était un autre SVG du même nom, situé dans un sous-dossier icons/, avec une classe CSS différente, donc une taille différente.

L'explication : les images émises par file-loader (dont tout le dossier icons/, embarqué par le require() dynamique vu plus haut) écrasaient les clés du manifest des fichiers copiés portant le même nom. Depuis des années, le site servait le mauvais fichier à cet endroit, et ce rendu accidentel était devenu la référence, jusque dans nos baselines de screenshots. Notre build Vite, plus propre, servait enfin le bon fichier… et cassait donc le test.

Nous avons audité les 31 collisions de noms du projet (une seule autre était visible) et pointé les templates vers le bon fichier, explicitement. Ce que je retiens de cette histoire, c'est qu'un bundler est avant tout un système de résolution : en changer révèle toutes les résolutions accidentelles dont votre site dépend sans que vous le sachiez.

Un pixel de différence

Toujours côté régressions visuelles : trois baselines ont bougé d'exactement 1 pixel après la migration. Un bouton centré, dont la largeur totale (icône dimensionnée en em + texte) tombe à un demi-pixel près différemment. En cause, le changement de minifieur CSS : cssnano (configuré avec calc: false précisément pour éviter ce genre d'arrondis) a laissé la place à esbuild.

0,01 % des pixels, invisible à l'œil, mais parfaitement reproductible. Le rendu de Vite est déterministe au pixel près d'un run à l'autre : nous avons comparé des captures à deux jours d'écart, zéro pixel de différence.

Corollaire qui vaut pour tous ceux qui font des tests de screenshots : ne régénérez jamais vos baselines sur le dev server. Le CSS non minifié y produit les mêmes écarts d'arrondis face au rendu buildé que compare votre CI, et vous chercherez longtemps pourquoi « ça passe en local ». Chez nous, la task de mise à jour des screenshots rebuild d'office avant de capturer.

Brancher le HMR dans la stack Docker

Le HMR (Hot Module Replacement ou remplacement de module à chaud) est le gain le plus visible de la migration pour les développeurs, et il mérite qu'on s'y attarde. Petite confession d'abord : avec Encore, notre « watch » se contentait d'écrire les fichiers sur le disque, et le vrai dev-server était pensé pour tourner dans Docker pour les PC sous Linux, sur la machine hôte (donc en dehors de Docker) pour les Macs (car ceux de l'époque souffraient trop). Avec Vite, nous voulions le HMR dans la stack, comme tout le reste, et pour tout le monde.

Les problèmes rencontrés

Nous avons eu trois problèmes à résoudre.

Atteindre le serveur depuis le navigateur. Nous avons d'abord sur-conçu la chose : route Traefik dédiée, TLS, service discovery. Puis nous avons retenu une solution bien plus simple, déjà adoptée sur un autre de nos projets : publier le port du conteneur sur l'hôte et servir en http://localhost:5173. Les navigateurs traitent localhost comme une origine sûre, donc pas de mixed content depuis une page HTTPS et zéro certificat à gérer.

Le cycle de vie. Notre premier montage lançait Vite dans un conteneur compose run éphémère. Mauvaise idée : un watch tué laisse un zombie qui squatte le port 5173 et continue d'écraser les fichiers en douce. Nous avons donc plutôt défini un service Compose dédié : up réutilise ou recrée toujours le même conteneur, ce qui rend le zombie impossible.

# docker-compose.dev.yml (extrait)
vite:
    image: "${PROJECT_NAME}-builder"
    command: bash -c "until [ -d node_modules/.bin ]; do sleep 2; done; yarn run ${VITE_SCRIPT:-dev}"
    ports:
        - "127.0.0.1:${PROJECT_VITE_PORT:-5173}:5173"

Le until node_modules n'est pas décoratif : au premier démarrage de la stack, Docker démarre le service avant que yarn install ne soit passé, et on ne veut pas d'un service en crash-loop.

Les pièges du conteneur. Deux classiques à connaître. Le watcher de Vite crawle par défaut tout le projet : avec un vendor/ de 100 000 fichiers, la limite inotify explose. Il faut donc l'exclure explicitement. Et méfiez-vous de vos patterns d'exclusion : notre **/var/**, pensé pour le cache Symfony, matchait /var/www, le dossier de travail du conteneur. Tout le projet était ignoré par le watcher, donc le HMR était inopérant : le serveur tourne, la page se charge, et rien ne se met à jour. Ancrez vos patterns au dossier du projet :

watch: {
    ignored: ['vendor', 'var', 'web'].map((dir) => path.resolve(__dirname, dir, '**')),
},

Dernier raffinement, la cohérence entre les modes : nos tasks de build stoppent le serveur de dev s'il tourne (sinon les pages repassent sur les assets buildés pendant qu'un serveur orphelin continue de tourner pour rien), et la task de watch le démarre. On ne peut ainsi pas se retrouver dans un état intermédiaire sans le savoir.

Et les worktrees ?

Avec l'IA devenant progressivement incontournable pour gagner en efficacité, nous travaillons de plus en plus avec des worktrees git, chacun avec sa stack Docker complète et isolée. C'est une feature native de notre template docker-starter : le nom de projet Compose est suffixé par le worktree, et tous les ports hôtes sont décalés automatiquement, ce qui permet d'avoir plusieurs stacks qui tournent en parallèle.

Le port du serveur Vite rejoint simplement ce mécanisme : chaque worktree a le sien, et deux développements en parallèle ont chacun leur HMR.

Il restait un détail à régler : Symfony génère des URLs d'assets absolues à partir des base_urls configurées, qui ne connaissent pas le port décalé. Dans un worktree, les pages allaient donc chercher leurs assets sur la stack du checkout principal, et on a mis un moment à comprendre pourquoi. Notre solution : un suffixe de port paramétrable dans les base_urls, vide par défaut (et en production) :

# config/packages/framework.yaml
framework:
    assets:
        base_urls:
            - 'https://%http.domain.front%%http.public_port_suffix%'

Et plutôt que de demander à chaque développeur de le renseigner à la main, la task Castor 🦫 qui démarre la stack détecte le worktree et synchronise la valeur dans un fichier parameters_override.yaml local (gitignoré, prévu pour la config personnelle) :

// Extrait de la task, appelée par `castor up`
$line = \sprintf("http.public_port_suffix: ':%d'", get_worktree_ports(get_worktree_name())['https']);
// … créé ou mis à jour dans parameters_override.yaml, sans toucher aux autres clés

Un nouveau worktree est ainsi utilisable en une seule commande, HMR compris.

Ce que nous avons perdu au passage

Pour être complet, voici ce que la migration nous a coûté :

• la minification svgo des images copiées a été abandonnée, à refaire à la source si le poids devient un sujet ;
• ts-loader faisait une analyse statique de code à chaque build, mais Vite ne le fait pas. Nous avons donc ajouté une nouvelle step dans la CI qui lance un yarn tsc --noEmit pour combler le trou (ne l'oubliez pas, c'est un vrai filet qui disparaît sinon) ;
• Reprise était expérimental au moment de la migration, avec une API susceptible de bouger d'une version à l'autre. Ce point s'est réglé tout seul depuis : la 1.0 est sortie et adopte la promesse de rétrocompatibilité de Symfony. Notre montée depuis la 0.8 s'est résumée à changer la contrainte de version, sans une ligne de code à toucher.

Une migration largement déléguée à l'IA

Un dernier point qui vous intéressera peut-être : nous avons laissé une IA faire le gros de cette migration. Pas la décision de migrer ni les choix structurants (le contrat d'assets, le mode de câblage du HMR), mais l'essentiel du travail mécanique et surtout l'itération sur les problèmes rencontrés.

Ce qui a rendu cela possible, ce n'est pas l'IA elle-même, c'est le filet de sécurité qui existait déjà autour du projet : une CI complète avec Behat, PHPUnit et nos tests e2e Playwright avec screenshots. Chaque webpack-isme du chapitre précédent a été détecté par un test, pas par un humain : les 19 scénarios Behat rouges pour le global fantôme, les screenshots pour le logo trop grand ou le pixel de différence, les 404 des fonts dans les captures. À chaque fois, l'IA a pu lire le rapport, reproduire le problème en local, corriger, et relancer la CI, sans que nous ayons à intervenir autrement que pour valider les choix.

Sans cette couverture de tests, la même migration aurait demandé une relecture visuelle de dizaines de pages à chaque itération, et nous n'aurions probablement pas osé déléguer autant. C'est un bon argument, si vous en manquiez, pour investir dans des tests de régression visuelle avant d'entreprendre ce genre de chantier.

Conclusion

Nous avons vu dans cet article que la migration mécanique d'Encore vers Reprise tient en quelques heures, et que le vrai travail se joue ailleurs : dans le contrat implicite que votre base de code entretient avec son bundler, et dans les quelques webpack-ismes qui ne se révèlent qu'au runtime. C'est là qu'il faut chercher si vous devez estimer une telle migration.

Le résultat en vaut la peine : notre build est cinq à six fois plus rapide, nous repassons sur la config par défaut de node avec 1 Go de heap (au lieu des 4 Go nécessaires auparavant), nous avons supprimé 583 packages npm, la config a été divisée par trois, et les développeurs ont enfin un hot reload avec fast-refresh React. En bonus, cela signifie également que le déploiement est également plus rapide de plus d'une minute, c'est appréciable !

Être early adopter d'un bundle expérimental a aussi ses bons côtés : le principal point de friction rencontré a fini en contribution upstream, mergée et publiée en quelques jours. La prochaine équipe qui migrera un site aux chemins d'assets figés aura une option de config là où nous avions initialement écrit un plugin local.