Nibblify est une plateforme de livraison complète : une application client, une application restaurant, une application livreur, une console d'exploitation, un backend et un site en 10 langues. Le tout a été construit par une seule personne, épaulée par des modèles d'IA de pointe. Nous appelons cette méthode le vibe engineering.
Le vibe engineering, ce n'est pas « laisser l'IA écrire et croiser les doigts ». C'est une répartition des rôles : l'humain porte l'intention, l'architecture et la décision finale ; les modèles portent la frappe, la mémoire et le premier jet ; et le dépôt lui-même porte la preuve — des tests, des validateurs et des vérifications à la compilation qui protestent bruyamment dès que quelque chose dérive.
Chaque fonctionnalité commence par une décision, pas par un prompt : ce qu'elle doit faire, quelles données elle touche, ce qu'elle ne doit jamais casser. L'architecture, le modèle de données et les arbitrages restent humains. On ne demande jamais aux modèles quoi construire — seulement comment construire ce qui a déjà été décidé.
Écrans, contrôleurs, migrations de données, traductions, tests : la première version arrive en minutes plutôt qu'en jours. Et elle est traitée pour ce qu'elle est — un brouillon, lu ligne par ligne, réécrit là où il se trompe, et purement et simplement jeté quand il passe à côté du sujet.
Rien n'est livré au feeling. 296 fichiers de tests, des suites sur les règles de sécurité, un vérificateur de clés i18n, un audit des métadonnées SEO et un validateur de réciprocité des liens tournent sur le code. Quand du code écrit par une IA est faux, une machine le dit bien avant un utilisateur.
Chaque dépôt porte son propre guide d'architecture — une carte vivante de sa structure, de ses conventions et de ses pièges. Les modèles commencent chaque session en connaissant déjà le code, et c'est précisément ce qui les fait passer de l'autocomplétion à la véritable collaboration.
Chaque modèle a été utilisé là où il est le meilleur — et contrôlé par les autres là où il ne l'est pas.
Réflexion produit, choix des noms, textes destinés aux utilisateurs et longues discussions sur ce qu'une fonctionnalité doit vraiment être. La plupart des écrans de Nibblify ont existé sous forme de conversation bien avant d'exister sous forme de code.
Recherche large sur les API, les règles des plateformes et les politiques des stores, plus une lecture indépendante des designs et du code produits par les autres modèles. Quand deux modèles n'étaient pas d'accord, le désaccord lui-même était le signal utile.
Il travaille directement dans les dépôts : il lit tout le code, écrit et refactorise à travers des centaines de fichiers, lance les suites de tests, répare ce qu'il a cassé et commite. C'est de là que vient l'essentiel des 300 000 lignes.
Les quatre applications partagent un seul langage et une seule boîte à outils d'interface : iOS, Android et le web sortent d'une base de code unique. Flutter avec Riverpod, Provider et go_router, sur Dart 3.10.
Node.js sur Firebase Cloud Functions gère les commandes, les versements, l'attribution des livreurs, le chiffrement AES-256 des données personnelles, les exports RGPD, les notifications push et toute l'API d'administration.
Auth, Firestore, Storage, Messaging, Remote Config, App Check, Crashlytics et Analytics — avec des règles de sécurité écrites à la main qui protègent chaque collection. La base de données est le contrat entre les quatre applications.
Ce site est écrit à la main en HTML et CSS avec Tailwind, compilé par un build Node qui rend chaque page en 10 langues et génère lui-même les balises hreflang, les données structurées, le sitemap et les variantes d'images.
Mesuré le 2 août 2026. Les dépendances et les fichiers générés automatiquement sont exclus : ce sont des lignes réellement écrites pour Nibblify.
L'application client : découverte, exploration sur carte, recherche tolérante aux fautes de frappe, panier, paiement, suivi de commande en direct, avis et compte. Version 1.0.127, livrée en 10 langues.
L'application restaurant : menus, offres, horaires d'ouverture, flux de commandes en direct, gestion d'équipe, versements et programme créateurs. Version 1.0.74, livrée en 10 langues.
L'application livreur : prise de service, navigation en course, preuve de livraison, revenus et portefeuille. Version 1.0.45, conçue pour rester légère sur les téléphones d'entrée de gamme que les livreurs ont vraiment en poche.
La console d'exploitation interne : vérification des restaurants, documents et portefeuilles des livreurs, support des commandes, cartes en direct, analytics et supervision — avec 102 Cloud Functions réservées à l'administration.
Cloud Functions, déclencheurs Firestore et tâches planifiées, plus 1 119 lignes de règles de sécurité Firestore et Storage couvrant 47 collections.
296 fichiers de tests Dart, plus des suites d'intégration sur émulateur et des tests des règles de sécurité. C'est le filet de sécurité qui rend livrable du code écrit par une IA.
26 fichiers de langue pour les applications et 10 dictionnaires pour le site, qui se déploient en 154 700 lignes de Dart générées. L'arabe est livré avec une vraie mise en page de droite à gauche, pas un simple miroir ajouté après coup.
20 pages sources rendues en 200 pages statiques localisées par un build Node maison — sans framework, et moins de 250 lignes de JavaScript qui atteignent le navigateur.
En comptant le code de localisation généré à partir de ces traductions, les dépôts totalisent environ 463 000 lignes.
Chaque dépôt documente sa propre architecture : le modèle sait comment fonctionne ce code avant d'en écrire la moindre ligne.
2 456 commits, pas cinquante. Chaque changement est assez petit pour être lu intégralement par un humain avant d'être intégré.
Tests, parité des clés de traduction, audits des métadonnées SEO et suites sur les règles de sécurité tournent sur chaque changement.
255 builds publiés sur les stores pour les quatre applications, avec rapports de crash et analytics pour nous dire ce qui s'est réellement passé.
« Les modèles n'ont pas remplacé l'ingénierie. Ils ont supprimé la frappe. Ce qui reste, c'est la partie qui a toujours été la plus dure : décider quoi construire, et être certain que ça fonctionne. »
Nibblify Food démarre comme un simple projet Flutter adossé à un backend Firebase.
Nibblify Partner démarre, et le projet cesse d'être une application pour devenir un système.
Un build statique maison rend le site en 10 langues, avec hreflang, données structurées et audits SEO page par page.
Nibblify Driver, le Staff Portal et un dépôt backend partagé démarrent tous en l'espace de trois semaines.
La plateforme entre dans un pilote à l'échelle de la ville et arrive au Mans testée, pas théorique.
Voir le partenariat →