En bref
On me vend de l'IA partout, et on me demande souvent quelle est la mienne. La réponse honnête surprend : dans nos logiciels, l'IA fait très peu de choses. Quatre tâches précises, toutes de lecture ou de brouillon, et trois de nos six applications n'en contiennent pas une seule ligne. Le reste — l'essentiel — est du logiciel ordinaire.
Cela amène immédiatement la question qui compte, et un client me l'a posée telle quelle : si l'IA n'est qu'un détail encadré, pourquoi mes données devraient-elles vivre dans le nuage ? Installez-moi ça sur un serveur chez nous. C'est une bonne question. Voici ma réponse, et ce que je m'engage à donner en échange.
Les quatre endroits où un modèle touche vos données
Commençons par l'inventaire, parce qu'un fournisseur qui parle d'IA sans dire où elle se trouve ne dit rien. Voici la liste complète, telle qu'elle tourne aujourd'hui.
| Où | Ce que le modèle fait | Ce qui lui est envoyé |
|---|---|---|
| Rapport d'inspection | Lit les cotes et les tolérances d'un plan | Une fenêtre du plan que l'inspecteur a encadrée lui-même — pas le plan complet |
| Rapport d'inspection | Transcrit un relevé de mesures écrit à la main | L'image de la feuille de relevé |
| Système qualité | Rédige une proposition de courriel au client à partir d'une non-conformité | Le texte de cette non-conformité |
| Module normes (en préparation) | Lit une norme en PDF pour en extraire des exigences vérifiables | La norme importée |
C'est tout. Il n'y a pas de cinquième ligne cachée. Et ce tableau se lit dans les deux sens : ce qui n'y figure pas, aucun modèle ne le voit. Votre historique de non-conformités n'est pas envoyé quelque part pour être « appris ». Vos prix, vos clients, vos employés, vos résultats de mesure ne sortent pas de la base de données.
Trois applications sur six n'en contiennent aucune
Le point suivant est celui qui me sert le plus, quand j'explique mon travail. La métrologie — l'étalonnage, les certificats, les rappels d'instruments — ne contient pas une ligne d'IA. La planification d'atelier non plus. Le module de flux de production non plus. Ce sont des logiciels entièrement déterministes : les mêmes données donnent le même résultat, aujourd'hui, demain, et dans trois ans devant un auditeur.
Et à l'intérieur même du système qualité, la partie que la plupart des gens prennent spontanément pour de l'IA n'en est pas. Quand une non-conformité se rattache à un processus, qu'une action corrective se rattache à sa non-conformité, qu'une action préventive découle d'une analyse de risque — tout ce maillage qui fait apparaître les points critiques — ce sont des règles écrites une par une. Cent douze, exactement. Pas un modèle qui devine : une matrice qu'on peut relire, discuter et corriger. L'indice de maturité du système fonctionne de la même façon, par un calcul dont je peux vous montrer chaque étape.
Ce n'est pas une faiblesse que j'avoue à contrecœur. C'est une exigence de métier. Un système qualité doit produire deux fois le même verdict sur les mêmes faits, sinon il ne prouve rien.
Le modèle a le droit de lire et de proposer. Il n'a jamais le droit de décider, ni d'écrire dans la base.
La règle qui gouverne les quatre cas
Regardez à nouveau la colonne du milieu du tableau : lit, transcrit, rédige une proposition, extrait. Aucun verbe de décision. Dans les quatre cas, le résultat arrive devant un humain qui le voit, le corrige et le valide avant qu'il existe pour de vrai. Les cotes lues sur un plan atterrissent dans un tableau que l'inspecteur relit ligne par ligne. Le courriel au client est un brouillon dans une fenêtre d'édition : personne ne l'envoie sans l'avoir lu.
C'est ce que j'appelle une IA cantonnée, et j'ai détaillé ailleurs ce qu'elle peut faire et ce qu'elle ne doit jamais faire. Le cantonnement ne tient pas à la sagesse du modèle. Il tient au logiciel autour : c'est le programme qui refuse d'enregistrer une valeur non validée, et c'est le programme qu'on peut auditer.
Ce qui sort vraiment de votre atelier
Soyons précis, parce que c'est là que la plupart des fournisseurs restent vagues.
Ce qui est envoyé à un modèle est toujours un fragment que quelqu'un a désigné : une zone de plan qu'on a encadrée à l'écran, une feuille de relevé qu'on a photographiée, le texte d'une non-conformité qu'on a ouverte. Jamais la base de données, jamais un lot d'historique, jamais une extraction nocturne.
Ce fragment est traité en premier par un service hébergé à Montréal. Si ce service est indisponible, l'appel peut basculer vers un service équivalent hors du Canada, sur ce même fragment réduit et rien d'autre. Je préfère le dire franchement plutôt que de promettre un « jamais » que le code ne garantit pas — et c'est exactement le genre de nuance qu'il faut exiger d'un fournisseur. La question utile n'est pas « est-ce que c'est au Canada », c'est quoi précisément, chez qui, et dans quel cas.
Enfin : rien de ce qui est envoyé ne sert à entraîner un modèle. Vos plans ne deviennent pas la connaissance générale de quelqu'un d'autre.
Alors, à quoi sert le nuage ?
Voilà la conclusion logique de tout ce qui précède, et elle n'est pas confortable pour moi : l'IA n'a jamais été l'argument du nuage. Si elle ne représente que quelques pourcents du logiciel et qu'elle ne travaille que sur des fragments, alors l'hébergement ne se justifie pas par elle.
Prenons la mesure de ce que sont les autres quatre-vingt-quinze pourcents. Des formulaires. Des règles de gestion. Des liens entre des objets métier. Un PDF bien fait. Un historique consultable. Rien de tout cela n'était techniquement impossible en 2005. Un logiciel qui relie les non-conformités aux processus et les instruments aux inspections, ce n'était pas un défi scientifique : c'était un travail long, minutieux, et surtout cher à écrire. Trop cher pour être vendu à un atelier de trente personnes à un prix qu'il aurait accepté de payer. C'est pour ça que je n'ai jamais vu de vrai système qualité en PME : non pas parce que personne n'y avait pensé, mais parce que le devis n'a jamais rencontré le budget. Ce qui a changé récemment, c'est le coût de fabriquer ce logiciel — pas la difficulté de l'imaginer.
« Installez-le chez nous, alors »
La demande est légitime, et je l'entends surtout de directeurs qualité prudents, ce qui est plutôt bon signe. Ma réponse est non, et je préfère l'expliquer plutôt que de la contourner.
Parce que personne ne l'entretiendrait. Un logiciel installé sur un serveur, c'est quelqu'un qui applique les correctifs de sécurité, qui vérifie que la sauvegarde a bien tourné cette nuit, et qui sait restaurer la base le matin où le disque meurt. Un atelier de trente personnes n'a pas d'informaticien. Ce que j'aurais livré, ce n'est pas un logiciel : c'est un deuxième métier que personne n'a le temps d'apprendre. On connaît la suite, parce que c'est l'histoire du fichier Excel sur le lecteur partagé : ça tient jusqu'au jour où ça ne tient plus, et la connaissance nécessaire pour le réparer est partie avec quelqu'un.
Parce que le travail se fait dans l'atelier, pas au bureau. Déclarer une non-conformité depuis un téléphone au pied de la machine, consulter un rapport chez le client : un serveur dans la bâtisse ne sort pas de la bâtisse. Pour qu'il en sorte, il faut lui ouvrir une porte sur Internet — c'est-à-dire recréer, sans surveillance, exactement le risque qu'on voulait éviter. Un serveur local mal exposé est plus dangereux qu'un hébergement bien tenu.
Parce que les applications se parlent. Un bon de travail traverse l'inspection, le système qualité et la métrologie en n'étant saisi qu'une seule fois. Multiplier les installations locales, c'est réintroduire la synchronisation manuelle — le problème même qu'on prétendait résoudre.
Parce que la souveraineté n'exige pas la proximité. C'est la confusion la plus répandue. « Chez nous » rassure physiquement, mais ce qui protège une donnée, c'est le pays où elle est stockée, le droit qui s'y applique et la liste des personnes qui peuvent la lire. Hébergé à Montréal sous le droit québécois, ce n'est pas moins sous votre contrôle qu'un serveur dans le local électrique — c'est souvent davantage, parce que c'est écrit, journalisé et vérifiable.
La contrepartie : trois engagements vérifiables
Refuser l'installation locale m'oblige à quelque chose. Si vos données ne sont pas physiquement chez vous, alors il faut que trois choses soient vraies, et contrôlables par vous.
Vos données restent au Canada. Base de données et fichiers hébergés à Montréal, choisi au moment de créer chaque service — pas ajouté après coup, parce que cette décision est irréversible. Ce que la loi québécoise exige, nous ne l'appliquons pas comme une contrainte subie : c'était l'architecture dès la première ligne.
L'IA reste cantonnée et réduite. Les quatre usages du tableau, sur des fragments désignés par un humain, sans droit de décision ni d'écriture, et sans servir à entraîner quoi que ce soit. Si cette liste s'allonge un jour, elle s'allongera par écrit.
Vous partez avec tout, quand vous voulez. C'est le seul engagement qui remplace vraiment la possession du serveur : l'export complet de vos données dans des formats lisibles, à tout moment, sans négociation. Le nuage inquiète pour une raison légitime, la peur de l'otage. On y répond par la réversibilité, pas par la localisation. Un fournisseur qui héberge vos données mais vous laisse partir avec est moins risqué qu'un logiciel installé chez vous dont les données sont enfermées dans un format que personne ne sait relire.
Les questions à poser à n'importe quel fournisseur
Vous n'avez pas à me croire sur parole, et ce serait une mauvaise habitude. Ces quatre questions se posent à n'importe qui vous vend un logiciel qui parle d'IA. Les réponses vagues sont elles-mêmes une réponse.
Premièrement : à quels endroits exactement un modèle touche mes données, et qu'est-ce qui lui est envoyé ? Une réponse précise ressemble à un tableau. Une réponse floue signifie que personne n'a fait l'inventaire. Deuxièmement : qui décide, lui ou moi ? Cherchez l'endroit où un humain valide avant que la donnée existe. Troisièmement : que se passe-t-il quand il se trompe ? Un fournisseur qui ne parle pas de correction humaine n'a pas travaillé le cas d'erreur. Quatrièmement : est-ce que le logiciel fonctionne encore si l'IA est indisponible ? Chez nous, oui — l'inspecteur saisit ses cotes à la main, comme avant, et tout le reste continue. Un logiciel qui s'arrête sans son modèle n'est pas un logiciel de métier, c'est une démonstration.
Et si vous voulez la question à cinq cents dollars, celle qui règle le débat du nuage : si je pars dans deux ans, qu'est-ce que j'emporte, dans quel format, et combien de temps ça prend ?
Le débat « nuage ou serveur local » est presque toujours mal posé. Ce n'est pas une question d'endroit, c'est une question de contrôle : savoir ce qui sort, savoir qui décide, et pouvoir partir. Un atelier qui obtient ces trois réponses par écrit est mieux protégé qu'un atelier qui possède une machine dans un placard, et j'ai raconté ailleurs la discipline qui rend ces réponses tenables.
Les convictions défendues dans cet article sont celles 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.