Ce que le produit final est devenu : bilan et prochaines étapes (partie 3/3)

La partie 1 décrivait ce qui était prévu. La partie 2 décrivait ce qui a changé en cours de route. Cette troisième partie décrit ce qui existe aujourd’hui : un outil qui fonctionne en production, une architecture qui couvre plus que le périmètre initial et quelques chantiers ouverts que je n’ai pas fermés volontairement.

Ce qui est en production

Le workflow complet est opérationnel. Un prospect remplit le formulaire sur oguhnas.fr/diagnostics/serenite , reçoit son rapport PDF par email et son contact est créé dans la gestion de relation client avec le PDF attaché. Le délai entre la soumission et la réception du mail est inférieur à 10 minutes, souvent inférieur à 5.

Le formulaire est un stepper en 8 écrans, servi par une page dédiée du site vitrine. Il charge les questions depuis la base de données au moment de l’affichage et soumet les réponses directement vers le back-office. Ce choix d’architecture évite un backend supplémentaire sur un site statique et donne une maîtrise complète sur la mise en page et le séquençage des questions.

Le moteur de traitement, côté automate, lit aussi entièrement sa configuration depuis la base de données, à chaque exécution. Aucune logique de scoring n’est écrite en dur dans le code. Les règles d’évaluation des flags, les poids des questions, les seuils de priorité, le template HTML du rapport : tout est en base de données, modifiable sans toucher au code.

Pas besoin de purge RGPD, aucune donnée personnelle n’est enregistrée en dehors du CRM. Ce qui est stocké (scores, flags contextuels, résumé) ne contient aucune donnée permettant d’identifier le prospect.

Premières évolutions après les retours utilisateurs

Les premiers retours ont permis d’affiner le formulaire sur deux points, sans modification du code.

Le découpage de la taille d’entreprise a été précisé. La tranche 1-10 salariés, initialement traitée comme un seul groupe, a été divisée en trois sous-groupes : 1-2, 3-5, et 6-10. Les problématiques diffèrent suffisamment entre un dirigeant seul et une petite équipe de six à dix personnes pour justifier des parcours distincts.

L’ordre des questions a été inversé. Les questions de contexte (taille, secteur, présence ou non d’une ressource IT) passent en premier. L’outil peut ainsi filtrer et adapter les questions suivantes au profil de l’entreprise, en ne présentant que celles qui sont pertinentes et dans une formulation ajustée selon la taille. Les libellés de certaines questions varient désormais selon le segment.

Ces deux évolutions ont représenté un effort réduit. Comme aucune logique n’était écrite en dur, il a suffi de modifier les données en base via l’interface d’administration : ajout de segments, réordonnancement des questions, variantes de libellés. L’architecture a absorbé ces changements sans friction.

L’application admin

L’application admin n’était pas dans le périmètre initial. Elle a été construite parce que son intérêt est apparu pendant le développement (cela permet d’automatiser la rédaction de rapports d’audits clients, beaucoup plus vastes et qui n’ont pas d’intérêt à être accessibles depuis le site vitrine).

C’est une application web (Alpine.js), servie statiquement par le backend de base de données (Pocketbase, qui gère aussi l’authentification) avec deux modules.

Le premier est un stepper de diagnostic interne. Il reproduit l’expérience du formulaire public, mais avec quelques différences : les soumissions sont marquées comme internes, l’email part en copie interne uniquement et les brouillons sont sauvegardés automatiquement à chaque réponse. Si la page est rechargée en cours de saisie, une bannière propose de reprendre là où on en était.

Le second est un module de paramétrage complet. Il couvre 8 onglets : Utilisateurs, Audits, Options questions, Questions, Actions, Flags, Modificateurs, Variables template. Chaque onglet permet de paramétrer tous les champs correspondants de la table dans la base de données. Modifier une question, ajuster un poids, changer une action recommandée ou téléverser un nouveau template HTML : tout se fait depuis cette interface, sans accès direct à la base de données.

Ce module de paramétrage est aussi ce qui rend l’architecture extensible. Créer un second audit revient à ouvrir l’onglet Audits, remplir un formulaire, puis alimenter les onglets associés. Aucune modification nécessaire sur le reste de l’application.

Ce que l’architecture permet maintenant

Le moteur est générique. C’était l’objectif dès la partie 2, mais les implications concrètes méritent d’être posées clairement.

