Le futur du web sera sans tête

WordPress, Drupal, Magento, Shopify ou Prestashop sont-ils en fin de vie ? Une des prochaines grandes évolutions dans la façon de créer des sites web et applications leur fera-t-il la peau ? Ou plutôt, vont-ils se faire couper la tête ?

Je parle évidemment de l’approche headless et API-first.

Il est reproché aux outils actuels d’être trop monolithiques et pénibles à maintenir. Il existe bien des extensions ou des connecteurs pour ajouter de nouvelles fonctionnalités mais il y a quand même une sensation de « peut mieux faire ».

Pourtant, techniquement aujourd’hui, il est possible de revoir l’approche back-office + front-office couplée et d’opter pour une approche headless, c’est à dire sans front-office ou découplée.

Concrètement, il faut imaginer avoir des outils pour le back-office. Ces outils peuvent être de provenance variée, ils peuvent être interchangeables et vont alimenter via des flux de données une moulinette créée sur-mesure qui va générer l’affichage du front-office mais de façon plus large va organiser et distribuer le contenu.

La stack technique est complètement revue :

• Approche API first : quels sont les bons outils accessibles via API déjà existant à brancher ?
• Approche multiservices :  on empile des micro-services tiers qui fonctionnent les uns à côté des autres. ;
• Approche cloud pour le stockage et l’hébergement mais aussi pour la transparence des mises à jour et la montée en charge ;
• Indépendance technique totale entre le front et le back ;
• Diffusion simplifiée : à partir d’un même back-office, il est possible de diffuser du contenu sur-mesure pour chaque usage (IoT, web, app, flux pour place de marché, publications sociales, fichiers…).

Des avantages qui donnent vraiment envie

Sur le papier, on obtient alors le meilleur des mondes :

• Utilisation des meilleurs outils (approche « best of breed ») ;
• Interchangeabilité des outils (si une brique ne convient plus, on la remplace) ;
• Plus de facilité à maintenir et à faire évoluer avec une dépendance bien moindre à une techno, un framework ;
• Moins de risques de sécurité (pas d’accès front attaquable en direct) mais une obligation de gestion des droits d’accès ;
• Plus grande facilité à faire évoluer l’ensemble (aussi bien le front que le back) sans engager de refonte (les évolutions peuvent toucher qu’une seule brique fonctionnelle) ;

On change complètement de paradigme et l’approche globale devient XaaS As A Service : le X étant remplacé par la mission à réaliser. S’il s’agit de faire du ecommerce, ce sera un vrai eCommerce as a service. S’il s’agit de faire de la publication de contenu, ce sera un vrai CMS as a service etc. S’il s’agit de faire un mouton à 5 pattes, aucun problème, le périmètre fonctionnel dépend des outils tiers interfacés. Avec cette approche, on obtient uniquement le périmètre fonctionnel souhaité, pas plus, pas moins. On compose sur-mesure.

Aujourd’hui, cette approche API commence à faire son bout de chemin mais l’importance des outils CMS et eCommerce empêche d’aller au bout de la démarche. Le moteur de recherche interne Algolia, par exemple, se branche très bien sur un site ecommerce ou un CMS mais il faut passer par une brique intermédiaire : l’extension. Et, il faut une extension pour chaque outil, chaque techno et il faut parfois en plus gérer les versions. Dans une approche API first, il y a uniquement les données qui transitent et des appels à l’API. Ça peut faire plus de travail de développement du côté du client final mais ça apporte beaucoup plus de souplesse.

Tout n’est pas si rose

Basculer vers une approche API-first et headless est nouveau. Comme tout ce qui est nouveau, c’est plus cher et les premiers payent les pots cassés. Il faut réinventer des fonctionnalités qui marchaient bien, il faut former, il faut tester…

Surtout, cette approche nécessite plus de préparation et d’anticipation. Du temps de cerveau supplémentaire pour vraiment choisir quels sont les vrais besoins et y associer les bons outils. Avec un WordPress ou un Prestashop, on ne se pose pas la question : on installe et on utilise ce que l’on a. Si ça ne convient pas, on ajoute des plugins ou on code. Ici, c’est différent : on doit d’abord faire l’effort de savoir ce dont on a besoin, le formaliser et trouver la bonne brique. C’est plus impliquant et responsabilisant.

La promesse du remplacement d’une API par une autre se heurte à la réalité : il faut parfois faire des ajustements et avoir un développeur sous la main pour réaliser la manipulation.

Utiliser des API externes diluent les responsabilités et augmente le nombre d’interlocuteurs. Si l’API X ou Y ne marche pas, il faut voir avec leur support directement. C’est plus pratique d’avoir un contact unique qui s’assure de la responsabilité de l’ensemble.

Enfin, qui dit outils tiers, dit facturation supplémentaire. Comme l’approche cloud / API est inhérente au modèle, la facturation se fait sous forme d’abonnement. On utilise les outils, ils ne nous appartiennent pas.

La souplesse est à ce prix. Concrètement, ce n’est pas pour le petit site du coin. Je commence à voir passer des propositions headless + API first sur des projets à 30k€.

Exemple pour un eCommerce

Concrètement, pour un ecommerce, l’approche Headless + API est tout à fait pertinente pour gérer l’ensemble du métier :

• le PIM et la base produit ;
• l’état du stock, des approvisionnements, des fournisseurs et l’emplacement des produits ;
• la gestion des expéditions, des transporteurs, des retours, des retraits en magasin ;
• l’ERP et les commandes ;
• les paiements, les remboursements ;
• la CRM, la personnalisation, le ciblage et le tracking ;
• les abonnements, paniers, codes de réductions, programmes de fidélité et règles de prix ;
• les programmes de
• le Contenu CMS, la partie éditoriale, les blogs, guides et autres pages à mise en page riche ;
• la recherche interne et les suggestions ;
• la bibliothèque des médias
• les flux pour places de marchés ;
• les campagnes Emailing…

J’ai fait exprès de ne pas citer d’outils. Il y en a toute une liste sur la MachAlliance.

Oui, ça fait beaucoup d’outils. Mais si on compare les approches classiques enfermantes avec leurs propres écosystèmes contraignants ou les approches de type « suite complète » ou on se trouve pieds et poings liés, la contrainte semble finalement mériter réflexion car elle rend de la liberté et de l’agilité. Et ça, c’est un argument très fort pour tous ceux qui ont connu des refontes douloureuses et la sensation de prise d’otages qu’exercent certaines technos ou prestataires.

Photo : The Wandering Angel