La première fois que j’ai rencontré le nom Wized dans ma vie, c’était il y a de ça plusieurs années, la promesse était somptueuse : pouvoir construire des applications web en utilisant Webflow comme solution frontend…
Traduction : Webflow, le meilleur outil au monde pour designer des interfaces, va aussi pouvoir servir d’outil de construction d’applications web avec de la logique 🤯
Cette promesse, surtout à cette époque, sous-entendait qu’il n’allait plus être nécessaire de faire forcément appel à Bubble lorsqu’il serait question de construire des produits un peu plus avancés en matière de logique business.
Parce que le problème avec Bubble, c’est que leur outil de construction d’interfaces est probablement une métaphore élégante de ce que doit être l’enfer pour les gens qui disent pain au chocolat au lieu de chocolatine. J’imagine que ces gens-là doivent être condamnés à designer sur Bubble pour l’éternité.
Toujours est-il que cette promesse m’a forcément fait rêver. Alors sans plus attendre, je dévore toute la documentation de l’outil qui avait été conçu par deux gars aux Etats-Unis, toutes les vidéos youtube qui avaient été faites sur le sujet. Et je commence à no-coder ma première app sur Wized, évidemment, une to-do app comme tout le monde. Jusqu’au moment de faire mes premiers tests en pré-production. Et là… Rien ne fonctionne.
La solution ne marche pas, c’est pas du tout stable, rempli de bug, lent…
Bref, une déception à la hauteur de la promesse.
Ce jour-là, la conclusion pour moi fut que Wized, Softr, etc. sont de jolis jouets pour créer des interfaces pour les enfants powered par un pseudo backend sur Airtable. Et que ça faisait des bons titres pour des vidéos youtube : Créez une app full stack sans lignes de code avec Airtable et Softr !
Mais ça n’était qu’un titre, parce que pour développer de vraies applications métiers qui peuvent être utilisées en production et qui sont vraiment utilisées par des business sérieux pour gagner de l’argent, il allait encore falloir passer par du vrai code. Pas le choix.
Et puis… Et puis un jour tout vint à changer dans l’empire du milieu…
Globalement l’écosystème no-code tout entier a fortement progressé depuis 5 ans (sauf Bubble). De nouvelles solutions performantes pour la création d’applications basées sur des technologies sérieuses comme Flutterflow (basé sur Flutter et dart), Draftbit (basé sur react native), ou plus récemment Weweb qui a vraiment commencé à faire du bruit dans la communauté et qui lui se base sur la framework frontend javascript vue.js.
Plus globalement des génies absolus se sont dits, puisque le problème des technologies nocode c’est que dans une volonté de faire trop simple, trop pour les gens qui n’y connaissent rien en technologies web, on a trop largement perdu en stabilité applicative. Alors pourquoi pas “simplement” prendre le top des technologies web frontend (reactJS et vueJS) et créer des applications qui serviront d’abstractions à ces technologies avec du point and click.
Bien sûr pour conserver la robustesse de développement et par conséquent être capable de créer des applications qui auront vocation à être utilisées en production, on ne peut pas éliminer les concepts de développement web de base que sont les architectures MVC, les protocoles de requêtes et requêtes API, la compartimentation de la gestion de la donnée entre le frontend et le backend, etc. Mais on peut tout de même faire gagner du temps de développement, beaucoup de temps !
Ce qu’il faut comprendre, c’est que ces outils sont faits pour être utilisés par des développeurs, des personnes formées et compétentes qui savent ce qu’elles sont en train de faire. Pas par des gens qui pensent que l’on peut coder des apps entières avec un prompt et les mettre en production sans se soucier à aucun moment de cybersécurité, je ne vise personne 😉
Dans cet élan vers l’avant et surtout vers le progrès de l’écosystème nocode, un acteur a tiré une nouvelle fois son épingle du jeu mais cette fois-ci, indirectement, ou plutôt à travers la communauté qu’il a su se créer.
Et bien sûr il s’agit de Webflow.
Nous avons abordé dans un article précédent comment Webflow et Finsweet ont construit une des plus belles histoires d’amour du 21ème siècle.
Vous pouvez retrouver cet article ici sur comment Finsweet a transformé Webflow.
En effet dans cet article, nous avions abordé le rachat de Wized par Finsweet. Ce rachat fut un moment charnière dans le positionnement de Webflow sur l’industrie des web-app low-code. Et pour l’instant, le pari est réussi.
D’ailleurs, vous vous demandez sans doute à ce stade de l’article ce que signifie l’acronyme WWX ?
Et bien les deux premiers W signifient tout simplement : Webflow, Wized.
Et pour ce qui est du X, on y reviendra un peu plus tard 🤫
Nous avons déjà longuement disserté sur le sujet de Webflow sur l’ensemble du blog d’Octolio, nous n’allons pas revenir trop en détails sur cela ici.
Si vous venez de découvrir notre super blog, ou si vous n’êtes pas encore très à l’aise sur ce qu’est Webflow et ce que cet outil permet de faire, nous vous conseillons les articles suivants :
En deux mots toutefois, et parce que c’est nécessaire pour comprendre la suite :
Webflow est un éditeur de développement visuel ; donc une abstraction de code HTML et CSS, permettant de créer des sites web, mais plus globalement permettant de designer avec grande précision et simplicité (pour ceux qui savent s’en servir) des interfaces. Et c’est exactement dans ce contexte-là qu’on va s’en servir dans le cadre de la stack WWX.
Bon, avant d’aller plus loin, ce serait bien de faire quelques rappels sur comment fonctionnent le développement web et les technologies web plus globalement pour bien comprendre ce qui viendra ensuite.
Si vous êtes déjà développeur, vous pouvez passer directement à la partie suivante et pour ceux que ça intéresse, c’est parti !
Aujourd’hui, lorsque l’on parle de développement web, on comprend deux grandes catégories de produits :
Et puisqu’on parle de web, on va aussi faire la distinction avec les applications mobile et desktop, qui sont globalement les deux faces d’une même pièce, mais qui consiste à développer des applications qui vont tourner directement sur la machine de l’utilisateur (téléphone ou ordinateur) contrairement aux applications web qui, quant à elles ne sont accessibles qu’à travers un navigateur, et vont donc exister sur les serveurs de l’entreprise qui développe les applications en question.
Ces précisions sont importantes pour parvenir à saisir la différence entre un site et une application.
Et je devrais aussi préciser, une application du web 2. Car si on commence à parler de web 3, cela va complexifier encore plus les explications, alors tenons-nous en au web 2 🙂
La différence fondamentale que l’on retrouve entre un site classique et une application est qu’un site (dans une certaine mesure) n’a vocation qu’à afficher de la donnée.
Par exemple, un blog affiche des articles.
Un portfolio affiche des réalisations.
Un site e-commerce affiche des produits en vente.
Et l’utilisateur ne peut pas vraiment interagir avec cette donnée. Il ne peut que la consulter.
Bien sûr dans le cadre d’un site e-commerce, il peut passer commande et donc interagir avec la donnée du site mais simplifions si vous le voulez bien 🙂
La différence avec une application web, prenons un exemple qui va parler à tout le monde : Facebook. (Boom les boomers)
C’est que l’utilisateur peut interagir avec la donnée de facebook, la consulter bien sûr, mais aussi en créer. Par exemple, il peut créer un compte, mettre à jour ses statuts, poster des photos et des commentaires, mais aussi les supprimer, etc.
C’est cette différence fondamentale qui distingue un simple site d’une application.
Une application doit pouvoir laisser la possibilité à son utilisateur d’interagir avec sa donnée. Et bien sûr, pour que cette application soit utile pour l’utilisateur et donc pour qu’elle puisse exister économiquement, il faut aussi qu’elle permette de faire quelque chose d’utile, qui va faciliter la vie de son utilisateur grâce aux programmes informatiques qu’elle développe.
Pour ce faire, on va vraiment avoir besoin de quatre ingrédients. Quatre termes que vous avez certainement déjà entendu et qui peuvent faire peur au premier abord (moi je me rappelle que ça me faisait peur quand j’ai commencé à apprendre à coder, ne me jugez pas)
Ok je préviens, on va vulgariser, et on va aussi utiliser l’analogie de restaurant puisque c’est la plus parlante, surtout si vous êtes déjà allé dîner dans un restaurant !
Le frontend, c’est l’équivalent de la salle, c’est convivial, chaleureux, un endroit où vous êtes censé avoir vos repères, qui doit vous mettre à l’aise pour vous faire passer un moment agréable.
Sur le web, la salle de restaurant ça s’appelle l’interface utilisateur, mais puisqu’on aime bien parler en anglais sur le web on dit plutôt “User Interface”, et puisqu’on aime bien les acronymes sur le web on dit plutôt : UI.
Et ça, je suis sûr que vous avez déjà vu passer ce mot UI, sûrement sur des offres d’emplois qui cherchent des designers UI / UX 😉
Le backend, dans notre analogie, c’est la cuisine. C’est là que la magie opère pour satisfaire le client. Et la magie dans une application, c’est sa logique. La logique lourde d’une application, celle qui enregistre traite, manipule, ordonne, et transforme de la donnée. C’est ça qui nous est utile.
Lorsque j’utilise une application CRM et que je mets en place des automatisations pour telle ou telle tâche. Ces automatisations sont le résultat d’un programme informatique qui manipule de la donnée. Et ces manipulations se font au niveau du backend. Souvent sur le cloud de l’entreprise qui commercialise l’application. Pour que vous, le client, n’ait à se soucier de rien.
Maintenant une API… Bon, c’est là qu’on va vulgariser un peu parce qu’une API n’est pas exactement ce que je m’apprête à expliquer mais dans un souci de simplicité je vous demande de me croire.
Ou alors on rentre vraiment dans le détail de ce qu’est une interface en programmation orientée objet ? Hmmmm, oui je me disais bien 😛
Donc dans notre exemple, on va considérer qu’une API c’est le serveur du restaurant.
Celui qui fait le lien entre la commande du client en salle, et la production des plats en cuisine.
Il permet de récolter la demande faite par le frontend, “traduire” la demande dans un langage compréhensible par le backend, afin que ce dernier fasse son travail, et retourne si nécessaire un résultat au frontend pour qu’il puisse être affiché à l’utilisateur.
Bon la réalité pour les puristes c’est que ce sont les requêtes HTTP qui font ce travail, mais ça se fait grâce à l’utilisation d’une API ; c’est pour ça qu’on se permet ce petit abus de langage.
Enfin la base de données, le meilleur pour la fin. Finalement son nom est assez explicite. La base de données, c’est là qu’est stockée toute la donnée de l’application et qui sera utile à l’expérience de l’utilisateur. Toutefois comme on l’aura compris, tant pour des raisons de sécurité que de gestion de la complexité (en tout cas si on souhaite développer une app sérieuse), ces bases de données ne doivent être accessibles qu’à travers un backend prévu à cet effet. Et pas directement depuis le frontend.
Petite note supplémentaire pour ceux que ça intéresse. La différence fondamentale entre le web 2 et le web 3 se fait justement au niveau de la base de données. Là où le web 2 utilise des DB centralisées stockées sur les serveurs de l’entreprise qui commercialise l’application. Quant aux applications de web 3, elles utilisent un tout nouveau système de stockage de la donnée qui s’appelle la blockchain 🙂 Mais ne nous éloignons pas trop de notre sujet !
Maintenant que nous avons un peu mieux expliqué les tenants et les aboutissants du développement d’applications web, revenons si vous le voulez bien au sujet qui nous intéresse, pourquoi WWX est la stack du futur ?
Nous avons déjà mentionné que Webflow dans ce contexte est un outil donc de création d’interface utilisateur, et probablement le meilleur.
Mais Webflow est un outil qui permet d’afficher de la donnée, sous forme de site internet. En revanche, il ne dispose nativement de presqu’aucune manière de créer la bidirectionnalité des interactions. A savoir que l’utilisateur puisse interagir avec la donnée qui l’intéresse, ou dit autrement qu’il puisse interagir avec un backend.
Dans notre stack, pouvoir interagir depuis une interface avec un backend : ça, c’est le rôle de Wized.
Pour le dire simplement, Wazed est un framework conçu comme une sur-couche pour Webflow qui permet de rajouter de l’interactivité aux interfaces designées sur Webflow.
Ça semble magique ? Franchement ça l’est presque. Mais c’est là la beauté de l’informatique, lorsque de bons développeurs et de belles entreprises sont à l’œuvre, ça a l’air magique…
En fait c’est simple, on installe un script sur le projet Webflow et… Et voilà c’est fini, juste ça fonctionne.
Alors bien sûr, encore faut-il développer la logique frontend de notre application. Mais globalement, transformer une interface Webflow en une web app c’est aussi simple qu’installer une simple librairie javascript dans la balise <head> de son site.
Ensuite, comment ça marche ? Je pense sincèrement commencer prochainement à documenter certaines de nos réalisations en WWX pour rentrer davantage dans le détail des choses à connaître pour utiliser cette stack. Mais dans le cadre de cet article, restons sur des concepts simples.
Je voudrais commencer par introduire trois notions fondamentales pour l’utilisation de Wized et plus globalement dans le cadre du développement web :
Les requêtes sont, comme nous l’avons évoqué précédemment, le point de contact entre le frontend et le backend.
Pour utiliser les capacités de Wized, il va être nécessaire de créer des requêtes, qui peuvent aller du backend vers le frontend, ou inversement, mais aussi du frontend vers ailleurs, ou d’ailleurs vers le frontend, bref. C’est au niveau des requêtes que l’on va pouvoir spécifier les routes des API dont on va avoir besoin au fonctionnement de l’application. Et comme nous venons de l’évoquer, cela peut soit permettre de récupérer de la donnée venant d’ailleurs pour l’afficher sur l’interface, soit envoyer de la donnée depuis l’interface vers un backend.
Les variables de Wized, comme leur nom l’indique, permettent de conserver de la donnée réutilisable et dynamique. Wized propose d’ailleurs la possibilité d’en créer de différents types pour convenir aux besoins de l’application. Parmi ces types, on va principalement retrouver :
Je voudrais revenir davantage sur les variables classiques. En effet, la documentation de Wized nous incite à créer une variable pour chaque élément dynamique que l’on souhaite bind sur notre application.
Par exemple, si l’on souhaite charger un contenu dynamiquement sur une page pour afficher un titre, une image et un paragraphe en fonction d’un paramètre d’URL, cela impliquerait de créer trois variables (classiques) différentes. Personnellement, je n’aime pas cette approche qui finit rapidement par causer des problèmes de maintenabilité de l’application au fur et à mesure que le nombre de variables nécessaires grandit. Une des faiblesses de Wized étant qu’il n’est pas possible d’organiser ses variables par folder.
Une technique qui fonctionne bien pour contourner ce problème est de réutiliser la même notion de contexte qu’en reactJS. On vient créer une variable contexte initialisée à null. Et lors de chaque chargement de page, on peut alors venir initialiser la donnée relative à la page en question en utilisant la variable contexte comme un objet.
Ainsi, on s’économise le besoin de créer une variable différente pour chaque élément dynamique de l’application. Une seule variable objet est nécessaire au sein de laquelle on vient stocker autant de propriétés et donc de données que l’on souhaite. Il ne reste alors plus qu’à y faire appel sur son front-end. Et de la même manière, il est possible de créer des variables objets persistantes dans le session ou dans le local storage pour faire persister de la donnée au cours de sa navigation.
Enfin, il nous reste à parler des éléments.
Wized fonctionne en utilisant le concept d’attribut HTML. Pour chaque élément HTML que l’on souhaite pouvoir utiliser dans Wized, il faudra venir lui attacher un attribut HTML wized=”element-name”. Ainsi, le nom que vous donnerez à l’élément sera disponible pour être utilisé dans Wized et lui attacher de la logique.
Le concept est donc simple, on vient designer les éléments graphiques de notre interface dans Webflow. On bind ces éléments pour pouvoir les manipuler dans l’embed de wized. Puis on crée la logique frontend de notre application grâce à l’interface point and click de Wized.
Pro tips cependant, il est bien sûr possible de créer sa logique frontend enutilisant du javascript. Et je ne saurais vous conseiller suffisamment de le faire ! En effet, développer son application en utilisant du javascript que ce soit pour les fonctions, les actions, etc. force à la réfléchir comme un “vrai” développeur le ferait et donc à adopter une logique de développement robuste.
Xano est en quelque sorte le chef d’orchestre, celui qui rend tout possible. Celui sans qui, tout le reste serait sans saveur.
Comme nous l’avons évoqué, jusque là Webflow et Wized servent à développer le frontend. Cependant, un frontend ne serait qu’une coquille vide sans le backend derrière permettant de gérer la logique et la donnée de l’utilisateur.
Et c’est exactement ce que se propose de faire Xano.
Toutefois, cet article n’est pas un tuto complet du fonctionnement de Xano. Il y a deux catégories de personnes qui liront cet article, surtout jusqu’ici 😛 : les développeurs qui iront chercher les informations par eux-mêmes, et les potentiels futurs clients qui n’ont globalement pas grand chose à faire de savoir comment ça fonctionne !
Du coup plutôt que de parler de ça, je voudrais revenir sur les possibilités qu’offre Xano en matière de développement.
Xano permet de créer un backend en développant visuellement sa propre API, tout en interagissant avec une base de données directement hébergée sur la plateforme. Et oui, plus besoin d’apprendre à utiliser un service de base de données externe !
Mais ce qu’il faut également mentionner, c’est la direction orientée IA prise par Xano en 2025.
L’outil offre désormais la possibilité de développer ses propres agents IA qui peuvent donc être connectés à des outils directement liés à la logique interne de son entreprise, dans son propre backend. Par conséquent, interagir directement et avec beaucoup de simplicité avec sa propre donnée. ET DONC, très logiquement, cela permet de créer ses propres serveurs MCP avec la même simplicité qu’avec laquelle on pouvait créer des APIs jusqu’à présent. Cela signifie que dans un futur qui se fait de plus en plus proche, vos utilisateurs pourront discuter avec votre application au lieu d’avoir besoin d’interagir avec elle… Je vous laisse libre d’imaginer l’infinité des possibles que cela offre !
Un autre secteur dans lequel Xano est pionnier, et il y a fort à parier que la plupart des outils de développement no code / low code vont s’y mettre également, c’est dans tout ce qui touche aux fonctionnalités de vibe coding.
Tout le monde a entendu parler de ce terme, mais jusqu’à présent il était davantage limité aux outils conçus spécifiquement pour comme Bolt, Lovable et consorts. Ou bien pour les plus avancés d’entre nous, à l’utilisation d’IDE spécialisé dans ce domaine comme Cursor ou Windsurf.
Cependant jusqu’à récemment la facilité de développement qu’offrait un prompt se limitait à s’exécuter avec du code, et bien souvent fait par des gens qui ne comprennent rien à comment ce code fonctionne. Les interfaces de programmation visuelle comme Webflow, quant à elle, nécessitait toujours qu’un développeur aille lui-même avec ses petites mains positionner tous les blocs un par un - parce que même si une IA pouvait lui expliquer quoi faire, aucune IA ne pouvait le faire à sa place. Et puis tout changea.
En tout cas dans Xano. Désormais l’outil dispose d’un assistant qui peut être prompté avec beaucoup de simplicité et il va alors s’occuper de réaliser et construire le back-end tel que le prompt le demande sans que le développeur n’ait à faire quoi que ce soit à part, bien sûr, vérifier la qualité du travail qu’a fait l’IA.
Oui messieurs, dames, ceci est une révolution.
Allier la vitesse de développement et d’itération qu’offrent les outils low-code avec la rapidité d’exécution qu’offrent les IA, c’est une révolution.
Cependant, cette révolution laisse à penser que la barrière à l’entrée pour créer des logiciels, qui était déjà basse, vient encore de s’abaisser davantage.
Il ne serait pas étonnant de voir durant les mois et années à venir une recrudescence du nombre d’applications apparaître et donc, d’une certaine manière, un phénomène de bulle. Et comme pour tout phénomène de bulle, il va s’opérer une course vers la qualité. Puisque le nombre d’applications va exploser, la loi de l’évolution de Darwin nous garantit qu’il ne restera à la fin que les plus aboutis et les mieux conçus. Et ce constat est très enthousiasmant. Au lieu de penser que les développeurs vont disparaitre, remplacés par des IA, on peut raisonnablement penser qu’ils seront plutôt augmentés par IA, capables de créer des applications performantes et vont donc devenir irremplaçables.
Et cela présage de beaux jours pour la création de valeur sur internet.
