Jusqu’au Forum PHP 2023, 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

J’ai créé un service SaaS, voyons ce qu’il ne faut pas faire J’ai longtemps cru, à tort, que transformer un outil open-source en solution dans le Cloud pouvait être une tâche facile. Et c'est souvent en sautant le pas que l'on se rend compte des détails. J’ai créé un ETL open-source, qui permet de synchroniser des applications entre elles. Tout fonctionnait très bien depuis plusieurs années : nous installions pour chaque client les outils nécessaires sur un serveur dédié. Tout placer dans le Cloud, avait en théorie plusieurs avantages : mutualiser une infrastructure et donc de réduire les coûts pouvoir augmenter ou réduire la capacité de l'infrastructure réduire le coût de maintenance C’est vrai... à quelques détails près. Ces petits détails qui ont fait de ce chemin un parcours très sportif. Gestion des coûts, multi-région, multi-cloud, Kubernetes, Serverless, ... plein de termes à la mode depuis quelques années dont il faut souvent se méfier. Je vous raconte ce que j'ai réussi, ce qui n'a pas fonctionné et ce que je ne referai certainement pas.

Salle Hopper ABCDEF 12/10/2023 11:40-12:20

Lors de ta conférence, tu nous feras un retour d’expérience sur ce qui n’a pas fonctionné. C’est un choix intéressant, utile et qu’on retrouve peu souvent. Qu’est-ce qui t’a poussé a orienter ton sujet de cette façon ?

Je crois que j’ai voulu proposer un sujet que j’aurais aimé voir au Forum PHP en tant que spectateur. C’est effectivement assez rare d’avoir des retours d’expérience lors de conférences. J’imagine que c’est cet à-priori un peu honteux d’affirmer qu’on a pu faire des erreurs et de les montrer aux autres qui repousse les gens à le faire. L’adage dit qu’il n’y a que ceux qui ne font rien qui ne font jamais d’erreurs.

Pour ma part, j’adore lire des retours d’expérience de choses qui n’ont pas fonctionné. C’est une source d’apprentissage énorme. Bien plus que le retour d’expérience positif qui voudrait nous vendre une solution miracle. Si je caricature un peu, c’est la confrontation entre la théorie et la pratique. C’est aussi un moyen de ne pas reproduire des erreurs que l’on n’a pas faites soi-même. Et ça, c’est une sacrée économie 😁.

En quoi ton expérience sur les outils d’ecommerce et les outils de PIM ont influé sur la façon de créer un ETL ?

C’est avant tout la raison pour laquelle j’ai commencé à créer un ETL. Il y avait des besoins de plus en plus grands avec l’arrivée des réseaux sociaux, des marketplaces, la volonté des clients d’intégrer ces outils web avec le vieux monde de l’informatique d’entreprise, ou de se partager des données entre partenaires (exemple: entre un fabricant et son distributeur). Le monde du e-commerce, et plus largement le marketing, a un besoin d’avancer très vite.

Tout le paradoxe était que le monde du web et du ecommerce était majoritairement écrit en PHP, avec des clients d’API tout prêts, des librairies capables de lire à peu près tous les formats de fichiers ou de se connecter à à peu près tous les systèmes de messagerie ou de bases de données. Mais à l’époque où j’ai commencé, l’outillage écrit en PHP était trop pauvre, un connecteur était lourd à écrire et il y avait de vrais enjeux sur la capacité de montée en charge sur de gros volumes de données. On voyait très souvent des connecteurs écrits sous forme de scripts de plusieurs milliers de lignes où il était difficile de retrouver son chemin.

Alors j’ai commencé à écrire mes propres outils. Certains pour éliminer les fuites mémoire. D’autres pour me faciliter la maintenance des connecteurs que j’écrivais. Je me suis créé des méthodes pour pouvoir réussir à avancer aussi vite que les demandes de mes clients. De fil en aiguille, j’en suis arrivé à créer un compilateur, un outil qui écrit la très large majorité du code PHP à ma place. Paradoxalement, je suis revenu aux scripts de plusieurs milliers de lignes, mais je n’ai plus à maintenir le code qu’ils contiennent.

Tu indiques qu’il faut se méfier des termes à la mode. Quel est ton avis sur ce qu’on appelle la « boring architecture » ?

Cette édition du Forum PHP sera le 10ème grand évènement AFUP auquel je participe. On voit beaucoup de théorie en conférence, sur des technologies ou méthodes nouvelles. On revient toujours très enthousiaste de ces nouvelles choses à découvrir et à tester. On se rend compte au bout de quelques semaines (ou plus) de la taille de la montagne qu’il faut arpenter pour réussir à appliquer ce qu’on a vu en conférence.

Évidemment, tout n’est pas à jeter dans les termes à la mode. Mon avis à propos de la « boring architecture », c’est qu’il y a un difficile équilibre à trouver. On a le devoir dans nos métiers de rendre nos projets les plus stables possible, où on n’aurait jamais besoin de lancer une action de sauvetage en urgence. Et il faut également que tous les membres de l’équipe soient rapidement compétents sur les nouvelles méthodes et les nouveaux outils. Malgré ça, il ne faut pas non plus s’interdire de mettre en place des choses nouvelles que l’on aurait par exemple pu voir en conférence.

Je vais peut-être énoncer des évidences pour certain·e·s. Ma méthode c’est d’expérimenter sur des petits projets qui n’ont pas d’enjeu. Ensuite, avec cette petite expérience, rechercher de manière objective quels seraient les avantages et les inconvénients à continuer. S’il y a plus d’avantages que d’inconvénients, essayer de l’appliquer de manière plus large dans l’équipe ou l’entreprise. Puis si ça porte ses fruits, de progressivement étendre l’usage de ces technologies ou méthodes.

Une conférence présentée par

Grégory PLANCHAT

Déjà tout petit Grégory réalisait des animations en pixel art en QBasic et un poste MS DOS 16 couleurs Il a (beaucoup) grandi et ses compétences QBasic n'ont pas été mises à profit dans sa carrière professionnelle. Il a par accident appris le PHP 4 sur le site php-facile et en a profité pour "coder" des super trucs sur PHPBB et PHPNuke. Tant de choses découvertes à cette époque où il n'était pas nécessaire d'exposer ses merveilles d'ingéniosité sur Github.

Autres Interviews