IA et Programmes

Les programmes d'IA seront bientôt transformés de sorte que l’on ne pourra bientôt plus les reconnaître. Ainsi, il n’y a pas de raison de penser qu’une amélioration d’un programme d'IA particulier obtiendra l’amélioration d’un système logiciel plus global.

De nouvelles techniques de calcul apparaissent, d’autres deviennent plus accessibles lorsque les capacités matérielles augmentent, et dès lors de nouveaux programmes surviennent, qui devront être intégrés à l’existant en brouillant ses frontières. En outre, on sait que la “loi de Moore” (qui procède du constat empirique que le volume d'informations traité par les puces informatiques double tous les deux ans) met en évidence l’augmentation rapide des capacités de calcul du hardware. Il ne faut donc pas penser l’IA comme un objet, ou un artefact stable.

L’IA, c’est avant toute chose, du programme logiciel qui aura besoin de matériel informatique. Or ces dispositifs sont toujours sujet à des évolutions (mise à jour de sécurité, de compatibilité, forking à des fins commerciales, clustering, ré-architecturation en containers etc.) Ces nécessités d’évolution des fatalités techniques que l’on ne peut ignorer. 

Un autre aspect est à considérer : l’IA d’une certaine manière, change son propre code (avant tout : ses paramètres et poids des vecteurs, mais aussi ses instructions et même ses déclarations de variables.)

Ainsi il ne faut pas considérer l’IA comme un objet caractéristique (comme une chaise) ni même comme un organisme soumis à ses propres lois. C’est une forme de dispositif purement conventionnel et calculatoire, soumis à aucune régularité naturelle.

L'IA est installée comme un logiciel (qu'elle est) sur un ordinateur.

Il faut considérer le lien indéfectible, la continuité réelle et inévitable entre IA, logiciel, instructions, procédures, bureaucratie, et mécanisation des rapports normatifs y compris juridiques. On ne peut pas y échapper, et il paraît extravagant que cette dimension soit très rarement relevée. 

Ceci convoque des problématiques d’intégration horizontale : le programme informatique (y compris celui qui mobilise de l’IA) sera doté de connecteurs (ou API, Application Programming Interface) en amont et en aval, afin de créer un flux d’activités, ou plus exactement d’automatiser des séquences de tâches (workflow). 

Le discours théorique sur l’IA néglige systématiquement cet aspect  : il préfère considérer que l’IA est un outil pour l’utilisateur, et se focalise sur le résultat sur l'écran, solution d'un calcul. Mais bien au contraire : plus d’IA signifie plus de logiciels (puisque l’IA est un logiciel à installer sur d’autres logiciels, en attente de nouveaux logiciels) soit plus d’instructions et procédures, donc plus de bureaucratie. Croyant utiliser un outil, l’utilisateur abonde en fait à un immense système bureaucratique! En outre, on peut penser que la mise en place d’une nouvelle IA n’est possible que dans le cadre d’une organisation déjà fortement bureaucratisée. Les startupers ne s’intéressent qu’à des logiciels de type standalone, mais leur déploiement supposerait une intégration et un interfaçage à l’intérieur de business process existants, pour abonder à ce que l’on désigne souvent par “marché”. Il faudrait encore distinguer l’IA accomplissant une tâche, et la dimension d’automatisation de process à une autre échelle.

Avant d’expliquer les bénéfices théoriques que l’on attend d’une nouvelle IA, on devrait toujours d’abord se demander si ce niveau de bureaucratisation n’est pas déjà trop élevé. L’IA serait alors mobilisée pour réduire la bureaucratie (ce qui supposerait de nouveaux critères d’informatisation) et non pour la renforcer encore plus.

Ceci fait aussi comprendre que l’extrant de l’IA n’est pas forcément une solution pratique fournie par un outil, mais seulement le résultat d’un calcul. ^[1] 

L'IA n'est pas, et ne restera pas stable dans les ordinateurs.

L’intégration verticale (couches logicielles : logiciel utilisateur, middleware, operating system, hardware, data center, système électrique) est à considérer. On peut se référer au modèle OSI ^[1] pour comprendre qu’un traitement informatique (y compris d’IA) réclame le traitement dans différentes couches, ce qui suppose divers niveaux et types de transformation de la donnée.

