La parole est aux speakers : Amaury Bouchard
Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Repenser les APIsDepuis vingt ans, les APIs se sont imposées comme un pilier du web. Nous avons connu XML-RPC, puis SOAP, puis REST, puis GraphQL, et désormais des écosystèmes entiers reposent sur des échanges machine-to-machine standardisés. Mais derrière cette normalisation, certaines pratiques se sont transformées en dogmes : REST “pur”, JWT obligatoire, endpoints découplés à outrance… souvent au détriment de la simplicité et de la maintenabilité. Dans cette conférence, nous allons remettre en perspective les fondements des APIs, et explorer des approches plus pragmatiques :
À travers des exemples concrets et des cas d’usage réels, nous verrons comment repenser la conception d’une API à partir de ses besoins réels, et non d’un modèle imposé. Une conférence qui invite à désapprendre certaines habitudes, à redécouvrir la puissance du protocole HTTP, et à bâtir des APIs plus efficaces et plus durables. |
E.S.G.I. 22/05/2026 15:20-15:40 |
On a eu la vague SOAP, la domination REST, la hype GraphQL… Est-ce qu’aujourd’hui on est arrivés à maturité sur la conception d’API, ou est-ce qu’on continue de réinventer la roue sans cesse ?
Ça fait très longtemps qu’on a atteint la maturité sur les architectures réparties. Comme pour beaucoup de choses, nous avons collégialement tendance à oublier les enseignements du passé, et à croire que les choses n’existaient pas avant qu’on soit là pour les voir.
Mais dès les années 90, on connaissait les illusions de l’informatique distribuée :
• Le réseau est fiable.
• Le temps de latence est nul.
• La bande passante est infinie.
• Le réseau est sûr.
• La topologie du réseau ne change pas.
• Il y a un et un seul administrateur réseau.
• Le coût de transport est nul.
• Le réseau est homogène.
Donc oui, je pense qu’on a tendance à réinventer la roue, avec des cycles de simplification (CORBA > SOAP > XML-RPC > REST) jusqu’à ce qu’on se rende compte qu’on a peut-être trop simplifié et qu’on recomplexifie (GraphQL).
Quand tu « repenses » une API, est-ce que tu penses d’abord à la machine qui va la consommer, ou à l’humain qui va devoir lire la documentation ?
Il y a plusieurs points importants dans une API :
• Est-ce qu’elle est facile à mettre en place ? Il ne sert à rien de développer une API « dans les règles de l’art » si ça prend inutilement trois fois plus de temps que nécessaire.
• Est-ce qu’elle est facile à « consommer » ? Parfois il vaut mieux complexifier un peu le code d’une API, si ça simplifie énormément son utilisation. Mais parfois, il suffit de faire différemment, pour que ce soit plus facile à utiliser.
• Est-ce qu’elle sera facile à maintenir ? Plus un développement est simple, plus il sera maintenable. Cela peut vouloir dire d’avoir moins de code à écrire, ou bien d’utiliser moins de « couches » logicielles, moins de dépendances qui font de la magie et que l’on ne maîtrise pas.
Pourquoi tu as voulu créer le framework Temma et le manifeste « PHP Way of Life » ? Il y a une histoire derrière ou c’était une nécessité que tu as ressenti en bossant sur des projets ?
Temma a été créé en 2007, pour les besoins du site ComprendreChoisir (ensuite renommé Ooreka, depuis absorbé par PagesJaunes). À l’époque, le paysage des frameworks PHP était assez différent, et c’était un choix qui était pertinent. Depuis, je l’ai toujours fait évoluer en cherchant le bon équilibre, pour qu’il soit plus simple à prendre en main que les gros frameworks bien connus, mais plus complet que les micro-frameworks, tout en faisant garder la maîtrise du code.
Temma est utilisé sur des sites à très fort trafic, aussi bien que dans des contextes où la sécurité et la conformité sont primordiales.
Le but du manifeste PHP Way of Life est d’exprimer les idées derrière Temma. Principalement, le fait que les bonnes pratiques ne sont pas quelque chose de monolithique et d’immuable, mais qu’elles doivent être adaptées à chaque situation. Les méthodes, pratiques et outils qui fonctionnent dans une équipe de 80 ou 200 personnes ne peuvent pas être efficaces dans une équipe de 12 personnes.
Le manifeste pousse volontairement le curseur un peu loin sur certains sujets, pour amener à la réflexion et à la discussion. L’idée n’est pas d’imposer une manière de voir les choses ; au contraire, c’est de dire qu’il y a plusieurs visions qui peuvent s’enrichir les unes les autres.
Une conférence présentée par
 Amaury BOUCHARD |
Directeur technique chez Homunity, Amaury a été coordinateur de l'AFUP Paris dans les années 2010. Il a donné des conférences au Forum PHP, au PHP Tour et lors de meetup, ainsi que dans des universités et des écoles d'ingénieurs. Il a réalisé plusieurs projets open-source (framework Temma, outil de sauvegarde Arkiv, outil de déploiement Dispak…), et a mené la rédaction du manifeste PHP Way of Life. Il est l'auteur du blog De geek à directeur technique, du manifeste PHP Way of Life, ainsi que du compte PHP Zen sur les réseaux sociaux. |