Sous le capot, une solution sur mesure bien conçue se ramène presque toujours à quatre briques : une interface légère, un moteur — un modèle d'intelligence artificielle exécuté localement ou appelé par API selon la sensibilité des données —, une base de données simple, et, en option, un agent conversationnel qui interroge le tout en langage naturel. FiscalDoc, l'application que j'ai construite pour classer ma propre fiscalité, illustre ce patron dans sa forme la plus dépouillée. Ce qui suit généralise cette architecture, et explique honnêtement ce qui la fait grossir.
Quels sont les quatre composants qui reviennent presque toujours ?
La première brique est l'interface : la façade par laquelle un utilisateur dépose une information ou lit un résultat. Dans FiscalDoc, c'est un simple formulaire web — je dépose un PDF ou une photo, l'outil s'occupe du reste. Rien ne justifie, à cette échelle, un framework front-end lourd ni une application mobile native : un formulaire propre, un tableau filtrable, quelques boutons suffisent à la quasi-totalité des usages internes d'une PME. La sophistication visuelle devient utile surtout lorsque des personnes extérieures à l'entreprise utilisent l'outil — ce qui change la donne, j'y reviens plus loin.
La deuxième brique, le moteur, est le choix qui structure tout le reste. Un modèle d'intelligence artificielle ouvert, exécuté localement, s'impose quand aucune donnée ne doit quitter l'entreprise — c'est le choix que j'ai fait pour FiscalDoc, avec un modèle ouvert tournant sur mon propre Mac, sans le moindre appel réseau pour le cœur du traitement. Un appel API vers un modèle propriétaire reste, à l'inverse, parfaitement défendable quand la donnée traitée est peu sensible et que la rapidité de mise en œuvre prime. Entre les deux, il n'existe pas de réponse universelle, seulement un arbitrage propre à chaque cas d'usage, que je détaille dans Projet IA bien construit : les trois patterns qui tiennent — l'appel direct, le RAG et les agents y sont posés comme les trois patrons qui couvrent l'essentiel des projets, indépendamment du choix local ou API.
La troisième brique, la base de données, surprend souvent par sa modestie. FiscalDoc indexe plusieurs centaines de documents par an dans une base SQLite locale — un fichier, pas un serveur. Pour un usage circonscrit à une poignée d'utilisateurs et quelques milliers d'enregistrements, une base de données simple fait le travail qu'on croit réservé à une infrastructure lourde. La bascule vers un système plus robuste — base hébergée, réplication, sauvegardes automatisées — ne devient nécessaire qu'à partir du moment où plusieurs personnes écrivent en même temps, ou où le volume dépasse ce qu'une machine unique tient confortablement.
La quatrième brique est optionnelle, et c'est important de le dire clairement : un agent conversationnel qui interroge la base et les documents en langage naturel. Dans FiscalDoc, je peux demander de retrouver les factures MCVA supérieures à 2'000 CHF sur le dernier trimestre et obtenir une réponse construite à la volée. Cette couche ajoute un vrai confort, mais elle n'est jamais la première chose à construire : un tableau de bord filtrable couvre déjà la majorité des besoins de recherche, et l'agent conversationnel ne justifie son coût de développement que si les questions posées sont réellement variées et imprévisibles.
Où héberger ces quatre briques ?
Le choix d'hébergement suit directement celui du moteur, pas l'inverse. Une machine locale — un poste de travail correctement dimensionné en mémoire — suffit pour un usage individuel ou une petite équipe, avec un modèle ouvert qui ne se connecte jamais à Internet pour le cœur du traitement. Une infrastructure suisse ou européenne devient pertinente dès que plusieurs utilisateurs doivent accéder au même outil depuis des postes différents, sans pour autant vouloir confier les données à un cloud hors juridiction. Un cloud d'éditeur assorti d'engagements contractuels de non-rétention reste une option raisonnable pour les données les moins sensibles, quand la vitesse de mise en œuvre compte plus que la maîtrise totale du lieu d'exécution. J'ai posé cette grille à trois niveaux — engagements contractuels, hébergement suisse ou européen, modèle ouvert sur infrastructure contrôlée — dans l'article sur l'architecture des projets IA, et je la reprends à chaque cadrage de solution sur mesure.
Pourquoi quelques centaines de lignes suffisent souvent ?
FiscalDoc tient dans un dossier de quelques centaines de lignes de code. Ce n'est pas une prouesse : c'est la conséquence directe d'un périmètre resté volontairement étroit. Un outil qui sert un utilisateur ou une petite équipe, sur une fonction précise et bien décrite, n'a besoin ni de gérer des milliers de connexions simultanées, ni d'anticiper des cas qui ne se présenteront jamais. La discipline la plus rentable, dans ce genre de projet, consiste à résister à la tentation de construire pour un usage hypothétique plutôt que pour le besoin réel posé au départ.
Ce qui a aussi changé, en dix-huit mois, c'est le coût de production lui-même. Je n'ai pas écrit FiscalDoc ligne par ligne : je l'ai dialogué avec un assistant de code, soir après soir, jusqu'à obtenir un outil qui me ressemble — j'ai détaillé cette méthode dans mon retour d'expérience sur le développement assisté. Ce que je démontre à l'échelle d'un cabinet d'une personne, la même logique le permet, fonction par fonction, pour des besoins de PME plus larges. Le cas complet — coûts, arbitrages, limites — est documenté dans FiscalDoc : remplacer 1'400 CHF/an de SaaS par une IA locale.
Qu'est-ce qui fait grossir un projet ?
Je n'ai, à ce jour, documenté publiquement qu'un seul cas complet construit selon ce patron — FiscalDoc. Mais son architecture n'a rien d'accidentel : elle correspond à ce qui reste une fois le superflu retiré, et elle change dès que l'une des trois conditions suivantes évolue.
- Les intégrations. Connecter l'outil à un système comptable existant, à un ERP ou à une messagerie professionnelle multiplie les points de défaillance : chaque intégration ajoute son propre contrat d'interface, sa propre gestion d'erreurs, sa propre maintenance dans le temps.
- Le multi-utilisateurs. Dès que plusieurs personnes doivent accéder au même outil avec des droits différents, il faut une authentification réelle, une gestion des rôles, et souvent une trace de qui a fait quoi — un chantier à part entière, distinct de la logique métier elle-même.
- La conformité. Un outil qui touche des données de tiers — clients, collaborateurs — engage la LPD au-delà du simple choix d'hébergement : registre des traitements, contrat de sous-traitance si une brique externe est utilisée, politique de conservation. Ce chantier mérite d'être posé au cadrage, pas découvert en cours de route.
Aucun de ces trois déclencheurs ne condamne le sur-mesure. Ils changent son budget et sa rigueur, pas sa pertinence. Ce qu'ils invalident, en revanche, c'est l'idée qu'un projet de ce type se règle toujours en quelques soirées : passé ce seuil, le cadrage mérite le même sérieux qu'un projet SaaS d'équivalent périmètre — c'est précisément ce que je pose au départ de chaque solution sur mesure. Cette anatomie n'est qu'un chantier parmi d'autres : la feuille de route d'ensemble est posée dans Que doit faire une PME suisse face à l'IA en 2026 ?
Ce qu'il faut retenir
— Une solution sur mesure se ramène presque toujours à quatre briques : interface légère, moteur choisi selon la sensibilité des données, base simple, agent conversationnel optionnel. — L'hébergement suit le choix du moteur : poste local, infrastructure suisse ou européenne, ou cloud d'éditeur sous engagements contractuels. — Trois déclencheurs font grossir un projet : intégrations, multi-utilisateurs, conformité — ils changent le budget, pas la pertinence du sur-mesure.
FAQ
Faut-il toujours privilégier un modèle IA local plutôt qu'une API ? Non. Le local s'impose quand aucune donnée ne peut quitter l'entreprise ; l'API reste souvent plus rapide à mettre en œuvre pour des données peu sensibles. C'est un arbitrage par cas d'usage, pas un principe absolu.
Une PME sans compétence technique interne peut-elle envisager ce type d'outil ? Oui, à condition qu'un tiers compétent conduise le dialogue avec l'assistant de code et relise ce qui est produit. Le livrable — code et données — appartient alors intégralement à l'entreprise, ce qui reste l'intérêt central de la démarche.
Combien de temps prend un projet de ce type ? Cela dépend entièrement du périmètre : quelques soirées pour un besoin aussi circonscrit que FiscalDoc, plusieurs semaines dès qu'interviennent intégrations ou multi-utilisateurs. Aucun chiffre général ne serait honnête sans un cadrage préalable.
Une base de données aussi simple qu'une base SQLite locale est-elle vraiment fiable pour une PME ? Pour un usage à un ou quelques utilisateurs et des volumes de quelques milliers d'enregistrements, oui, largement. Elle atteint ses limites dès que plusieurs personnes écrivent simultanément ou que le volume dépasse ce qu'une seule machine gère confortablement — le signal même qui annonce un changement d'échelle.
Et dans votre entreprise ? Le Diagnostic d'Usage IA : soixante minutes pour poser vos flux réels, identifier ce qui mérite du sur-mesure, ce qui reste en SaaS, et ce qui n'a pas besoin d'IA du tout. Réserver un diagnostic
Jérôme Deshaie est CEO et fondateur de MCVA Consulting SA, agence augmentée basée en Valais. Quinze ans au service de grandes marques internationales, désormais en direct pour les PME suisses. Parcours.