Quand l'outil sait faire, où se trouve encore l'expertise ?

L’expertise ne disparaît pas lorsqu’on automatise le geste. Elle se déplace.

Il y a quelques années, lorsqu’un ingénieur concevait une pièce mécanique, il devait maîtriser son outil de CAO, construire sa géométrie, définir ses contraintes et vérifier son résultat.

Aujourd’hui, une IA peut générer une partie de cette géométrie, produire du code de conception paramétrique et parfois même préparer les éléments nécessaires à sa fabrication.

Alors, une question se pose : que reste-t-il à l’ingénieur ?

La réponse paraît simple : son expertise.

Mais où se trouve-t-elle exactement ?

Savoir faire et savoir quoi faire #

Prenons un exemple.

Je souhaite concevoir une pièce mécanique destinée à accueillir une carte électronique.

Je peux aujourd’hui demander à une IA de générer du code de CAO paramétrique à partir de contraintes : dimensions, tolérances, positionnement des composants, interfaces mécaniques, procédés de fabrication.

Le modèle obtenu peut être modifié, vérifié, puis transmis à une imprimante 3D.

Une partie importante du travail de modélisation est alors automatisée.

Mais l’IA ne détermine pas nécessairement quelles contraintes sont pertinentes.

Elle ne sait pas spontanément pourquoi une tolérance particulière est nécessaire, pourquoi une pièce doit pouvoir être démontée, pourquoi tel matériau est préférable ou pourquoi une solution pourtant parfaitement modélisée risque de poser problème à l’industrialisation.

Ces éléments relèvent de la compréhension du produit et de son environnement.

La compétence ne consiste donc plus seulement à réaliser le modèle, mais à définir ce que le modèle doit respecter et à vérifier qu’il y répond.

Et cette distinction dépasse largement la CAO.

L’automatisation déplace le travail #

En électronique, nous pouvons automatiser une partie de la génération de netlists, de l’analyse de schémas ou de l’optimisation du routage.

En développement logiciel, une IA peut produire du code à partir de spécifications.

En gestion de projet, elle peut rapprocher des décisions, identifier des dépendances ou suivre des actions.

À chaque fois, une partie des opérations autrefois réalisées manuellement peut être déléguée.

Mais cette délégation fait apparaître un autre travail.

Il faut formaliser les règles.

Définir les contraintes.

Organiser les données.

Construire les interfaces.

Vérifier les résultats.

Identifier les erreurs que l’automatisation ne sait pas détecter.

Et surtout, continuer à prendre les décisions.

Car automatiser une tâche n’implique pas nécessairement d’automatiser le raisonnement qui permet d’en apprécier la pertinence.

Le risque de confondre production et compétence #

Pendant longtemps, nous avons évalué une compétence à travers la capacité d’une personne à produire quelque chose.

Un développeur écrit du code.

Un dessinateur réalise des plans.

Un ingénieur électronique conçoit des circuits.

Un chef de projet construit et suit des plannings.

Ces activités restent importantes.

Mais lorsqu’un outil peut réaliser une partie de cette production, elles ne suffisent plus à caractériser l’expertise.

Prenons deux personnes disposant du même outil d’IA.

La première lui demande de produire une solution et accepte le résultat parce qu’il semble fonctionner.

La seconde sait interroger les hypothèses, préciser les contraintes, détecter les incohérences, confronter les résultats à la réalité et déterminer les vérifications nécessaires.

Elles utilisent le même outil.

Pourtant, elles n’ont pas nécessairement la même capacité à produire un résultat fiable.

L’accès à un outil ne donne pas automatiquement la compétence nécessaire pour juger ce qu’il produit.

Et c’est probablement l’un des enjeux majeurs de l’intégration de l’IA dans les métiers techniques.

Peut-on automatiser son propre savoir-faire ? #

Depuis plusieurs années, je construis des outils pour réduire les tâches répétitives dans mes activités.

Progressivement, ces outils ont commencé à partager leurs données, puis leurs fonctions.

L’arrivée des modèles d’IA locaux m’a permis d’aller plus loin en intégrant certaines de mes méthodes de travail à un environnement commun.

Mais l’exercice est intéressant pour une autre raison.

Pour qu’un système reproduise une partie de ma manière de travailler, je dois d’abord réussir à la décrire.

Pourquoi est-ce que je vérifie tel paramètre ?

Pourquoi est-ce que je privilégie cette architecture ?

Quels critères me font écarter une solution ?

À partir de quel niveau d’incertitude dois-je arrêter une conception pour réaliser une mesure ?

Autant de questions auxquelles nous répondons parfois presque instinctivement après des années de pratique.

La construction de l’outil oblige à rendre explicite une partie de ce savoir-faire.

Et l’on découvre alors que certaines décisions peuvent être traduites en règles, d’autres nécessitent des données complémentaires et d’autres encore résistent à la formalisation.

Cette dernière catégorie est particulièrement intéressante.

Elle rappelle que tout ce que nous savons faire n’est pas nécessairement quelque chose que nous savons expliquer ou automatiser.

Une automatisation efficace ne supprime pas la responsabilité #

Lorsqu’une IA génère un modèle mécanique, qui garantit qu’il est fabricable ?

Lorsqu’elle propose un routage PCB, qui vérifie les contraintes électriques, thermiques ou de compatibilité électromagnétique ?

Lorsqu’elle génère du code embarqué, qui s’assure que le comportement respecte les exigences du système ?

Ces questions ne disparaissent pas parce que la production devient plus rapide.

Elles deviennent même essentielles lorsque le volume de production augmente.

Un outil capable de générer dix fois plus de solutions ne représente pas nécessairement un progrès si nous ne sommes pas capables de les vérifier correctement.

L’efficience ne consiste pas simplement à produire plus vite.

Elle consiste à obtenir un résultat exploitable avec moins de ressources, sans dégrader le niveau de confiance nécessaire à son utilisation.

Cela suppose de considérer la vérification, la validation et l’arbitrage comme des parties intégrantes du travail, et non comme des formalités ajoutées après la génération.

Finalement, qu’est-ce qu’on transmet à la machine ? #

Une méthode ?

Des connaissances ?

Une expérience ?

Une succession de décisions passées ?

Probablement un peu de tout cela.

Mais il faut distinguer deux choses : un système capable de reproduire certaines décisions dans des situations connues et un système capable de déterminer si ces décisions restent pertinentes dans une situation nouvelle.

C’est dans cet écart que se situe une partie de la difficulté.

Nous pouvons automatiser des gestes, formaliser des règles, capitaliser des connaissances et construire des systèmes capables de les mobiliser.

Nous pouvons même obtenir des résultats que nous aurions mis beaucoup plus de temps à produire manuellement.

Mais nous devons rester capables de comprendre ce qui a été produit, pourquoi cela fonctionne et dans quelles conditions cela pourrait cesser de fonctionner.

L’expertise n’est pas seulement ce qui permet de produire une solution.

C’est aussi ce qui permet de savoir si cette solution est la bonne.

Et plus nos outils deviennent capables de produire à notre place, plus cette distinction devient importante.