Création d'une page complexe avec un backend - Emergent
Comment une idée se transforme-t-elle en une véritable plateforme ? Dans cet article, je décris comment j'ai développé Foodopia avec Emergent, quels sont les avantages du développement assisté par IA au quotidien et pourquoi la compréhension technique reste malgré tout cruciale.
Lorsque j'ai commencé avec Foodopia, l'idée était encore beaucoup plus simple que ce qu'elle est devenue aujourd'hui.
Je voulais construire une plateforme où les petits producteurs, les jardiniers amateurs ou les personnes qui fabriquent des aliments chez eux pourraient proposer leurs produits directement dans leur environnement.
L'idée sous-jacente était en fait assez simple : il y a beaucoup de gens qui produisent des œufs, des fruits, des légumes, du miel ou d'autres aliments et qui en ont parfois plus que ce dont ils ont besoin. En même temps, souvent à quelques kilomètres seulement, vivent des personnes qui aimeraient acheter de tels produits localement, mais qui ignorent leur existence.
C'est précisément ces deux parties que je voulais réunir avec Foodopia.
Une grande partie de la plateforme a été créée avec Emergent.
Pourquoi j'ai utilisé Emergent pour Foodopia
Je viens moi-même du développement logiciel et j'ai travaillé pendant plusieurs années de manière classique sur des backends Java, des API, des systèmes cloud et des projets d'entreprise plus importants.
Normalement, pour un nouveau projet, je commencerais assez rapidement à réfléchir aux modèles de données, à la structure du backend, aux API, aux composants frontend et au déploiement.
Pour Foodopia, les choses se sont déroulées un peu différemment.
J'ai pu d'abord simplement expliquer à Emergent ce que je voulais réellement construire.
Par exemple :
Un producteur doit pouvoir publier un produit, choisir un ou plusieurs lieux de retrait et définir des créneaux horaires pendant lesquels les clients peuvent récupérer leur commande.
À partir de cette description, une implémentation fonctionnelle a pu être créée assez rapidement.
Ce qui était intéressant pour moi, ce n'était pas tant de ne pas avoir à écrire de code. Bien plus important était le fait que je pouvais tester très rapidement si mon idée était pertinente.
Une petite idée est rapidement devenue un système plus vaste
Comme pour de nombreux projets logiciels, les exigences réelles n'ont émergé qu'au cours du développement.
Un producteur n'a pas seulement besoin d'un formulaire de produit.
Il a besoin d'un profil, de quantités disponibles, de prix, de taux de TVA, de lieux de retrait et d'horaires de retrait.
Ensuite, la question s'est posée de savoir si les réservations devaient être confirmées automatiquement ou si le producteur voulait confirmer chaque réservation lui-même.
Ensuite sont apparues les Pickup Locations. L'idée est que, par exemple, un magasin puisse servir de point de retrait pour plusieurs producteurs et percevoir une petite commission pour cela.
Plus tard, les paiements via Stripe Connect ont été ajoutés.
Cela a rendu l'ensemble nettement plus complexe, car soudain, non seulement l'UI et la base de données étaient pertinentes, mais aussi les flux de paiement, les frais de plateforme, les comptes de producteurs, les webhooks et les décaissements.
C'est précisément sur de tels sujets que l'on réalise assez vite que le développement par IA ne signifie pas simplement :
"Écris-moi une plateforme."
Plus les systèmes sont interconnectés, plus il devient important de comprendre soi-même ce qui se passe en arrière-plan.
Le modèle économique a changé pendant le développement
Au début, Foodopia ne ressemblait pas à ce qu'il est aujourd'hui.
Une idée antérieure était de travailler davantage avec nos propres hubs et notre logistique.
Plus je m'y suis penché, moins il m'a semblé judicieux de faire de Foodopia une entreprise de logistique à part entière.
Aujourd'hui, l'idée est beaucoup plus claire :
Foodopia fournit la plateforme.
Les producteurs décident eux-mêmes où et quand leurs produits peuvent être retirés. Ils peuvent utiliser leur propre emplacement ou collaborer avec des Pickup Locations.
Ce changement n'était pas seulement une décision commerciale. Il a bien sûr eu des répercussions sur le logiciel.
Avec Emergent, j'ai pu implémenter de tels changements relativement rapidement et essayer différentes variantes.
C'est pour moi l'un des plus grands avantages de ce type de développement.
Surtout avec un nouveau produit, on ne sait pas tout au début.
On ne comprend beaucoup de choses qu'une fois qu'on les a réellement construites.
Foodopia ne devait jamais être qu'une simple place de marché
Un aspect qui m'a toujours tenu à cœur avec Foodopia, c'est la communauté.
Je trouve dommage qu'aujourd'hui, les aliments soient souvent devenus complètement anonymes.
On achète des tomates, des œufs ou du miel sans savoir qui est derrière ou comment ils ont été produits.
C'est pourquoi Foodopia comprend également une section sociale.
Les producteurs peuvent par exemple montrer ce qui se passe dans leur jardin ou leur ferme, partager des photos de leur récolte, créer des événements ou former des groupes.
Cela ne doit pas toujours être de la publicité.
Une photo de poussins fraîchement éclos, d'un figuier ou de la première récolte de tomates peut être tout aussi intéressante.
Je veux que les gens retrouvent un peu plus de lien avec l'origine de leurs aliments.
Où Emergent fonctionne très bien
Ce que j'apprécie particulièrement, c'est la rapidité.
Je peux décrire une idée et voir relativement vite comment elle se concrétise sur la plateforme.
Si quelque chose ne convient pas, je le modifie.
Si une fonction est devenue inutilement compliquée, je peux la simplifier à nouveau.
Si une meilleure solution me vient à l'esprit pendant les tests, je n'ai pas besoin de prévoir plusieurs jours de développement.
Le processus de développement est ainsi devenu beaucoup plus itératif.
Souvent, cela se déroule à peu près comme ça :
Idée → Prompt → Implémentation → Test → Correction → Adaptation
Parfois, je travaille avec des descriptions textuelles, parfois avec des captures d'écran.
Surtout pour les problèmes d'UI, il est très pratique de simplement montrer une capture d'écran et d'expliquer précisément ce qui me dérange.
Il faut quand même savoir ce que l'on fait
Je ne crois pas que des outils comme Emergent rendent les connaissances techniques superflues.
Plutôt le contraire.
Si l'IA peut générer du logiciel très rapidement, quelqu'un doit être capable de juger si le résultat est pertinent.
Pour Foodopia, cela concerne par exemple :
- Stripe et les flux de paiement
- Authentification et autorisations
- Modifications de la base de données
- Webhooks
- SEO
- Sitemap et Google Search Console
- TVA
- Processus de facturation
- Protection des données
- Exigences différentes dans divers pays de l'UE
Pour des ajustements simples de l'UI, on peut expérimenter assez librement.
Mais pour la logique de paiement ou les fonctions critiques pour la sécurité, je veux comprendre précisément ce qui se passe.
L'IA peut construire quelque chose très rapidement.
Mais cela ne signifie pas automatiquement que la solution est correcte.
Mon rôle en tant que développeur change
C'est probablement la partie la plus intéressante pour moi.
Auparavant, une grande partie de mon travail consistait à traduire moi-même les exigences en code.
Aujourd'hui, sur des projets comme Foodopia, je passe beaucoup plus de temps à définir les bonnes exigences.
Je réfléchis davantage à :
- Comment un processus doit-il réellement fonctionner ?
- Qu'est-ce que l'utilisateur a vraiment besoin ?
- Quels sont les cas particuliers ?
- Quelle fonction peut être simplifiée ?
- Quels sont les impacts d'un changement sur d'autres parties de la plateforme ?
L'accent se déplace un peu de la simple écriture de code vers l'architecture, la pensée produit, les tests et la revue.
Cela ne signifie pas que la programmation devient sans importance.
Mais la manière dont le logiciel est créé change.
Combien le développement m'a-t-il coûté jusqu'à présent ?
Un point souvent négligé dans le développement assisté par IA, ce sont les coûts récurrents.
Emergent fonctionne avec un système de crédits. Selon le forfait acheté, le prix effectif par crédit varie légèrement.
Au moment de mon utilisation, les prix étaient approximativement les suivants :
| Crédits | Prix |
|---|---|
| 100 | 20 $ |
| 250 | 50 $ |
| 500 | 100 $ |
| 1.250 | 250 $ |
| 3.000 | 500 $ |
| 6.000 | 1.000 $ |
J'ai généralement acheté le pack de 1 250 crédits pour 250 $. Entre-temps, il y a aussi eu des packs plus petits pour 50 $ et occasionnellement le pack de 3 000 crédits pour 500 $.
Pour le développement de Foodopia, environ 8 066,53 crédits ont été consommés jusqu'à présent.
Si l'on calcule ces crédits avec les packs normaux à environ 0,20 $ par crédit, cela correspond approximativement à :
8 066,53 × 0,20 $ = 1 613,31 $
Étant donné que les packs plus importants sont un peu moins chers, le montant effectif réel est légèrement inférieur en fonction de la combinaison achetée. De manière réaliste, la consommation de développement jusqu'à présent correspond donc à environ 1 350 $ à 1 600 $.
Ce n'est cependant pas exactement la même chose que mes dépôts totaux, car les crédits achetés peuvent bien sûr également rester sur le compte.
Coûts de backend récurrents
En plus du développement lui-même, des coûts récurrents sont engendrés pour l'hébergement ou le backend.
Actuellement, le backend de Foodopia me coûte :
50 crédits par mois
Au prix normal du crédit, cela correspond à environ 10 $ par mois.
Pour moi, c'est une comparaison intéressante avec le développement logiciel classique. Environ 1 500 $ représentent bien sûr de l'argent, mais en même temps, cela a donné naissance à une plateforme avec une place de marché, une gestion des producteurs, des réservations, des paiements, des fonctionnalités communautaires et diverses intégrations externes.
Si j'avais fait développer ces fonctions entièrement en externe, les coûts auraient très probablement atteint un ordre de grandeur complètement différent.
Néanmoins, le développement par IA ne doit pas être considéré comme un "développement logiciel gratuit". Surtout lorsque l'on expérimente beaucoup, que l'on développe de nouvelles fonctions ou que l'on retravaille plusieurs fois des solutions existantes, les crédits peuvent être consommés assez rapidement.
Le grand avantage pour moi réside donc moins dans le fait que le développement devienne soudainement gratuit, mais plutôt dans le fait que je peux expérimenter, tester et construire une véritable plateforme très rapidement pour un coût relativement faible.
Foodopia est loin d'être terminé
Foodopia reste un jeune projet.
Il y a beaucoup de choses qui vont probablement encore changer.
Surtout lorsque davantage de producteurs utiliseront la plateforme, des exigences auxquelles je ne pense pas encore aujourd'hui apparaîtront probablement.
Et c'est précisément pourquoi ce type de développement convient très bien au projet.
Je peux prendre en compte les retours, essayer de nouvelles idées et modifier les fonctionnalités sans que cela ne devienne à chaque fois un cycle de développement gigantesque.
Foodopia a été lancé au Portugal, mais à long terme, la plateforme devrait également fonctionner dans d'autres pays européens.
Pour cela, certaines questions techniques et juridiques doivent encore être résolues.
Mais le cœur de l'idée reste en fait très simple :
Les aliments locaux devraient être plus faciles à trouver.
Et les aliments qui ont déjà été produits ne devraient si possible pas être jetés, simplement parce que personne ne sait qu'ils sont disponibles.
Avec Emergent, j'ai pu transformer cette idée en une véritable plateforme assez rapidement.
Maintenant commence pour moi la partie la plus excitante : découvrir comment les gens utilisent réellement Foodopia.