Comprendre avant de construire.Rester après avoir livré.
Je pars de votre fonctionnement réel — exceptions et fichiers indispensables compris — avant de choisir une technologie. La décision de développer se prend ensuite, avec vous, et elle est écrite.
Le dernier kilomètre.Là où se joue la confiance.
Un outil qui inspire confiance se gagne dans les derniers détails : la rencontre entre le logiciel et votre réalité. C’est là que je passe le temps nécessaire.
Ce qu’une démonstration montre vite
- Modèle
- Interface
- Prototype
- Démonstration
- Faisabilité
Ce que seule la réalité fait apparaître
- Contexte métier
- Données réelles
- Règles non écrites
- Exceptions
- Permissions
- Utilisateurs réels
- Intégration
- Sécurité
- Exploitation
Ce qui commence après la démonstration
Les assistants d’IA rendent le prototype facile, et c’est tant mieux. Voici les questions qui comptent ensuite pour un outil qui dure, regroupées par enjeu — celles que je traite avec vous.
Les données
Ce que l’outil affiche doit être juste, complet et à jour.
- Quelles données font autorité quand deux systèmes se contredisent ?
- Comment reprendre vingt ans d’existant sans rien perdre ?
- Comment tenir plusieurs centaines de milliers d’enregistrements ?
Les personnes
L’outil doit suivre l’organisation réelle, pas un schéma idéal.
- Que se passe-t-il quand douze personnes modifient en même temps ?
- Qui a le droit de voir quoi, et de le modifier ?
- Comment tester avec les utilisateurs réels, pendant leur travail ?
Le changement
Une exception ou une évolution ne doit pas tout bloquer.
- Où vont les exceptions métier que personne n’avait mentionnées ?
- Qu’est-ce qui casse si l’on modifie ce processus essentiel ?
- Comment revenir en arrière après une évolution ratée ?
La durée
Ce qui fonctionne le jour de la démonstration doit tenir dans le temps.
- Comment l’outil tient-il dans trois ans, sans son auteur ?
- Sauvegardes et migrations : qui les a réellement essayées ?
- Quel coût d’infrastructure dans dix-huit mois, à volume réel ?
Une première preuve vite.Une construction durable ensuite.
Votre projet avance par étapes, chacune définie à l’avance et vérifiée avec vous : vous investissez au rythme des résultats, en ne construisant que ce qu’il faut pour décider de la suite.
POC
Preuve de concept (Proof of Concept)
Est-ce possible ?
Démontrer qu’un concept ou une solution technique est faisable, sur le point précis qui fait douter. Avec les outils actuels, la réponse arrive souvent vite : elle est nécessaire, rarement suffisante.
POV
Preuve de valeur (Proof of Value)
Est-ce que cela vaut la peine ?
Vérifier que la solution apporte une valeur réelle au regard du besoin, sur des critères fixés à l’avance, observables ou mesurables. Par exemple :
- Combien de temps le problème fait perdre, par semaine et par personne
- Combien de personnes sont réellement concernées
- Ce que la situation actuelle coûte, erreurs comprises
- Quelle part peut être automatisée, quelle part doit rester humaine
- Ce qui existe déjà sur le marché, et à quel prix
- Quelle valeur un outil spécifique créerait vraiment
MVP
Produit minimum viable (Minimum Viable Product)
Que faut-il réellement construire pour apprendre et avancer ?
La version minimale pertinente, utilisée en conditions réelles, pour apprendre des usages et valider les hypothèses essentielles. Ni maquette jetable, ni produit fini : une base qui sert déjà et peut grandir.
Une réalisation exploitable
Puis la conduite jusqu’en production : reprise des données, droits, sauvegardes, documentation, transmission. Au-delà, en pointillé : l’exploitation et les évolutions.
Le bon choix n’est pas toujours un développement. Si un logiciel existant couvre l’essentiel du besoin pour un coût raisonnable, je vous le recommande.
Six étapes, dans cet ordre
Aller voir
Regarder le travail réel : les fichiers qu’on ouvre vraiment, les contournements, les exceptions que personne n’a documentées.
Poser le problème
Écrit, chiffré, partagé avec ceux qui l’ont décrit. S’il faut le corriger, c’est maintenant : le moment où cela coûte le moins.
Décider
Construire, acheter, régler l’existant ou ne rien faire. La recommandation est écrite, avec ses risques et son coût.
Une première preuve
Quand le problème s’y prête, quelque chose d’observable en quelques semaines : une mesure, un flux clarifié, une première automatisation.
Construire avec les utilisateurs
Des versions utilisables tôt, essayées pendant la vraie journée de travail, corrigées avec ceux qui s’en servent.
Conduire jusqu’en production
Reprise de données, droits, exceptions, supervision, sauvegardes, documentation, transmission. Puis rester présent le temps que tout tienne.
Chaque étape produit un résultat concret : une décision écrite ou quelque chose qui fonctionne.
La même méthode,appliquée à mes propres produits.
Ne jamais séparer un chiffre de sa source
Chaque valeur de France ÉcoScan porte sa source, sa période, son unité, son périmètre et son statut.
France ÉcoScanÉcrire le protocole avant le résultat
Les performances de FYRIS sont mesurées sur des années que le moteur n’a jamais vues, et publiées avec leurs limites.
FYRISNe rien promettre que les calculs ne tiennent pas
Visionary Stats Pro calcule des probabilités exactes depuis les règles des jeux — et refuse toute promesse de gain.
Visionary Stats ProVérifier contre une référence indépendante
Le moteur d’Astro Destiny One est confronté à une référence astronomique indépendante, et ses lectures livrées sont scellées.
Astro Destiny One
Ce que je construisdoit fonctionner sans moi.
Un bon outil est un actif qui vous appartient : vous pouvez l’exploiter, le faire évoluer ou le confier à quelqu’un d’autre. Ces principes se vérifient ligne à ligne à la livraison.
- Les comptes vous appartiennent
- Hébergement, noms de domaine, services en ligne : ouverts à votre nom, administrés par vous. Les accès qui me sont donnés se retirent en une minute.
- Vos données restent les vôtres
- Dans votre environnement, exportables à tout moment dans un format ouvert.
- Code et documentation transmissibles
- Un dépôt qui vous appartient, un historique complet, une documentation écrite pour quelqu’un qui ne me connaît pas.
- Des composants remplaçables
- Un service externe, un modèle d’IA ou un fournisseur s’appelle derrière une frontière claire. En changer reste une décision technique, pas une refonte.
- Des automatismes aux droits limités
- Ce qui est automatisé agit avec le minimum de permissions, dans son périmètre, et laisse une trace de ce qu’il a fait.
- Sauvegardes et retour arrière essayés
- Pas seulement configurés : essayés. Une restauration jamais tentée n’est pas une sauvegarde, c’est une intention.
- Un arrêt d’urgence
- On peut suspendre une automatisation sans arrêter l’entreprise, et revenir temporairement au fonctionnement précédent.
- Aucune dépendance artificielle
- Pas de format fermé, pas de clé que je serais seul à détenir, pas de maintenance obligatoire déguisée.
Trois engagements
- Chiffrer sur la réalité du terrain
- Un devis se construit après avoir regardé le travail réel : il sert le projet, pas seulement la signature.
- Partir du problème
- L’architecture découle du problème, des volumes et des utilisateurs — jamais d’une préférence technique.
- Livrer en transmettant les clés
- Une solution livrée doit pouvoir être comprise, exploitée et reprise sans moi. À la livraison, dans le périmètre convenu, vous recevez :
- La documentation utile : installer, utiliser, exploiter, faire évoluer
- Les accès et les configurations convenus, à votre nom
- Ce qu’il faut pour l’exploitation au quotidien : sauvegardes, supervision, procédures
- Une transmission des connaissances à ceux qui reprendront l’outil
- Des conditions de reprise écrites, pour votre équipe ou un autre prestataire
- La liberté de confier, ou non, les évolutions à Visionary Édition
La maintenance et les évolutions peuvent faire l’objet d’une prestation distincte. Les droits transmis sont ceux que prévoit le contrat.
Le cap.Un rêve, mené comme un projet.
Visionary Édition porte une ambition qui dépasse le logiciel : financer, à l’horizon 2030, un trimaran Ultim à ses couleurs. Aujourd’hui, c’est un rêve d’entrepreneur, pas encore un bateau. Il dit pourtant quelque chose de juste sur la manière de travailler : un projet ambitieux peut naître d’une idée personnelle, et il avance par étapes, sans raccourci.
Du cap à la barre
Définir le cap
Un projet commence par une intention, un besoin, une destination. Pas par une technologie.
Concevoir
Choisir une architecture taillée pour les contraintes réelles — comme on dessine une coque pour un plan d’eau, pas pour un salon nautique.
Construire
Un produit se monte pièce par pièce, par choix successifs, chacun vérifié avant le suivant.
Régler
Les détails, les validations, les corrections : c’est là que se joue la fiabilité.
Éprouver
Une démonstration au ponton ne suffit pas. Le produit doit tenir dans les conditions réelles de son usage.
Transmettre la barre
Celui qui porte le projet doit pouvoir le comprendre, l’utiliser et le faire évoluer — sans dépendre de celui qui l’a construit.
Une inspiration, pas une offre : chaque projet mené à bien rapproche ce cap, et ceux qui travaillent avec le studio pourront suivre la trajectoire.
« On a toujours fait comme ça. » Et si on faisait mieux ?Votre idée mérite qu’on la regarde.
Un problème du quotidien, un outil qui ne suit plus, une opportunité à saisir, un produit qui n’existe encore nulle part : regardons ensemble ce qui mérite d’être fait, et comment le réaliser.
Une idée, même modeste, mérite une vraie discussion. Pas besoin de cahier des charges ni de budget défini : racontez-moi simplement ce que vous aimeriez améliorer ou créer.