Retour sur l’AFUP Day Lyon 2025 : nos temps forts

L’ETL, ce qu’il vous manquait pour intégrer vos clients – Nicolas Jordan

Nicolas nous a plongés dans une problématique bien concrète : comment intégrer les données de clients ayant des API similaires, mais pas totalement compatibles. Sa réponse : une architecture ETL maison, basée sur Symfony.

• Extract : création de services Fetcher pour interroger l’API externe.
• Transform : un service DataMapper pour normaliser les données.
• Load : un Loader qui pousse les données dans l’API de l’entreprise.

Le tout orchestré par un service central, Orchestrator, avec gestion des erreurs, logs détaillés et mécanismes de DataResolver pour traiter les cas limites. Nicolas insiste sur la rigueur nécessaire : poser les bonnes questions (volumétrie, performances, connecteurs existants…), documenter, tester en entrée/sortie, loguer chaque étape, et concevoir une solution flexible et évolutive.

Débusquez les failles cachées avec PHPInfection & Pest – Vincent Amstoutz

Tester son code, c’est bien. Tester ses tests, c’est mieux. Vincent nous introduit aux tests de mutation pour valider réellement la robustesse de nos suites de tests automatisés.

Il illustre le principe des mutants : des modifications volontaires du code qui ne doivent pas passer inaperçues. Si un mutant ne provoque aucun échec de test, il met en lumière une faiblesse.

Outils phares : PHPInfection et Pest, qui permettent de configurer facilement ces tests de mutation. Mais Vincent tempère : on ne commence pas par ça. Il faut d’abord avoir une bonne base de tests classiques. Ensuite, on peut introduire les mutations progressivement, avec pragmatisme.

Comprendre et appliquer le Pattern Repository en PHP – Pablo Godinez

Pablo revient sur le modèle Repository tel que présenté dans DDD et par Martin Fowler. Il en décortique chaque aspect :

• Collection en mémoire,
• Critères de filtrage,
• Mécanismes cachés de persistance via l’ORM.

Il propose une approche pour rendre les Repository Doctrine plus lisibles, en les rendant filtrables via des méthodes enchaînables sur le QueryBuilder.

Il approfondit le fonctionnement de l’Unit of Work, inspiré de l’event sourcing pour optimiser les opérations SQL. Et conclut sur quelques règles d’or :

• Ne pas faire transiter toutes les lectures par l’ORM – le SQL reste parfois la meilleure option.
• Un mauvais modèle entraîne un mauvais repository.
• Pas un repository par entité systématiquement.
• Limiter les relations trop complexes.

Gestion des failles de sécurité dans l’écosystème PHP – Robin Chalas

Avec pédagogie, Robin nous rappelle une vérité essentielle : plus une base de code est vaste, plus elle est exposée aux vulnérabilités. Symfony ne fait pas exception avec ses 1,5 million de lignes de code et ses 29 000 téléchargements quotidiens.

Robin nous détaille le processus rigoureux de déclaration et de correction d’une faille :

1. Signalement privé à security@symfony.com,
2. Analyse par la security team,
3. Patch privé, puis relecture,
4. Notification des projets impactés (comme Drupal),
5. Publication d’un Security Advisory (CVE),
6. Release publique.

Ses conseils : publier un security.txt, utiliser composer audit, dépendre d’outils comme Dependabot, et surtout soutenir les mainteneurs de l’écosystème.

Votre app à l’épreuve de Black Friday – Thomas Di Luccio

Thomas nous emmène dans une histoire vraie de lancement raté pour illustrer les bonnes pratiques de scalabilité applicative. Son mantra : faire tomber l’app avant qu’elle ne tombe toute seule.

1. Tester sous charge

Utiliser Gatling, Locust, Artillery pour simuler un trafic réaliste, identifier les points de rupture.

2. Environnements ISO production

Ne jamais tester en prod. Des outils comme Platform.sh permettent de cloner fidèlement les environnements.

3. Observabilité dès le dev

Grâce à Blackfire, Thomas montre comment profiler, monitorer, et visualiser les goulets d’étranglement dans le code PHP.

4. Bien penser la mise à l’échelle

Se demander quelle ressource est sollicitée, pourquoi, et pour quel résultat. Ne pas surdimensionner à l’aveugle.