Un second audit peut être déployé sans modifier une seule ligne de code côté workflow. Le script de création de formulaire est paramétrable par audit. Le template du site vitrine charge les questions dynamiquement depuis la base de données selon un paramètre d’URL. Le moteur de l’automate est indifférent au contenu de l’audit qu’il traite.

Concrètement, les audits suivants sont envisageables avec l’architecture actuelle, sans surcoût de développement significatif :

• Diagnostic cybersécurité de base, orienté vers les obligations NIS2 pour les PME sous-traitantes
• Diagnostic maturité IA, pour les entreprises qui déploient des outils d’IA sans cadre défini
• Audit processus, pour identifier les goulots d’étranglement opérationnels sur des fonctions précises
• Audit plus concret sur l’une des catégories abordées dans l’auto-diagnostic

Chacun de ces audits nécessite uniquement un questionnaire adapté, des modificateurs contextuels pertinents et un template de rapport. L’infrastructure est déjà là.

Mais ce n’est pas tout. Le système peut facilement être dupliqué pour automatiser la génération de rapports (financiers, commerciaux, production…) sans interaction humaine. La saisie manuelle du formulaire étant remplacée par une brique compilant des statistiques envoyées directement à l’automate.

Ce que les données permettront

Chaque diagnostic exécuté alimente la base de données avec trois objets conservés : les scores par question, les flags contextuels dérivés et un résumé structuré. Ces données sont agrégées et non personnelles.

À partir d’un volume suffisant de diagnostics, plusieurs analyses deviennent possibles. Quelles fragilités sont les plus fréquentes selon la taille de l’entreprise ? Les PME sans ressource IT dédiée présentent-elles systématiquement les mêmes angles morts ? Le flag usage IA non encadré est-il corrélé avec des scores plus élevés sur les axes gouvernance et pilotage ?

Ces analyses ne sont pas un produit en soi. Elles alimentent les articles de blog, les prises de parole LinkedIn et les conversations commerciales avec des observations concrètes plutôt qu’avec des généralités de secteur.

Ce qui reste ouvert

Trois points n’ont pas été fermés, par choix.

Le formulaire public dans le site vitrine fonctionne. La page oguhnas.fr/diagnostics/serenite charge les questions depuis la base de données et soumet les réponses au formulaire. Quelques ajustements d’affichage sur mobile sont en attente, sans bloquer le fonctionnement.

Les tests bout-en-bout automatisés. Le moteur a 84 tests unitaires sur les fonctions pures. Il n’y a pas de suite de tests couvrant le workflow complet, de la soumission du formulaire à la réception email. C’est volontairement différé : l’outil d’orchestration ne s’y prête pas bien et le rapport risque/bénéfice ne justifie pas de construire un environnement de test dédié à ce stade.

La personnalisation des pistes de réflexion par LLM. Les pistes de réflexion dans le rapport sont actuellement statiques : elles viennent de la table audit_actions. L’idée d’adapter leur formulation au profil exact du prospect (taille, secteur, flags actifs) via un appel LLM est documentée dans la feuille de route V2. Ce n’est pas une priorité tant que le volume de diagnostics reste faible.

Ce que ce projet m’a rappelé

Trois choses, en dehors des aspects purement techniques.

La généricité ne se décrète pas au départ. Elle émerge quand le découpage des données est propre. La décision de séparer les questions, les actions, les flags et les modificateurs en tables distinctes n’était pas une ambition de départ. C’est la conséquence directe d’avoir posé la question : “qu’est-ce qui doit pouvoir changer indépendamment de quoi ?” Une fois ce découpage fait, la généricité du moteur s’est imposée sans effort supplémentaire.

Les limites des outils sont des contraintes de conception, pas des obstacles. La limite de taille d’indexation, la troncature silencieuse de l’automate sur les grandes valeurs, l’encodage des accolades par la base de données : aucun de ces problèmes n’a bloqué le projet. Chacun a conduit à une décision d’architecture plus solide que celle envisagée initialement.

Un outil non prévu peut devenir le livrable principal. L’application admin était hors périmètre. Elle est aujourd’hui ce qui rend l’outil maintenable sur la durée. Sans elle, modifier une question ou tester un nouveau profil de diagnostic nécessiterait un accès direct à la base de données. Avec elle, c’est quelques clics. Mieux encore, elle permet d’automatiser la rédaction des rapports d’audit réalisés lors des missions (un gain de temps concret pour moi comme pour le client).

Reste une question pratique : est-ce qu’un outil de ce type correspond à votre propre activité ? L’architecture est documentée, les composants sont tous des logiciels libres en hébergement interne.