En bref
J'ai passé quatorze ans dans la qualité, dont plusieurs à faire du contrôle dimensionnel dans l'hydroélectrique, avant d'écrire ma première ligne de code sérieuse. Aujourd'hui, seul, j'ai conçu une suite de logiciels de métier cohérente pour les ateliers d'usinage. Ce n'est pas une prouesse de programmeur. C'est une prouesse de cadre.
L'IA m'a permis d'aller vite. Mais l'IA laissée à elle-même produit du plausible, pas du fiable — et en qualité, le plausible ne passe pas l'audit. Ce qui a rendu le résultat solide, c'est la discipline imposée autour d'elle : des règles écrites, des limites strictes, une vérification à chaque étape. Voici comment, et surtout ce que cela révèle de ce qu'une PME peut désormais se permettre.
Je viens de l'atelier, pas de l'informatique
Il faut poser ça d'emblée, parce que ça change tout le reste. Je ne suis pas un développeur qui a découvert le manufacturier. Je suis un praticien de la qualité qui a fini par écrire ses propres outils.
Pendant quatorze ans, mon quotidien a été fait de cotes, de premiers articles, de non-conformités à documenter, de rapports d'inspection à livrer au donneur d'ordre. J'ai contrôlé des pièces où l'erreur ne se rattrape pas. J'ai vécu la revue de direction, l'audit interne, la traçabilité rompue qu'on découvre trois mois trop tard. Je connais le poids réel d'un étalonnage oublié.
Ce vécu n'est pas un détail biographique. C'est le socle de tout. Un logiciel de qualité conçu par quelqu'un qui n'a jamais rempli un rapport de premier article à la main sera toujours un logiciel qui ressemble à ce dont on a besoin, sans jamais y coller vraiment. Les détails qui font la différence — l'ordre exact de la chaîne qualité, ce qu'un auditeur veut voir, ce qui fait perdre une heure au machiniste — ne s'inventent pas. Ils se vivent d'abord.
Je ne suis pas un développeur qui a découvert le manufacturier. Je suis un praticien de la qualité qui a fini par écrire ses propres outils.
L'IA seule ne fait rien de fiable
Beaucoup de dirigeants imaginent qu'aujourd'hui, on « demande à l'IA » de construire un logiciel et qu'il en sort une application prête à l'emploi. Ce n'est pas ainsi que ça fonctionne, et il faut être honnête là-dessus.
L'IA générative est remarquable pour produire vite quelque chose qui a l'air correct. C'est aussi précisément son danger. Elle ne connaît pas la différence entre « juste » et « crédible ». Laissée sans cadre, elle invente une structure de données un jour, en propose une autre le lendemain, mélange deux notions qui doivent rester séparées, et vous laisse avec un assemblage qui compile, qui se démontre bien, et qui s'effondre au premier cas réel.
En qualité, ce genre de fragilité est éliminatoire. Prenons la chaîne que tout responsable qualité connaît : une non-conformité (§8.7) se rattache à un processus ; une action corrective (§10.2) se rattache à une non-conformité ; une action préventive découle d'une analyse de risque (§6.1). Ces liens ne sont pas décoratifs. Ils sont la logique même du système. Une IA à qui on demande « fais-moi un module de non-conformités » sans encadrement rigoureux va, tôt ou tard, rattacher une action corrective à un risque au lieu d'une non-conformité. Sur le moment, personne ne le voit. En audit, ça vous coûte votre certification.
C'est le cœur de tout ce que j'ai appris en construisant Asterion : l'IA n'est utile que si elle est tenue. Le logiciel de métier, c'est le cadre. L'IA travaille dedans, pas à sa place.
La discipline avant la vitesse
Concrètement, encadrer l'IA veut dire lui imposer les mêmes règles qu'on imposerait à un employé junior très rapide mais sans jugement métier. On ne le laisse pas décider de l'architecture. On lui donne des consignes écrites, non négociables, et on vérifie son travail à chaque étape.
J'ai donc écrit des règles avant d'écrire du code. Des règles simples, tenues, relues à chaque intervention. Quelques exemples de ce qui gouverne chaque ligne du système :
| Règle imposée | Ce qu'elle empêche |
|---|---|
| Découper chaque morceau du logiciel en petites pièces courtes, jamais de blocs géants | Le fouillis ingérable où plus personne ne comprend ce qui se passe, ni comment le corriger |
| Nommer et vérifier chaque donnée sans jamais tolérer d'à-peu-près | Les erreurs silencieuses qui passent la démo et cassent au travail réel |
| Contrôle automatique avant et après chaque modification | Le fait de réparer une chose en cassant discrètement une autre sans s'en apercevoir |
| Une donnée métier saisie une seule fois, jamais recopiée d'une application à l'autre | La double-saisie et les incohérences entre modules |
| Documentation mise à jour en même temps que le logiciel | La dérive entre ce que le logiciel fait et ce qu'on croit qu'il fait |
Ces règles ne rendent pas le travail plus rapide, à court terme. Elles le rendent plus lent, volontairement. C'est le point que je veux faire passer aux dirigeants : la valeur n'est pas dans la vitesse de l'IA, elle est dans la rigueur de ce qui l'entoure. Une IA rapide dans un cadre discipliné produit un logiciel solide. Une IA rapide sans cadre produit une dette qu'on paie plus tard, souvent au pire moment.
À chaque intervention, la même mécanique se répète : lire et comprendre l'existant avant de le toucher, faire un changement minimal et ciblé, vérifier que rien d'autre n'a bougé, résumer ce qui a été fait. Ce n'est pas glamour. C'est exactement la discipline qu'on attend d'un bon système qualité : traçable, vérifiable, sans zone d'ombre.
Il y a une objection légitime qu'un dirigeant se pose devant un outil bâti par une seule personne : « et si cette personne disparaît, qu'advient-il de mon logiciel ? ». C'est justement à cela que sert toute cette rigueur. Un logiciel dont les pièces sont courtes, nommées clairement, documentées au fil de l'eau et gouvernées par des procédures écrites n'est pas un objet mystérieux enfermé dans une seule tête. Il est lisible, repérable, reprenable. La même exigence de traçabilité qu'on impose à un dossier qualité — que n'importe qui puisse retrouver quoi, pourquoi et comment — s'applique au logiciel lui-même. C'est ce qui fait qu'un outil vit au-delà de celui qui l'a écrit : non pas la promesse d'une personne, mais la structure documentée qui permet à d'autres de la relayer. Pour un acheteur, c'est une garantie de durabilité, pas un pari sur un individu.
Un écosystème cohérent, pas un tas d'outils
Le résultat de cette discipline, c'est une chose qu'on ne construit pas par accident : une suite d'applications qui se parlent réellement.
Chaque application couvre un métier réel de l'atelier — le contrôle dimensionnel, la gestion de la qualité, la métrologie, la planification. Mais l'important n'est pas la liste. L'important, c'est qu'elles partagent une seule identité, une seule source de vérité pour les données maîtres, une seule façon de penser. Un bon de travail saisi une fois circule d'un métier à l'autre sans être ressaisi. Une non-conformité détectée au contrôle alimente le système qualité. Un instrument suivi en métrologie est proposé au bon endroit lors de l'inspection.
Cette cohérence n'est possible que parce qu'un seul cadre gouverne l'ensemble. Les mêmes règles de structure, la même exigence de traçabilité, la même conformité — au Québec, cela veut dire des données hébergées et traitées ici, un choix d'architecture assumé dès la première ligne, pas un correctif ajouté après coup. La souveraineté des données, pour moi, n'est pas un argument de peur. C'est une question de contrôle et de propriété : les plans de vos clients, l'historique de vos non-conformités, ce sont vos actifs. Ils doivent rester sous votre maîtrise, et cela se décide dans l'architecture, tôt.
Un ensemble d'outils bricolés séparément n'aurait jamais tenu cette cohérence. C'est la discipline imposée à chaque brique qui permet à l'ensemble de former un système, et non un empilement.
80 % à la machine, 20 % à l'humain — et jamais l'inverse
Là où l'IA encadrée donne le meilleur, c'est sur le travail répétitif. Extraire les cotes d'un plan, comparer des documents à des exigences, préparer un dossier, signaler une échéance qui approche : ce sont des tâches où la machine, bien tenue, abat l'essentiel de l'effort. Elle prépare.
Mais elle ne signe pas. La libération d'un produit (§8.6), la clôture d'une action corrective, la décision qui engage la responsabilité de l'entreprise : cela reste, à 100 %, entre les mains d'un humain qualifié. Un logiciel bien conçu ne cherche pas à automatiser le jugement. Il l'augmente. Il présente l'information claire, met en évidence ce qui manque ou ce qui cloche, propose — et laisse la personne compétente décider.
Cette frontière n'est pas une limite technique qu'on lèvera un jour. C'est un principe. La responsabilité ne s'automatise pas. Un système qui prétend le contraire ment à son utilisateur, et le laisse seul le jour de l'audit. L'IA qui prépare bien et l'humain qui tranche : c'est le bon partage, et c'est celui que le cadre doit protéger.
Ce que ça révèle pour une PME
Voici la partie qui devrait intéresser tout dirigeant, au-delà de mon parcours.
Il y a quelques années encore, concevoir une suite logicielle cohérente pour un métier précis demandait une équipe, un budget, des mois — souvent des années. C'était réservé aux grands. Une PME manufacturière n'avait le choix qu'entre deux options : payer très cher une suite générique qu'elle n'utiliserait qu'à moitié, ou vivre avec ses fichiers Excel et ses classeurs.
Ce que mon expérience démontre, c'est qu'une troisième voie existe désormais. Une personne qui connaît vraiment son métier, si elle sait encadrer l'IA plutôt que de lui faire aveuglément confiance, peut concevoir en quelques mois des outils taillés exactement pour son terrain. Pas parce que l'IA fait le travail à sa place — elle ne le fait pas — mais parce qu'elle réduit énormément la distance entre « savoir ce dont on a besoin » et « le construire ».
La compétence qui compte, ce n'est plus de savoir programmer. C'est de savoir quoi construire, et d'avoir la discipline de tenir l'IA dans les rails pendant qu'elle aide à le construire. Autrement dit : l'expertise métier reprend la première place. Celui qui connaît la cote, la non-conformité, l'étalonnage et la revue de direction a désormais les moyens de transformer ce savoir en outil, sans devenir informaticien.
Pour une PME, la leçon est directe. La question n'est plus « avons-nous les moyens d'un logiciel sur mesure ? ». Elle devient : « connaissons-nous assez précisément notre propre métier pour dire ce dont nous avons vraiment besoin ? ». Et pour un fournisseur, la question est : est-ce qu'il vient de votre monde, ou est-ce qu'il le regarde de loin ?
En conclusion : le cadre, plus que l'outil
Si je devais résumer ces coulisses en une phrase, ce serait celle-ci : ce n'est pas l'IA qui a construit ces logiciels, c'est la discipline autour d'elle. L'IA a été un accélérateur puissant. Le cadre — les règles, la vérification, l'exigence de traçabilité, le refus d'automatiser le jugement — a été ce qui a rendu le résultat digne d'un environnement où l'erreur se paie.
Cela ouvre des questions que je trouve plus intéressantes que les réponses. Si l'expertise métier devient la ressource rare et l'outil devient accessible, à quoi ressemble un bon logiciel de qualité conçu par ceux qui vivent le métier plutôt que par ceux qui le décrivent ? Combien d'ateliers portent, dans la tête de leurs meilleurs éléments, des outils qui ne demandent qu'à exister ? Et jusqu'où fait-on confiance à une machine qui prépare admirablement, tant qu'un humain garde la main sur ce qui l'engage ?
Je n'ai pas toutes les réponses. Mais je sais une chose, pour l'avoir construit : l'IA encadrée par un logiciel de métier structuré ne remplace pas le professionnel de la qualité. Elle lui rend enfin la place qui lui revient.
Les principes décrits dans cet article sont ceux qui ont guidé le développement d'Asterion Solutions, une suite de logiciels de métier pensés pour les PME manufacturières qui veulent structurer leur qualité sans multiplier les tâches administratives.