apidays Paris 2024

Dev, cloud & sécu3–5 décembre 2024Puteaux, CNIT Forest (La Défense)

Thème : The Future API Stack for Mass Innovation

Site archivé (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de décembre 2024 →

Thème officiel de l'édition selon la page apidays Paris 2024, les descriptions YouTube et l'OpenAPI Initiative : « The Future API Stack for Mass Innovation » (l'ancien thème « Software and APIs for Smart, Sustainable and Sovereign Societies » venait d'une page archivée en janvier 2024). Chiffres annoncés par l'organisateur : 5 000+ participants, 1 500+ entreprises, 300+ sessions, 300+ speakers ; 11 salles selon Loïc Lefloch. Sponsor platinum : IBM. Co-localisés sous la bannière FOST (Future Of Software Technologies) : Green IO Paris (500+ participants annoncés), Enterprise No-Code, un track OpenAPI Initiative (3 décembre), la première JSON Schema Conference, un Docs track et les DevPortal Awards (4 et 5 décembre). Journée d'ateliers OpenAPI la veille (2 décembre : Thomas Bayer, Mike Amundsen, Frank Kilcommins et Yousaf Nabi). Têtes d'affiche annoncées : Alain Damasio, Ilan Benhaim (Veepee), Julien Villeret (EDF), Laurent Fressinet, Loubna Ben Allal (Hugging Face), Michal Valko (Meta), Thomas Mesnard (Google DeepMind), Jean-Baptiste Kempf (Scaleway), Lélio Renard (Mistral AI), Gregor Hohpe, Mark O'Neill (Gartner), Arnaud Lauret (Postman).

Une édition à cheval entre deux mondes : le design, la gouvernance et les standards d'API (OpenAPI, JSON Schema, catalogues, plateformes) occupent l'essentiel des talks, tandis que l'IA générative y entre d'abord comme un nouveau trafic à gouverner par la gateway.

26 sessions résumées · 17 vidéos · mise à jour le lundi 5 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : 49 vidéos de la playlist officielle « apidays Paris 2024 » (titres, descriptions), 16 transcripts complets, la page officielle archivée (liste de 210 speakers), les programmes des tracks OpenAPI, Docs et Green IO, un compte-rendu détaillé de participant (Loïc Lefloch, deux pages de blog, 8 décembre 2024, 10 talks du 4 décembre), le récapitulatif de la JSON Schema Conference (Valeria Hernandez, 19 décembre 2024) et les slides de Teresa Pereira, lus en octobre 2026.

Limites : Synthèse fondée surtout sur le contenu des talks (transcripts de vidéos souvent réenregistrées après l'événement) et sur un seul témoignage de participant, centré sur les tracks design et architecture, l'auteur ayant volontairement évité les sessions IA. Aucun post LinkedIn lu. La playlist ne couvre qu'une cinquantaine des 300+ sessions et ne contient aucune keynote de la scène principale ; les jours ne sont connus que pour les sessions citées par le blog ou un programme de track.

Synthèse globale

1. Un salon devenu fédération de conférences

apidays Paris 2024 ne se résume plus à une conférence API : sous la bannière FOST, le CNIT accueillait aussi Green IO, Enterprise No-Code, un track OpenAPI Initiative, la toute première JSON Schema Conference, un Docs track et les DevPortal Awards. L'organisateur annonce 5 000+ participants et 300+ sessions ; Loïc Lefloch, qui revenait pour la première fois depuis 2014, compte 11 salles et voit dans l'événement « a cornerstone of the API community ». Benjamín Granados (JSON Schema) remercie apidays d'avoir donné aux standards ouverts leur propre espace. Revers de cette ampleur : impossible de tout voir. Loïc Lefloch a choisi les tracks design et architecture et laissé de côté l'IA.

2. Le design d'API reste le socle

La journée racontée par Loïc Lefloch est une succession de variations sur le même thème : concevoir avant d'implémenter. Gregor Hohpe parle de nommage et d'abstractions, Mike Amundsen de livrables de design indépendants de la technologie, Arnaud Lauret d'un kit de référence entre besoin, design et développement, Henning Schwentner de Domain Storytelling, Marco Pierobon de 17 principes, Peter Milne compare REST et GraphQL. Ses conclusions : des API « flexibles, réutilisables et modulaires », une documentation claire, et des API qui « résolvent de vrais problèmes » au lieu de servir seulement la technique. Ryan Day pousse la même logique vers un public nouveau, les data scientists, pour qui l'API ne compte pas : seule la donnée les intéresse.

3. L'IA générative arrive par la gateway

Dans la partie IA de la playlist, le message est convergent : un LLM est une API comme une autre, avec en plus des tokens à compter. Mathieu Ancelin (Cloud APIM, Otoroshi), Jérôme Guillaume (Kong) et l'équipe Azure API Management de Microsoft présentent tous les trois le même ensemble de fonctions : endpoint unifié, clés centralisées, quotas en tokens, cache sémantique, bascule entre fournisseurs, garde-fous. Mark O'Neill (Gartner) place ces AI gateways au tout début du hype cycle et prévoit qu'une part croissante de la demande d'API viendra de l'IA. Ancelin, lui, se dit « pas fan de GenAI » et préfère un pragmatisme d'intégrateur. À l'autre bout du spectre, Nouamane Cherkaoui (BPCE SI) livre un discours de dirigeant sur l'IA comme révolution, qui conclut que « true intelligence is human ». L'IA agentique et MCP, qui domineront l'édition 2025, sont absents des contenus lus.

4. Gouvernance : voir son patrimoine d'API avant de l'exposer

Trois retours d'expérience racontent la même prise de conscience. SNAM et De Volksbank ont modernisé leur architecture (microservices, Kafka, plusieurs gateways) avant de découvrir qu'elles ne savaient plus quelles API existaient, ni qui s'en servait. Chez NHS England, présenté par Ikenna Nwaiwu, la réponse passe par l'outillage et l'empathie envers les équipes productrices. Les sondages faits en salle par Nwaiwu donnent une rare mesure du public : 43 % des participants n'ont pas de point central pour trouver leurs descriptions d'API, 56 % voient des goulots dans leur processus de revue de design, environ 30 % savent que leur documentation ne reflète pas le comportement réel. Teresa Pereira (Siemens Energy) donne la version sécurité du même problème avec les API fantômes, zombies et orphelines.

5. Les standards ouverts entre élan et fragilité

OpenAPI, AsyncAPI et JSON Schema avaient chacun leur scène, et l'écosystème bouge : OpenAPI 3.1, Arazzo et Overlays sont sortis, une 3.2 est imminente. Mais les speakers ne cachent pas les fragilités. Oleg Nenashev constate que Moonwalk (OpenAPI 4) semble à l'arrêt vu de l'extérieur et ne sortira pas en 2024 comme annoncé ; il critique le YAML comme langage de modélisation et la quasi-absence de registre d'extensions. Benjamín Granados présente une communauté JSON Schema en forte croissance (TSC élargi, mentorat, catalogue d'outils), tout en annonçant que plusieurs mainteneurs payés, dont lui, ont été licenciés et contribuent désormais sur leur temps libre. Le récapitulatif de Valeria Hernandez parle pourtant d'un public dont l'engagement « a dépassé les attentes ».

6. Sécurité et sobriété, deux angles moins visibles

La sécurité est traitée par les protocoles plutôt que par les outils : profil FAPI 2, jetons liés à l'émetteur et PAR (Michał Trojanowski, Curity) ; mock OIDC pour tester la sécurité sans la désactiver (Amadeus). Côté Green IO, Romain Jacob (ETH Zürich) fournit le talk le plus contre-intuitif du corpus. Le réseau suisse SWITCH tourne en moyenne à 2,1 % de charge, éteindre des liens n'économise presque rien, et c'est le pic qui fait grossir l'infrastructure ; d'où sa réserve envers le « tout carbon-aware ».

7. Tensions, critiques et limites du corpus

Les rares critiques viennent de Loïc Lefloch : salles combles le matin avec des gens debout, interdiction de rester debout l'après-midi pour raisons de sécurité (ce qui oblige à changer de programme), longues files pour les dédicaces de livres, et pas assez de temps pour les stands sans sacrifier des talks. Il suggère de recueillir à l'avance les préférences des participants, « comme Devoxx ». Une part notable des vidéos sont des démonstrations d'éditeurs (Kong, Microsoft, Boomi, Cloud APIM) aux contenus très proches. Biais du corpus : un seul témoignage de participant, centré sur une journée et sur le design ; aucune keynote de la scène principale filmée dans la playlist ; plusieurs vidéos sont des réenregistrements faits après l'événement (Nenashev, Nwaiwu) ; aucun post LinkedIn lu.

Actions concrètes citées

  1. Gérer aussi les API que l'organisation consomme, pas seulement celles qu'elle expose (Mark O'Neill, rapporté par Loïc Lefloch).
  2. Traiter le design d'API comme du design d'expérience pour développeurs, et nommer les abstractions selon leur intention plutôt que leur implémentation (Gregor Hohpe, rapporté par Loïc Lefloch).
  3. Écrire une histoire, un vocabulaire, un diagramme et une description indépendants de la technologie avant la définition OpenAPI ou AsyncAPI (Mike Amundsen).
  4. Faire passer les appels aux LLM par une gateway : clés centralisées, quotas en tokens, cache sémantique, bascule entre fournisseurs et garde-fous sur les prompts (Ancelin, Kong, Microsoft).
  5. Mesurer la dérive entre documentation OpenAPI et comportement réel, en commençant par les parcours clients les plus utilisés (Ikenna Nwaiwu).
  6. Considérer les équipes productrices d'API comme des clientes de la plateforme et leur offrir des abstractions qui masquent la tuyauterie (NHS England, présenté par Ikenna Nwaiwu).
  7. Pour séduire les data scientists : SDK Python, identifiants externes standard, téléchargement en masse et filtre par date de dernière modification (Ryan Day).
  8. Séparer bénéfices directs et indirects dans le business case d'un programme API, sous peine de « business case qui s'évapore » (Claire Barrett).
  9. Protéger le jeton et le flux qui l'obtient : profil FAPI 2, jetons liés à l'émetteur (mTLS, DPoP), requêtes d'autorisation poussées (Michał Trojanowski).
  10. Inventorier les API fantômes, zombies et orphelines avec un catalogue centralisé et une surveillance continue du trafic (Teresa Pereira).

Session par session

Mardi 3 décembre

Keynoted'après le programme

Delivering Authentic Intelligence with OpenAPI

Darrell Miller — Microsoft, OAI Technical Steering Committee

  • Keynote du track OpenAPI Initiative, après l'ouverture d'Erik Wilde (INNOQ) sur l'état d'OpenAPI.
  • Aucun retour ni vidéo trouvés : seul le programme de l'OAI est disponible.
  • Oleg Nenashev y fait allusion dans sa propre session : Darrell Miller y a présenté les nombreuses mises à jour qui font avancer l'écosystème OpenAPI (3.1, Arazzo, Overlays, 3.2 à venir).

Conférence▶ vidéo + transcript

Tackling OpenAPI Drift

Ikenna Nwaiwu — auteur d'Automating API Delivery

  • Session du bloc « Design » du track OpenAPI Initiative.
  • Ampleur : sondage en salle à apidays Paris, environ 29 % des participants savent que leur documentation ne correspond pas au comportement de leur API, et 3 % ne savent pas. Résultats proches à Bruxelles et Berlin. Livre blanc APIContext (août 2024) cité : 75 % des API testées ont des endpoints non conformes, 25 % n'en ont aucun de conforme.
  • Cas Acme FS (fintech anonymisée, 70+ microservices Spring Boot) : un grand compte abandonne une preuve de concept, la dérive OpenAPI arrivant en tête de ses griefs ; 30 % des endpoints du parcours type dérivaient.
  • Deux ingénieurs, deux semaines : neuf contre-mesures étudiées (génération depuis le code, design-first strict, Smithy/TypeSpec, Pact, tests par fuzzing…). Retenue : des tests de contrat côté fournisseur via un proxy validant (Prism), en rejouant les collections Postman existantes avec Newman.
  • L'astuce : fusionner les fichiers OpenAPI (Redocly CLI), filtrer l'obsolète et forcer additionalProperties: false pour détecter les champs non documentés. Résultat : conformité de 70 % à 100 % en cinq jours, et le contrat suivant est signé.
  • Leçon : commencer par les parcours clients les plus fréquents ; solution de court terme, le vrai chantier de tests de contrat continuant en parallèle.
Voir sur YouTube (nouvel onglet) ↗

Mercredi 4 décembre

Keynote

The State of API Management

Mark O'Neill — Gartner

Retours : Loïc Lefloch (blog)

  • Une des deux keynotes d'ouverture de la journée, celle qui « a donné le ton » selon Loïc Lefloch.
  • Fin du monolithe d'API management : les organisations assemblent des outils spécialisés (« best of breed »). Les gateways se banalisent, et des éditeurs comme Postman ou SmartBear se concentrent sur des fonctions complémentaires.
  • L'IA comme moteur de consommation : chiffre Gartner cité, « 30 % de la hausse de la demande d'API d'ici 2026 viendra de l'IA ». Les AI gateways (routage de prompts, analyse des coûts, sécurité) sont placées au stade « Innovation Trigger » du hype cycle.
  • Phrase retenue : « You must manage APIs your organisation consume, not only those you provide ».
  • Autres tendances notées : adoption croissante de GraphQL (Shopify cité), et des API qui deviennent la couche d'interaction principale, devant les interfaces web.
  • Le chiffre des 30 % est repris le même jour par Peter Mörsch (Boomi) dans la session De Volksbank (« thank you Mark »).

Keynote

Build Abstractions, Not Illusions

Gregor Hohpe — auteur de Platform Strategy et co-auteur d'Enterprise Integration Patterns

Retours : Loïc Lefloch (blog)

  • Seconde keynote d'ouverture. Idée directrice notée : « We advance technology not towards its limit but to our own ».
  • Une plateforme doit permettre des solutions variées, pas anticiper tous les cas d'usage.
  • Les standards favorisent l'innovation : métaphore du grand incendie de Baltimore, où les pompiers venus d'ailleurs ne pouvaient pas brancher leurs tuyaux faute de raccords standardisés.
  • Bien nommer : une bonne abstraction porte un nom qui dit son intention, pas son implémentation. Anti-pattern « The Grim Wrapper » : la surcouche qui ne fait qu'emballer sans abstraire.
  • Formule reprise : « API Design is UX Design for developers ».

Conférence

Mastering API Architecture

James Gough — Morgan Stanley

Retours : Loïc Lefloch (blog)

  • Constat : les API modernes vivent derrière des couches d'APM et de gateway. Cela apporte cache et rate limiting, mais aussi complexité, latence et maintenance.
  • Remède proposé : des plateformes d'infrastructure as code qui prennent en charge l'onboarding des développeurs, l'automatisation, la fiabilité et la sécurité.
  • CALM (Common Architecture Language Model), projet FINOS, pour décrire l'architecture de façon standardisée. James Gough présentait aussi CALM à la JSON Schema Conference (« JSON Schema: powering FINOS architecture as code »).
  • Enjeux cités : API réparties sur de nombreux systèmes, dette technique, séparation des responsabilités.

Conférence

API Design Reference Kit

Arnaud Lauret — Postman

Retours : Loïc Lefloch (blog)

  • Deux points de friction : entre la définition du besoin et le design (API peu ergonomiques ou peu interopérables), puis entre le design et le développement (implémentations confuses).
  • Le kit : des capacités d'API écrites en langage naturel à partir des parcours utilisateurs ; des contrats d'interface (OpenAPI, enchaînements d'opérations, mocks) ; des détails d'implémentation (sécurité, comportements attendus) ; des guidelines réutilisables (méthodes HTTP, erreurs, conventions de données).
  • Consigne retenue : « Adapt to context, focus on outcomes ».

Conférence

GraphQL vs. REST

Peter Milne — Criteo

Retours : Loïc Lefloch (blog)

  • REST : « bad REST is easy », mais un bon REST exige une discipline stricte. La multiplication des endpoints et le mélange des responsabilités compliquent la maintenance.
  • GraphQL : un endpoint unique, un langage de requête qui simplifie le développement d'interfaces, une séparation nette entre client et serveur.
  • Les intentions d'adoption de GraphQL sont en hausse nette, ce qui fait écho à la tendance citée par Mark O'Neill le même matin.

Conférence▶ vidéo + transcript

Creating APIs That Data Scientists Will Love

Ryan Day — auteur de Hands-On APIs for AI and Data Science

Retours : Loïc Lefloch (blog)

  • Thèse (sur scène) : « to succeed in AI you must first master APIs », pour les data scientists comme pour les développeurs. Le talk reprend des conseils du livre à paraître au printemps 2025.
  • Se mettre à leur place : environ 38 % du temps d'un data scientist passe en préparation de données (rapport Anaconda cité). Leur demande se résume à « just give me the data » : l'API ne les intéresse pas en soi.
  • Cinq conseils : un SDK Python publié sur PyPI ; des identifiants externes standard pour faire des jointures (exemple de l'identifiant GSIS des joueurs NFL) ; des types de données imposés et documentés dans OpenAPI (Pydantic + FastAPI) ; un téléchargement en masse pour l'analyse exploratoire et l'entraînement ; un filtre par date de dernière modification pour les chargements incrémentaux (Airflow).
  • Ce qu'en retient Loïc Lefloch : les data scientists se font une opinion d'une API en quelques secondes, la première impression compte énormément.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Five Essential Design Assets for Successful APIs

Mike Amundsen — auteur de Design and Build Great Web APIs

Retours : Loïc Lefloch (blog)

  • Cinq livrables de design que tout projet d'API devrait avoir, sur le modèle des assets du design UI/UX.
  • Histoire : objectif en deux phrases (règle attribuée à Ridley Scott), actions, données, règles. Sans HTTP ni langage, donc accessible à tous. « Every great design begins with an even better story ».
  • Vocabulaire : tous les mots de l'API (ressources, actions, statuts), proche du langage omniprésent du DDD.
  • Diagramme d'interaction, qui montre les connexions possibles et non un workflow imposé.
  • Description agnostique et lisible par une machine (ALPS, Smithy, TypeSpec), qui dit ce qui est possible sans prescrire. Définition propre à la technologie (OpenAPI, AsyncAPI, Protobuf, GraphQL SDL), à partir de laquelle on génère code et documentation.
  • Conclusion citée par Loïc Lefloch comme par la vidéo : « Design is thinking made visible » (Saul Bass).
Voir sur YouTube (nouvel onglet) ↗

Conférence

Canva's High-Quality Public APIs

Ofir Zeevi

Retours : Loïc Lefloch (blog)

  • Titre et entreprise tels que rapportés par Loïc Lefloch (orthographiés « Canvas » dans son billet) ; session absente de la playlist.
  • Partir du problème à résoudre et d'un objectif clair.
  • Interne d'abord : construire l'API en privé avant de l'ouvrir, pour affiner l'expertise métier et garder la liberté de la faire évoluer.
  • Itérer par étapes (alpha, bêta, disponibilité générale) et concevoir l'extensibilité dès le départ.
  • Une équipe transverse dédiée aux API publiques, avec permanences hebdomadaires et revues de design.

Conférence

Modularizing your API with Domain Storytelling

Henning Schwentner

Retours : Loïc Lefloch (blog)

  • Session du Docs track (15 h 55).
  • Problème : les malentendus entre développeurs et métier font échouer les projets.
  • Domain Storytelling : un langage pictographique pour capter les récits des experts métier (acteurs, tâches, événements) et bâtir une compréhension commune.
  • Ces récits guident le découpage en microservices et la structure des API.
  • Bénéfice retenu par Loïc Lefloch : des exigences abstraites deviennent des représentations visuelles lisibles par les profils techniques comme non techniques.

Conférence

API Design Principles

Marco Pierobon

Retours : Loïc Lefloch (blog)

  • 17 principes relevés par Loïc Lefloch, dont : tout est compromis, à tracer dans des ADR ; versioning et politique de dépréciation ; kebab-case pour les URL et camelCase pour le JSON ; pas de hiérarchies de ressources trop profondes ; DTO pour séparer modèle de domaine et contrat d'API.
  • Robustesse : distinguer mises à jour complètes et partielles, suppression logique, opérations en masse atomiques avec verrouillage optimiste, retries idempotents, messages d'erreur utiles, opérations longues traitées comme des ressources suivables.
  • Gouvernance : tests de contrat contre les changements cassants, portail développeur, alignement sur des objectifs métier mesurables.

Conférence▶ vidéo + transcript

The Internet is Getting Emptier; That's a Sustainability Problem

Romain Jacob — ETH Zürich

  • Session de Green IO Paris (première journée, « Devil is in the Details »).
  • Un réseau presque vide (sur scène) : la charge moyenne des liens du réseau suisse SWITCH est de 2,1 %. Le trafic total croît, mais c'est l'écart entre pic et creux qui grandit, et c'est le pic qui dicte le dimensionnement.
  • Un matériel non proportionnel : un routeur consomme presque autant à vide qu'à pleine charge (image du tube d'hyperloop qu'on maintient sous vide). On exploite donc le réseau dans son mode le moins efficace.
  • Éteindre ne suffit pas : le protocole Hypnos permet de couper un tiers des liens la nuit, mais n'économise presque rien, car un transceiver branché consomme même port éteint. Ce sont des bugs constructeurs à corriger. Projet de base publique de mesures de puissance (« Network Power Zoo »).
  • Garder Internet vide : le coût marginal du trafic est négligeable (environ 6 W, 0,02 % de la puissance du réseau), mais remplir les tuyaux déclenche de nouveaux investissements. D'où un appel à la sobriété et à éviter le pic, avec une mise en garde contre le « tout carbon-aware », qui synchroniserait les charges.
Voir sur YouTube (nouvel onglet) ↗

Date non précisée

Conférence▶ vidéo + transcript

AI in My API Gateway... But Why?

Mathieu Ancelin — Cloud APIM

  • Position (sur scène) : l'auteur d'Otoroshi, gateway open source, se dit « pas particulièrement fan de GenAI ». Selon lui, des bibliothèques comme LangChain réimplémentent des fonctions que les gateways offrent depuis longtemps ; mieux vaut appeler les LLM à travers la gateway.
  • Une interface unifiée (compatible OpenAI) vers tous les fournisseurs, avec retries, circuit breaker, bascule vers un modèle local et load balancing.
  • Observabilité et coûts : rapports par clé d'API (modèle, prompt, tokens), quotas en tokens par consommateur, cache exact et cache sémantique (démo : 10 secondes sans cache, 71 ms avec).
  • Garde-fous sur les prompts (regex, webhook ou LLM validateur hébergé en interne contre les fuites de secrets, de données personnelles ou les propos toxiques), secrets injectés depuis un coffre-fort, et appels d'outils exécutés dans la gateway (WASM).
  • Démos annexes : masquage de données personnelles dans une réponse d'API, faux backend généré par un LLM pour prototyper.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Run, Secure, and Govern Your AI Traffic with an AI Gateway for Multi-LLM

Jérôme Guillaume — Kong

  • Point de départ (sur scène) : selon un chiffre de Microsoft Ignite cité, plus de 90 % des cas d'usage utilisent au moins trois fournisseurs de modèles. Développeurs, réseau/sécurité et ops ont chacun leurs inquiétudes.
  • Kong AI Gateway : un seul endpoint pour Azure, Bedrock, Gemini, Mistral ; choix du modèle par en-tête ; clés stockées dans la gateway (Vault) ; accès sous OAuth/OIDC ; load balancing (round robin, latence, usage).
  • Contrôle : rate limiting en tokens, templates de prompts imposés pour restreindre les usages, transformation par LLM des requêtes et réponses d'API existantes sans code (« AI augmentation »).
  • Fonctions sémantiques : cache, garde-fou (démo : question politique refusée) et routage vers le modèle adapté au prompt. Tableaux de bord de coûts par modèle et par consommateur (ELK, Prometheus/Grafana).
  • Démo très produit, mais elle recoupe presque point par point les talks Cloud APIM et Microsoft.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Azure API Management as a GenAI Gateway

Andrei Kamenev — Microsoft, Iheb Khemissi — Microsoft

  • Thèse (sur scène) : un LLM est « just another API » (endpoint, clé, requêtes), qu'il faut gérer, sécuriser et gouverner comme les autres, avec en plus des enjeux spécifiques liés aux tokens.
  • Coûts : métrique de consommation de tokens par abonnement, utilisateur ou en-tête, pour refacturer aux équipes ; limites en tokens par minute et quotas horaires à annuels.
  • Résilience : load balancing et circuit breaker pour consommer d'abord la capacité réservée (PTU) puis basculer vers le paiement à l'usage ou une autre région en cas de 429 (démo France Central vers Suède).
  • Sécurité : identité managée vers Azure OpenAI au lieu d'une clé partagée, clés d'abonnement révocables, validation de JWT.
  • Cache sémantique (Redis + embeddings) ; prise en charge de l'API d'inférence unifiée (Mistral, Cohere, Llama, Phi) et des entrées image de GPT-4o.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

An Operating Model for API Platforms

Ikenna Nwaiwu — auteur d'Automating API Delivery

  • Deux indicateurs pour une équipe plateforme API (sur scène) : la satisfaction des clients de l'API et le délai de livraison d'une API.
  • « Two customer mindset » : ne pas croire que les consommateurs sont les seuls clients. Une mauvaise expérience côté producteurs finit par dégrader celle des consommateurs. Exemple de NHS England : entretiens avec les équipes, analyse des besoins, enquête de satisfaction annuelle en hausse de 2020 à 2023.
  • Monter en abstraction : publier une API sur la plateforme NHS demandait de 3 à 8 semaines de checklist manuelle (Apigee, Azure DevOps, AWS). L'outil interne Proxygen génère et déploie le proxy depuis le fichier OpenAPI : -75 % de délai, -50 % de charge de support.
  • Sondage en salle à apidays Paris : 43 % des participants n'ont pas d'endroit central pour trouver les descriptions d'API (14 % ne savent pas) ; 56 % estiment que leur processus de design et de revue d'API comporte des goulots d'étranglement.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Walk the OpenAPI Talk, Moonwalk the Developer Experience!

Oleg Nenashev — Gradle

Retours : Oleg Nenashev (speaker)

  • Vidéo réenregistrée le 10 décembre ; le speaker dit avoir vécu une « awesome experience » et tenu le stand partagé avec AsyncAPI (speaker).
  • OpenAPI n'est pas une spécification formelle : une définition ne suffit pas à construire un service correct (réponses liées à une requête, comportement à états).
  • Histoire : quasi-stagnation entre la 3.0 (2016) et 2021 ; depuis, 3.1, Arazzo, Overlays et une 3.2 imminente. En 2024, « OpenAPI » dépasse « Swagger » dans les recherches web.
  • Moonwalk (OpenAPI 4) : relier requêtes et réponses, moins de verbosité, gabarits d'URL normalisés. Mais le dépôt semble à l'arrêt vu de l'extérieur, et la sortie annoncée pour 2024 n'aura pas lieu ; d'où le conseil de passer dès maintenant à la 3.2.
  • Critiques personnelles : le YAML est un mauvais langage de modélisation (il préférerait un DSL en code, Kotlin par exemple) ; le registre officiel d'extensions ne contient que x-twitter, ce qui oblige chacun à réinventer x-logo ou les modèles d'autorisation.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

The State of JSON Schema

Benjamín Granados — JSON Schema TSC, Celonis

Retours : Valeria Hernandez (récapitulatif JSON Schema, organisation)

  • Ouverture de la première JSON Schema Conference, track d'apidays Paris ; Benjamín Granados remercie apidays d'offrir un espace aux standards ouverts (sur scène).
  • Constat : 97 % des payloads d'API sont en JSON (chiffre cité). En 2021, le projet comptait 7 membres du TSC, 355 contributeurs, 6 000 membres et 4 sponsors, mais l'échelle de contribution était trouée au milieu.
  • Ce qui a été fait : nouveau site, « Tour of JSON Schema », catalogue d'environ 200 outils relié au méta-validateur Bowtie, 8 projets Google Summer of Code en 2024 (près de 100 candidats), rédactrices financées par Season of Docs, ambassadeurs, programme d'adoptants. Le TSC passe à 9 membres.
  • Revers : des membres payés à plein temps, dont lui, ont été licenciés ; le travail se poursuit sur du temps libre, avec des délais assouplis. Version « stable » visée l'année suivante, avec quelques ruptures assumées ; processus de publication propre hors IETF ; volonté de rejoindre une fondation.
  • Récapitulatif de Valeria Hernandez (équipe JSON Schema) : dix présentations, trois thèmes récurrents (design et standardisation des données, outillage, intégration applicative), et un engagement du public qui « a dépassé les attentes ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Getting the numbers for API-driven transformation to add up

Claire Barrett — APIsFirst, Women in APIs

  • Le problème (sur scène) : les organisations peinent à tirer la valeur promise de leurs investissements API (gateways plus chères que prévu, changements pas plus rapides), dans un contexte de concurrence pour les budgets.
  • Asymétrie des business cases : des semaines passées à chiffrer les coûts, quelques lignes vagues sur les bénéfices, d'où le risque d'un « evaporating business case ».
  • Direct ou indirect : portail, gouvernance et formation produisent des bénéfices directs et mesurables. Une architecture composable ou de nouveaux marchés sont des bénéfices indirects, à rattacher aux plans métier concernés ; seuls les revenus directs d'API produits sont vraiment attribuables.
  • Ce que font ceux qui réussissent : traiter les ingénieurs comme des clients, penser l'API comme un produit, discipline d'ingénierie, design en « sport d'équipe » métier et tech, culture API-first dès la conception.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Military-Grade Security for APIs

Michał Trojanowski — Curity

  • Toutes les données sont sensibles (sur scène) : même une liste d'e-mails volée nourrit d'autres attaques. Le but est de rendre la vie de l'attaquant assez dure pour qu'il aille ailleurs.
  • FAPI, profil de sécurité OAuth de l'OpenID Foundation, perd son « Financial-grade » en version 2 : il vaut pour tous les secteurs, d'où le titre « military-grade ».
  • Jetons liés à l'émetteur au lieu des bearer tokens : mTLS (RFC 8705, empreinte du certificat dans la claim cnf) ou DPoP (RFC 9449). Un jeton volé devient inutilisable.
  • Protéger le flux : PAR (RFC 9126) pour des requêtes d'autorisation authentifiées et intègres, JARM pour des réponses signées. PKCE sans flux hybride protège déjà des attaques par confusion de serveur.
  • À retenir selon lui : lire le court document FAPI 2, quel que soit le secteur.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Reconciling Zero-Trust APIs and Developer eXperience

Romain Quinio — Amadeus, Kevin Viet — Amadeus

  • Transcript automatique de mauvaise qualité (son de salle) : résumé partiel.
  • Contexte (sur scène) : en passant au cloud public et aux microservices, Amadeus perd le périmètre de confiance. Chaque microservice doit valider lui-même le jeton OpenID Connect.
  • Le dilemme : tester une API sécurisée est pénible à chaque étage de la pyramide de tests. La tentation est de désactiver la sécurité en intégration, au risque que ce réglage parte en production.
  • Leur réponse : un mock conteneurisé du protocole OIDC, décrit comme une API OpenAPI, réutilisable du poste du développeur (dev service Quarkus) à l'intégration. Démo : 401, 403 selon l'utilisateur, rôle « agent de voyage ».
  • Message : déplacer la sécurité vers la gauche et en faire une responsabilité des développeurs, pas seulement de l'équipe sécurité.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Future-Proofing API Management: How De Volksbank is Ready for Tomorrow's Challenges

Sebastiaan Kalshoven — De Volksbank, Peter Mörsch — Boomi

  • Contexte (sur scène) : banque néerlandaise (ASN, SNS, RegioBank, BLG Wonen), 3,5 millions de clients, environ 4 000 salariés dont 1 100 ingénieurs. « The biggest of the small banks », avec des ressources limitées.
  • Le problème : une belle vision d'intégration par API, mais sans outillage pour la piloter. Résultat : API redondantes, réutilisation faible, aucune vue d'ensemble sur deux gateways (Broadcom à l'extérieur, Gravitee à l'intérieur) et Kafka.
  • Projet Lighthouse : une évaluation de maturité notée par les équipes elles-mêmes, utile pour convaincre les parties prenantes. Puis un plan de contrôle construit avec APIDA (racheté par Boomi) : catalogue unique, gouvernance, contrôles de sécurité OWASP en amont, analytics.
  • Talk orienté leadership plutôt que technique, avec une forte part de discours éditeur ; le speaker y évoque aussi la démonstration d'attaque d'API d'un hacker le matin même.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

API Governance as an enabler of an architectural evolution: The SNAM experience

Alessandra Gambatesa — SNAM, Simone Manzoni — SNAM

  • Contexte (sur scène) : l'opérateur gazier italien (environ 41 000 km de réseau, 9 sites de stockage) a engagé il y a environ sept ans une rationalisation de son parc applicatif : passage de monolithes en cascade à des microservices, Kafka, agile et DevOps.
  • La désillusion : l'architecture était devenue cloud native, mais personne ne savait plus quels composants existaient, qui les utilisait ni lesquels étaient réutilisables.
  • Le tournant : redéfinir les microservices comme des produits API porteurs d'un sens métier, désigner des propriétaires de processus, puis adopter un outil de gouvernance unique et non intrusif.
  • Trois principes : séparer la complexité organisationnelle de la complexité technique, offrir un point de contact unique aux fonctions hors DSI, ouvrir une marketplace d'API aux partenaires (en cours).
  • Présenté comme un retour d'expérience avec ses erreurs, et non comme un modèle à suivre.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Focus on Data, on the Road to AI

Nouamane Cherkaoui — BPCE Solutions Informatiques

  • Discours de dirigeant plutôt que talk technique (sur scène) : l'IA présentée comme une quatrième révolution, portée par l'explosion des données, qui attire aussi les cybercriminels.
  • Paradoxe de productivité : la technologie progresse sans gain de productivité visible, en raison du décalage historique entre une invention et son impact (la machine à vapeur citée).
  • Relativiser les peurs par l'histoire (imprimerie, électricité, e-mail) ; pour les dirigeants, apprendre puis adapter, à partir de cas d'usage concrets.
  • L'IA seule ne donne pas d'avantage concurrentiel durable, puisque tout le monde l'adopte. Anecdote Lego : le redressement est venu de décisions humaines, quand les outils d'IA testés auraient poussé vers le métavers.
  • Conclusion : « true intelligence is human ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo

Do not live in the Shadow (APIs)

Teresa Pereira — Siemens Energy

  • D'après les slides publiées sur Speaker Deck.
  • Trois familles : API fantômes (hors des canaux surveillés, par précipitation ou héritage), zombies (remplacées mais toujours actives), orphelines (documentées mais sans trafic).
  • Risques : un rapport de 2022 cité évoque 5 milliards de requêtes malveillantes visant des API fantômes ; la fuite d'Optus (environ 10 millions de clients) est passée par une API REST de test non surveillée.
  • Parades : découverte automatisée et validée à la main, catalogue centralisé (propriétaire, version, cycle de vie), surveillance continue à partir d'un trafic de référence, culture API-first, sécurité testée tôt.
  • Formule : « APIs can be open windows, even when the doors are locked ».
Voir sur YouTube (nouvel onglet) ↗

Sessions sans retour trouvé (36)

  • AI and the Future of Humanity: Biopunk or Biohacking? (panel avec Alain Damasio, Green IO, 3 décembre)
  • OAI Track Introduction and the State of OpenAPI (Erik Wilde, INNOQ, 3 décembre)
  • Interventions annoncées sans contenu retrouvé : Ilan Benhaim (Veepee), Julien Villeret (EDF), Laurent Fressinet, Loubna Ben Allal (Hugging Face), Michal Valko (Meta), Thomas Mesnard (Google DeepMind), Jean-Baptiste Kempf (Scaleway), Lélio Renard (Mistral AI)
  • AI-Enhanced API Documentation (Saheed Abiola Lasisi, JPMorgan Chase, Docs track, 4 décembre) : vidéo
  • Harnessing AI for API Business Documentation in a Devportal CMS (Kristof Van Tomme, Pronovix, Docs track, 4 décembre) : vidéo
  • Discoverability, Findability, and AI: lessons learnt from the DevPortal Awards (Laura Vass, Docs track, 4 décembre)
  • TMForum's AsyncAPIs For a New Era of Event-Driven Architecture : vidéo
  • Contract-Driven Development for Event-Driven Architecture : vidéo
  • Streaming Data Events Into An AI Cognitive Event Mesh Using AsyncAPI : vidéo
  • AI Agents Meet AsyncAPI: Conversational Interfaces For Event Streams : vidéo
  • Governance of event-driven distributed systems (Omid Eidivandi, Groupe La Centrale) : vidéo
  • Generic and Extensible Web of Things Manager using JSON Schema & AI (Andreas Eberhart, Dashjoin) : vidéo et slides
  • Unlocking Dynamic Frontend Development Through JSON Schema (Neha Singla, Apple) : vidéo
  • Layered Approach of API Security Strategies and its Business Impact : vidéo
  • Building an AWS Serverless Application with Terraform (Andre Lopes, Tesla) : vidéo
  • The Power of Generative AI in API Product Testing and Validations : vidéo
  • The experience choosing a framework for documenting APIs (Laura Lacarra Arcos) : vidéo
  • Design, Debug, Test and Mock APIs with Kong Insomnia (Pierre-Alexandre Loriot) : vidéo
  • AI Voice agents for the Business and Phone Channels (Katya Lainé, TALKR.ai) : vidéo
  • Embeddings: Core Concepts for Developers (Jocelyn Matthews) : vidéo
  • Cross-platform Catalogs for Unified Governance and Developer Experience : vidéo
  • APIs and GenAI: Your Perfect Combo with LLM-Powered Frameworks : vidéo
  • API Integration augmented by GenAI (Pierre-Olivier Patin, Sogeti) : vidéo
  • Hexagonal Modules: A Cleaner Approach to Monolithic API Design (Adil Baaj) : vidéo
  • How to Build an Integration Platform using Open Source (Magnus Hedner) : vidéo
  • Develop in parallel and ship earlier with OpenAPI and mocking (Lee Turner) : vidéo
  • Fostering API Productization in Federated API Architecture (Abhijit Dey, Axis Bank) : vidéo
  • Establishing a Specification Framework for API Management Federation : vidéo
  • Success stories of API integration : vidéo
  • An Alternative View on OpenAPI Docs, Start Finally Doing it Right! : vidéo
  • Orchestrating APIs using AWS Step Functions (Daniel Gutierrez Diez, track OAI) : vidéo
  • Generate OpenAPI Schema from Golang Code with the Fuego Framework (track OAI) : vidéo
  • Project API Forge: Streamlining Dev-First API Lifecycle Management : vidéo
  • Advanced API Management & Operations, A Developer & Customer-Focused Approach : vidéo
  • Opey, the AI for API Discovery and Future of Fintech : vidéo
  • Designing a Composable API Platform Powered by Open Standards : vidéo

Sources