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, c'est-à-dire l'essentiel, est du logiciel ordinaire.
Vient ensuite la question qu'un client m'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 ? La bonne réponse n'a rien à voir avec l'IA. Le nuage, c'est d'abord une question de coût : tout ce qui entoure le logiciel est partagé entre les clients, donc chacun en paie une petite part. Sur un serveur chez vous, c'est possible, et nous le faisons. Mais rien n'y est partagé, et ça se voit sur la facture.
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
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. 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.
Le nuage n'a jamais été une question d'IA
Voilà la conclusion logique de tout ce qui précède : l'IA n'est pas l'argument du nuage. Elle ne représente que quelques pourcents du logiciel et ne travaille que sur des fragments. Si le nuage se justifie, c'est ailleurs.
Il se justifie par la mutualisation. Autour de n'importe quel logiciel de métier, il y a un travail que personne ne voit et qui coûte cher : un serveur qui tourne jour et nuit, des sauvegardes vérifiées chaque nuit, les correctifs de sécurité appliqués dès leur sortie, les mises à jour du logiciel, la surveillance, quelqu'un qui sait restaurer la base le matin où un disque meurt. En SaaS, ce travail est fait une fois, pour tous les clients en même temps. Chacun en paie une petite part. C'est ce qui permet de vendre à un atelier de trente personnes un logiciel qu'il n'aurait jamais pu faire tenir seul.
C'est aussi ce qui explique pourquoi je n'ai jamais vu de vrai système qualité en PME. Un logiciel qui relie les non-conformités aux processus et les instruments aux inspections n'était pas techniquement impossible en 2005. Il était long à écrire et cher à faire vivre, trop cher pour un atelier de trente personnes s'il devait en porter seul tous les frais. Deux choses ont changé : le coût de fabriquer ce logiciel, et la possibilité d'en partager les frais d'exploitation entre beaucoup d'ateliers.
Le nuage ne vend pas de l'intelligence. Il vend une facture partagée.
Et sur un serveur chez vous ?
On me le demande souvent, surtout des directeurs qualité prudents, ce qui est plutôt bon signe. La réponse est oui : nous installons aussi nos logiciels sur un serveur dans l'atelier. Mais il faut savoir ce qu'on achète, parce que ce n'est pas le même produit au même prix.
Rien n'est partagé. Le serveur, son installation, sa mise en service, ses sauvegardes, ses mises à jour et son suivi ne servent qu'à un seul client. Tout ce que le nuage répartit entre tous retombe sur une seule facture. C'est mécanique : un serveur pour un atelier coûte plus cher qu'une part de serveur pour cent ateliers.
Les mises à jour se font une installation à la fois. En SaaS, une correction arrive chez tout le monde le même jour. Sur serveur, chaque installation se met à jour séparément, avec son propre calendrier et ses propres vérifications. C'est du travail en plus, et il se paie.
Quelqu'un doit s'en occuper sur place. Une panne de courant, un disque plein, un poste qui ne voit plus le serveur : sur un serveur local, ces problèmes arrivent chez vous et se règlent chez vous. Il faut savoir qui appelle qui, et à quelle heure.
L'analyse des plans passe quand même par Montréal. Même sur serveur, la lecture automatique des cotes utilise le même service d'analyse, avec les mêmes fragments désignés par l'inspecteur. Le serveur local garde vos données chez vous ; il ne fait pas disparaître le tableau du début de cet article.
Ce n'est pas un plaidoyer contre le serveur local. Il a de vraies raisons d'être : un donneur d'ordres qui exige par contrat que les données restent dans la bâtisse, un atelier qui a déjà un informaticien et une salle de serveurs, une politique interne qui ne se négocie pas. Dans ces cas-là, c'est le bon choix, et il vaut ce qu'il coûte. Ce que je veux éviter, c'est qu'un atelier le choisisse en croyant faire une économie. C'est presque toujours l'inverse.
Trois engagements, dans les deux cas
Nuage ou serveur, trois choses doivent être vraies, et contrôlables par vous.
Vous savez où sont vos données. En nuage, la base de données et les fichiers sont hébergés à Montréal, un choix fait au moment de créer chaque service et pas ajouté après coup, parce que cette décision est irréversible. Sur serveur, elles sont chez vous. Dans les deux cas, 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. 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 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 : 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.
Quatrièmement, celle qui règle le débat du nuage : qu'est-ce qui est partagé entre vos clients, et qu'est-ce que je paierais seul sur un serveur ? Un fournisseur qui ne sait pas répondre n'a pas fait le calcul, ou ne veut pas vous le montrer.
Et la dernière, qui vaut dans les deux formules : 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'IA, ni même vraiment d'endroit. C'est une question de coût et de contrôle : savoir ce que vous payez seul, savoir ce qui sort, et pouvoir partir. 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.