Programme
CI/CD à toutes les sauces : recette d’un .gitlab-ci.yml savoureux pour projets PHP multi-environnements
Vous êtes dev PHP et vos déploiements manquent parfois de sel ? Vous jonglez avec plusieurs environnements (production, recette, release...) et la simple idée d’un .gitlab-ci.yml vous donne des sueurs froides ? Pas de panique, voici la recette pour transformer votre CI/CD en plat étoilé !
Dans cette conférence, nous vous partagerons notre expérience de mise en place d’un pipeline GitLab CI optimisé, conçu pour gérer plusieurs projets PHP dans un contexte multi-environnements. Au menu :
- Un .gitlab-ci.yml pensé comme une vraie recette de chef : modulaire, réutilisable et maintenable.
- La gestion fine des variables d’environnement et des secrets, pour éviter les mauvaises surprises en cuisine.
- Une stratégie de déploiement "à la carte" qui s’adapte à chaque service et à chaque environnement.
Bonus : quelques astuces pour éviter que vos tests unitaires ne brûlent au fond de la casserole ou que vos déploiements ne tournent en vinaigre.
Venez avec vos tabliers et repartez avec une CI/CD aux petits oignons !
PHP, Mercure et IoT – Quand PHP devient plus que Full Stack
Quand on parle IoT ou informatique embarquée, on pense à C/C++, Javascript, Python mais pas à PHP…
Réparons cet affront en étudiant ensemble les possibilités que nous offre PHP dans le monde de l’embarqué !
Nous allons voir ensemble une application assez simple, nous permettant de déverrouiller des casiers à colis depuis une PWA, basée sur PHP, Symfony et Mercure.
S'y retrouver dans le dédale du code
Explorer le code source d'un projet, c'est comme arpenter les couloirs d'un labyrinthe en suivant une carte incomplète : si certains chemins sont bien indiqués, d'autres s'avèrent être de fausses pistes ou des impasses. Prenez une classe sans enfants non marquée comme "final", par exemple : l'absence du mot-clé est comme un panneau pointant vers une voie sans issue.
Combien de ces chemins laisse-t-on accidentellement (ou délibérément) ouverts ? Cette présentation introduit le principe "Closed-by-Default", une reformulation de principes existants visant à garder ces chemins fermés, soulageant ainsi la charge cognitive du développeur.
C'est aussi une exploration de l'évolution de PHP au fil du temps, chaque version apportant des fonctionnalités pour rendre le labyrinthe aussi praticable que possible. Nous verrons également comment utiliser des outils d'analyse statique pour automatiser les règles correspondantes, donnant ainsi l'assurance que tous les chemins mènent quelque part.
🎹🎻🎸 Et si nous cherchions des morceaux de musique 🎼🎶 ?
Pendant cette session, nous allons utiliser les principes de la recherche vectorielle pour trouver des morceaux de musique 🎶 ressemblant (peut-être) à d'autres. Pour cela, nous ferons un rappel des principes de la génération d'embeddings pour représenter n'importe quel type de données, qu'elles soient textuelles ou binaires.
2 secondes pour détecter la fraude : orchestrer Kafka dans un système bancaire critique
Dès 2025, les banques européennes devront mettre en place le Verification of Payee (VOP), un système de vérification en temps réel du nom du bénéficiaire par rapport à l'IBAN saisi lors d'un virement. L'objectif principal est de lutter contre la fraude par usurpation d'identité. Si l'utilisateur attend une réponse immédiate, la réalité en coulisse est bien plus complexe : nous devons orchestrer un flux asynchrone sophistiqué impliquant des APIs externes, Kafka, des microservices distribués et des vérifications anti-fraude.
Dans ce talk, je partagerai comment nous avons intégré ce flux dans un processus synchrone en moins de 2 secondes chez BoursoBank, en détaillant la partie APIs PHP et leur intégration au sein d'un écosystème distribué plus large orchestré via Kafka. Je vous expliquerai comment nous avons géré la corrélation des requêtes, les timeouts et le monitoring d'un flux distribué, autant de défis concrets liés à la mise en œuvre d'une architecture asynchrone sous contrainte de latence.
Je comparerai également cette implémentation avec d'autres cas d'usage asynchrones chez BoursoBank afin d'identifier les situations où il est pertinent de simuler un comportement synchrone et celles où il est préférable d'assumer pleinement l'asynchronie.
Le progrès réside dans les BC Breaks
La rétrocompatibilité, ou Backwards Compatibility (BC) en anglais, est le principe selon lequel les pratiques et les conceptions élaborées dans un contexte antérieur restent valables dans le contexte actuel. Rompre la rétrocompatibilité (BC break) correspond à faire des changements qui altèrent la conception sous-jacente, entraînant souvent des perturbations qui cascadent pour les utilisateurs.
Les avantages de maintenir la compatibilité sont évidentes, alors quelles sont les raisons que divers secteurs la rompent régulièrement ? Dans cette conférence, nous examinerons des exemples issus de divers domaines afin de montrer pourquoi la rupture de la rétrocompatibilité est généralement le prix nécessaire et inévitable du progrès.
Test simplifié à moitié pardonné
Quand une modification dans une application casse un test, il est pénible de devoir passer plus de temps à essayer de comprendre l'utilité dudit test qu'à corriger le problème. Au final, garder une suite de tests aussi lisible et maintenable que le code applicatif est primordial, car cela garantit le bon fonctionnement de notre logiciel.
Dernièrement, certaines techniques comme le pattern Arrange-Act-Assert se démocratisent. Dans cette présentation nous étudierons une astuce en particulier : comment, avec l'aide de Faker et des « named arguments » de PHP 8.0, on peut simplifier l'instantiation des objets utilisés par les tests pour en améliorer la lisibilité et la maintenance.
Quand faire des filtres à facettes n'est pas si simple
Avez-vous déjà mis en place des filtres à facettes sur votre application SaaS ? Vous est-il déjà arrivé que chaque client vous demande d’ajouter des champs - parfois plusieurs dizaines - spécifiques à son contexte ? Le tout en souhaitant gérer ses propres noms de champs pour ne pas perturber ses utilisateurs, et pouvoir filtrer sur ces champs spécifiques ? C’est exactement la demande qui a fini par arriver sur notre application. Je vais vous expliquer la solution que nous avons mise en place pour y répondre.
Design patterns émergents IA dans Symfony : stratégie de prompts, pipelines, agents, orchestrateurs
L’intégration de l’IA dans Symfony arrive à un tournant : la communauté commence à formaliser de véritables design patterns, comme en témoigne la présence du sujet « Emerging AI Design Patterns in Symfony » à SymfonyCon Amsterdam 2025. Ce talk propose un panorama des principaux patterns applicables aux projets Symfony — Proxy LLM, orchestrateur d’outils, agents à mémoire, pipelines RAG, automatisation de fonctions métiers — illustrés par des exemples de code concrets, pensés pour favoriser le découplage et la testabilité. Vous y découvrirez comment choisir le pattern adapté à votre contexte (volume, latence, sensibilité des données) ainsi que les anti-patterns et pièges fréquents à éviter pour construire des intégrations IA robustes et évolutives.
