`
Pourquoi un fiduciaire a besoin de « petits outils »
Je suis comptable à Lausanne, et je constate année après année la même réalité : dans une fiduciaire, une multitude de petites tâches répétitives s’accumulent. Vérifier une somme avec TVA, recalculer rapidement un net/brut, préparer un modèle de facture, rédiger un rappel client, contrôler un IBAN, regrouper des informations dans un format clair. Ce n’est pas du « grand logiciel », ce sont des dizaines de micro-outils qui font gagner du temps chaque jour.
L’IA (notamment les assistants modernes capables d’écrire du code) a rendu étonnamment accessible ce qui demandait auparavant de l’expérience : prendre une idée de « calculateur » ou de « générateur » et la transformer en page web ou en petit service. Il faut bien comprendre la nuance : l’IA ne remplace pas le contrôle, elle abaisse la barrière d’entrée. Une personne sans formation en programmation peut aujourd’hui construire des prototypes et les amener à un niveau réellement utile.
Mais il existe une différence essentielle entre « générer du code » et « produire un outil auquel on peut faire confiance ». Dans une fiduciaire, une erreur n’est pas seulement une imperfection d’interface. Cela peut devenir un mauvais calcul, un format incorrect, un document illisible, ou une défaillance qui surgit au pire moment — quand le client est déjà en déplacement et que la facture doit être payée aujourd’hui.
C’est précisément pour cela que je tiens ce blog comme un journal de progression : pas dans le style « regardez comme c’est facile », mais plutôt « ce que j’ai fait, où j’ai trébuché, comment j’ai vérifié que ça fonctionne, et pourquoi un contrôle externe reste indispensable ». Je veux documenter un chemin qu’un autre comptable ou fiduciaire pourrait reproduire : sans arrogance technique, mais avec discipline et sens du détail.
Enfin, une motivation supplémentaire : en Suisse (et ailleurs), les outils comptables sont souvent soit trop lourds et coûteux, soit trop génériques. Les micro-applications, elles, se construisent autour du travail réel. Pas une « ERP pour tout », mais « un calculateur pour cette tâche », « un générateur pour ce format », « une vérification pour ce champ ». L’IA joue ici le rôle d’accélérateur — pas de pilote automatique.
Comment, sans programmer, on peut construire un calculateur
J’ai commencé par le plus simple : un calculateur qui reproduit ce que je fais mentalement et dans Excel des dizaines de fois par semaine. Par exemple : passer d’un montant TTC à HT, calculer un brut selon un taux, appliquer un arrondi « comme sur les factures », et vérifier rapidement que le total correspond à la somme des lignes. Ces calculateurs ne valent pas parce qu’ils sont complexes, mais parce qu’ils réduisent la charge cognitive et diminuent le risque d’erreur humaine.
Ma manière de travailler avec l’IA s’est structurée ainsi : je ne demande pas « fais-moi un calculateur ». Je formule des exigences comme un comptable : quels champs en entrée, quelles règles d’arrondi, quels taux (fixes ou modifiables), quel format de sortie, et ce qui constitue une erreur de saisie. Ensuite, je demande un prototype minimal : une page, un formulaire, un résultat sous le formulaire, sans décor inutile.
Puis vient l’étape la plus importante : les cas de test. L’IA peut écrire un code qui « a l’air juste », mais le « juste » en comptabilité se définit par des exemples. Je prends 10 à 20 scénarios réels : petits montants, grands montants, montants avec deux décimales, montants sans centimes, arrondis à la limite. Je calcule manuellement (ou via Excel) et je compare. Si ça diverge, je ne « crois pas l’IA » : je clarifie la règle. Souvent, la cause n’est pas un bug, mais une exigence mal définie.
Pour ne pas m’enliser, je progresse par étapes. D’abord : « ça fonctionne chez moi dans le navigateur ». Ensuite : « ça fonctionne sur téléphone ». Puis : « je le donne à un collègue et je lui demande de le casser ». Pour une fiduciaire, c’est crucial : un outil doit rester fiable même sous pression. Quand un client appelle, on n’a pas le luxe de comprendre pourquoi un bouton ne répond plus.
Autre sujet essentiel : le versioning. J’ai très vite compris que « un prompt = un résultat » ne tient pas sur la durée. Je prends des notes : quelle version, quels changements, quels tests sont passés, quels risques restent ouverts. Comme on documente les processus comptables, il faut documenter le « processus numérique ». C’est aussi cela, le contrôle externe : pas uniquement vérifier des chiffres, mais contrôler l’évolution de l’outil.
Générateur QR de factures : « ça marche presque », mais le réel est plus exigeant
Après les calculateurs, j’ai voulu m’attaquer à ce qui semblait être un gain évident : un générateur de QR-factures. En Suisse, la QR-facture est un standard, et il est logique de disposer d’un outil interne qui génère rapidement un QR pour un client. Pour ne pas réinventer la roue, je me suis d’abord appuyé sur des solutions existantes — par exemple une page de génération de QR-factures que j’utilise comme référence pour la structure des champs et le résultat attendu : https://robuste.ch/generateur-gratuit-de-factures-qr/.
À ce stade, il est facile de tomber dans un piège : si le QR se génère et qu’une caméra de smartphone le lit, on pense que c’est prêt. Mais le monde fiduciaire n’est pas un monde du « ça a l’air bon ». C’est un monde de ce que la banque accepte, de ce que le système de paiement lit, et de ce que le guichet de La Poste peut réellement scanner. Et c’est précisément là que j’ai rencontré une situation que je laisse volontairement « en suspens » à ce stade : mon générateur produit des QR-factures qui semblent correctes, mais La Poste n’arrive pas à les scanner.
C’est un cas d’école sur les limites de l’IA sans contrôle humain. L’IA peut générer un QR sous forme d’image. La vraie question est : est-ce que le contenu encodé respecte le standard exactement comme le scanner du processus réel l’exige ? On peut obtenir un QR lisible par des scanners « génériques » et rejeté par des scanners spécialisés. Et oui, cela peut dépendre du format des données, de l’encodage, de l’ordre des champs, de caractères de contrôle, d’une version de standard, voire de la qualité du rendu.
Il y a un autre point : en pratique fiduciaire, ce qui compte n’est pas seulement le QR, mais tout l’environnement de la facture : mise en page, typographies, marges, contraste, échelle, et l’espace de silence autour du code (quiet zone). L’IA produit parfois quelque chose de visuellement « propre », mais pas forcément techniquement « scannable ». Et cela nous ramène à l’idée centrale : un contrôle externe n’est pas une option, c’est une exigence.
Je ne dévoile pas encore ici la cause exacte ni la correction (je publierai un prochain billet quand la solution sera stabilisée). Mais je peux déjà tirer un enseignement utile : dans les outils « de paiement », le test ne doit pas être seulement numérique (le QR s’ouvre-t-il ?), mais aussi process (fonctionne-t-il au point où il est réellement utilisé ?). Si l’outil échoue au test « sur le terrain », il n’est pas prêt.
Comment je vais faire évoluer ce blog — et pourquoi le contrôle humain est la clé
J’ai pensé ce blog comme une série de comptes rendus courts mais concrets : ce que je voulais construire, quel résultat minimal j’ai obtenu, quels problèmes sont apparus, et comment je les ai résolus. Je cherche le point de vue du fiduciaire : pas « magie de l’IA », mais « IA + méthode ». La structure sera donc volontairement répétitive : objectif, critères de qualité, réalisation, tests, incident, conclusion.
Deuxième principe : « la justesse avant la vitesse ». L’IA donne l’impression qu’on peut tout produire en une soirée. Mais en comptabilité, la vitesse sans vérification crée une dette — et elle finit par coûter cher. Je veux montrer comment j’organise le contrôle : cas de test, vérification des extrêmes, validation des saisies, journal des modifications, et, si possible, une vérification indépendante (un collègue, un autre appareil, un autre point de scan).
Troisième principe : les outils destinés aux clients doivent rester « humains ». Si un client saisit un montant, il lui faut des indications, des exemples, des avertissements, des erreurs compréhensibles. L’IA peut générer une interface, mais la « pédagogie de l’interface » reste notre travail. Une fiduciaire ne peut pas se permettre un outil qui pousse à une saisie incorrecte ou qui laisse l’utilisateur seul face à un message incompréhensible.
Quatrième principe : complexifier progressivement. D’abord des calculateurs (net/brut, TVA, devises, arrondis). Ensuite des générateurs (modèle de facture, QR, e-mail de rappel, explications courtes pour le client). Puis des outils de vérification (IBAN, structure d’adresse, cohérence des montants). Et à chaque étape, je veux écrire honnêtement : où l’IA m’a aidé, et où elle a créé une illusion de « prêt à l’emploi ».
Enfin, l’histoire du QR et de La Poste est l’exemple parfait du sujet de ce blog. L’IA aide à créer des outils efficaces, mais ils exigent encore un contrôle externe. Je reviendrai sur ce cas dans un article dédié : ce qui n’allait pas, comment je l’ai diagnostiqué, quelles hypothèses étaient fausses, et quelle approche a donné un résultat stable. Parce que ce sont précisément ces histoires-là qui sont les plus utiles à ceux qui commencent.
`
Top comments (0)