vavi.dev : notre avis en 2026

Créer un site rapidement sans coder

Le 1er novembre, le référentiel Qualiopi change. Voici l'application qui le suit, générée en treize minutes. Le problème Un organisme de formation qui prépare son renouvellement Qualiopi travaille presque toujours de la même façine : un tableur partagé, un dossier de preuves quelque part sur un disque, et la mémoire du responsable qualité. Trente-deux indicateurs, sept critères, et pour chacun un document à retrouver, une date à vérifier, une procédure à mettre à jour. Ça tient, tant que rien ne bouge. Or quelque chose bouge. Le décret n° 2026-728 du 1er août 2026, publié au Journal officiel du 4 août, remplace l'annexe qui fixe les indicateurs du Référentiel National Qualité. Le référentiel passe de 32 à 33 indicateurs, sans renumérotation des existants, et une dizaine d'indicateurs sont enrichis. Entrée en vigueur : le 1er novembre 2026. Pour un organisme de formation, ça veut dire relire son dossier de preuves à l'aune d'un texte qui vient de changer, et savoir lesquelles de ses procédures sont touchées. Un tableur ne sait pas faire ça. La demande Nous avons décrit le besoin en un paragraphe, comme le ferait un responsable qualité : Une application métier de pilotage de la certification Qualiopi. Des agents qui lisent le dossier, détectent les écarts, suivent les indicateurs, gèrent les preuves documentaires et surveillent la veille réglementaire. Un tableau de bord qui dit ce qui mérite l'attention aujourd'hui. Pas de spécification technique. Pas de schéma de base. Pas de choix de framework. Ce qui sort Treize minutes plus tard, l'application est générée, compilée et déployée. Neuf tables : organismes, agents, actions, indicateurs, documents, veille, preuves, journal des agents, utilisateurs. Chacune provisionnée avec une colonne propriétaire — les données d'un organisme ne sont jamais visibles par un autre. Ce n'est pas une option activée après coup, c'est le schéma qui l'impose. Huit écrans métier : le tableau de bord du jour, les agents et leur journal, les actions correctives, les indicateurs du référentiel, les preuves documentaires, la veille réglementaire, plus un rapport de préparation à l'audit. Quatre fonctions de domaine calculées : score de préparation, conformité par critère, actions en retard, jours restants avant l'audit. Des calculs purs, dérivés des données réelles, pas des valeurs figées dans le code. Un export complet : docker compose up sur votre propre serveur. Base Postgres, API, frontend, migrations. L'application vous appartient. Le détail qui fait la différence Une application de pilotage avec des « agents » est facile à mettre en scène. Une carte, un pourcentage de confiance, une barre de progression : visuellement, rien ne distingue un agent qui travaille d'un agent qui n'existe pas. Chez nous, l'agent est un moteur réel, écrit une fois et livré avec l'application. Il enchaîne jusqu'à huit itérations, appelle le modèle de langage, et dispose de trois outils exécutés côté serveur : lire des lignes d'une table du dossier, écrire une ligne dans le dossier, calculer. Ces outils ne sont pas des façades. L'agent qui détecte un écart de conformité lit vraiment les indicateurs en base. Celui qui enregistre une action l'écrit vraiment — et toujours pour le compte de l'utilisateur qui l'a lancé, jamais pour un autre. La règle est dans le moteur, pas dans une consigne que le modèle pourrait oublier. L'évaluateur de calcul, lui, n'exécute pas de code : c'est un analyseur arithmétique qui refuse toute expression contenant autre chose que des nombres et des opérateurs. Un agent ne peut pas exécuter n'importe quoi sous couvert de « calculer ». Ce que l'application dit ne pas savoir faire C'est le point sur lequel nous sommes le plus intransigeants. À la livraison, l'application ne se contente pas d'annoncer ce qu'elle fait. Elle publie aussi ce qu'elle ne fait pas : la génération de PDF n'est pas disponible sur ce serveur — dit explicitement, avec la raison ; l'historique des agents n'est pas conservé par cet export — dit explicitement, plutôt qu'une liste vide qu'on prendrait pour une panne ; une capacité déclarée mais non branchée est signalée, nommée, et accompagnée de la marche à suivre. C'est inconfortable à lire. C'est infiniment plus utile qu'un bouton qui tourne trois secondes et affiche un résultat inventé. La plupart des générateurs livrent une interface complète et laissent découvrir les trous en production. Nous préférons livrer une application partielle et déclarée. Un manque annoncé se planifie ; un manque caché se paie devant un auditeur.