Les routines d´installation, de test, de déploiement et de mise à jour standardisés, de correction des erreurs (bugs), de récupération, de sécurisation, standardisées et automatisées ou non, sont à prendre en compte. 

Ceci éloigne l’IA du modèle de la calculette (calculatrice déconnectée et non programmable), qui a beaucoup moins de couches, n’est pas intégrée, et dont le programme ne se modifie pas.

Des « effets de bord » (des reconfigurations imprévues, éventuellement invisibles mais en tout cas gênantes) apparaissent souvent en informatique déployée. Ils surgissent en particulier, s’agissant d’IA, du fait des flux de rétroaction (feedback loop) - le flux de sortie dont la fonction est de venir moduler le flux d'entrée.

Nous relevons à ce feedback au moins 3 couples {cible, fonction} usuels   :
1 - {le modèle de L'IA, entraînement}   : c'est ici que l'on retrouve les effets de bord les plus imprévisibles. Par exemple, on continue l'entraînement du modèle avec comme source les entrées utilisateurs ou des requêtes web. Ceci provoque ce que l’on peut nommer une « dérive des modèles »
2 - {l'utilisateur, médiation sociale}   : la censure des sorties selon des règles donnés (morales, législatives, fact checking, etc). Par exemple, l'utilisateur demande la recette d'explosif, la surcouche de l'IA remplace la réponse par un message prédéfini.
3 - {le système, remontée d'information}   : autrement dit du "renseignement 2.0". Par exemple, un mail est envoyé aux autorités pour informer que l'utilisateur précédant cherche absolument à créer des explosifs.

Peut-on y remédier ?

Les points 2 et 3 sont “auditables” (on peut s’en occuper si l’on a le temps) puisque advenant dans la surcouche. Il s'agit concrètement de lignes de code sur lesquelles on peut faire des tests unitaires, techniques, fonctionnels ou autres. Ainsi dans certains cas, lorsque l’on dispose concrètement des ressources adéquates, l’effet de bord est maîtrisable.

Le point 1 est plus complexe à auditer   : le test unitaire peut donner quelques indications mais n'assure en rien la conformité, puisque l’effet de dérive est continu. Il ne s'agit plus ici de questionner le traitement de la donnée flux par flux mais globalement, or les systèmes récents sont basés sur des couples d'entrée pour être performants. Il n'est pas possible d’investiguer les couples (“brutforcer”) un par un, parce qu’il y a trop entrées et résultats possibles.

L’IA n’est pas un outil : les outils ne sont pas soumis à des effets de dérive propagatrice et effets de bord (par exemple : si j’utilise mon marteau, cela n’altère pas la performance du vôtre).

Les outils sont alors optimisables unitairement, et l’amélioration globale est bien au moins égale à la somme de ces améliorations locales (si tous les marteaux fabriqués sont plus efficients, on peut espérer que tous les clous seront plus vite plantés). 

Les animaux, eux, sont également “optimisables” : on peut vouloir modifier l’ADN d’une espèce de moustiques dans une région pour la rendre moins agressive. L’amélioration globale est possible (du point de vue du confort lors des pique-nique) : si tout se passe correctement, les lois de la nature vont continuer d’opérer globalement, en propageant les “bénéfices” d’une optimisation locale. Par exemple, les prédateurs vont adapter leurs comportements au vu de la modification opérée. L’homme a dès lors appris à “surfer” sur les lois de la nature avec la planche de son travail et de ses outils - en tout cas, c’est l’impression qu’il peut en avoir-.

On ne peut pas attendre la même chose pour l’IA, dont les programmes ne sont que du code, soit des conventions écrites : il n’y a aucune magie, aucune loi naturelle qui agit spontanément pour réécrire mieux les prescriptions partout en vue d’un équilibrage global.

Ainsi, un problème majeur avec les programmes d’IA, c’est que le reparamétrage automatique et les difficultés d’intégration et de maintenance causent des transformations internes du logiciel, des effets de dérive, et des effets de bord. De la sorte, les solutions obtenues dans l’ordinateur sont toujours un peu moins bonnes qu’espérées à cause des paramétrages et calages qu’elles nécessitent.

En-dehors de l’ordinateur, il faut vraiment compter sur la chance pour imaginer que ces imprévus vont toujours s’avérer favorables. A l'inverse: à l’intérieur de l’ordinateur, si l’on dispose d’un temps illimité, rien d’imprévu ne peut se passer.