# Qu’était XCON, le système expert qui configurait les ordinateurs de Digital Equipment Corporation?

Date: 2019-12-05 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/xcon-systeme-expert-dec/

**Answer:** XCON, aussi appelé R1, était un système expert à base de règles écrit par John McDermott à l’Université Carnegie-Mellon, qui vérifiait et complétait les commandes de clients pour les ordinateurs VAX de Digital Equipment Corporation et indiquait comment les pièces s’assemblaient. Mis en service régulier par DEC en 1980, il a été l’un des premiers programmes d’IA à se rentabiliser dans les affaires courantes, et il a contribué à lancer l’essor commercial des systèmes experts.

À la fin des années 1970, acheter un mini-ordinateur n’avait rien à voir avec l’achat d’un portable. Le client qui commandait un VAX à Digital Equipment Corporation (DEC) choisissait le processeur, la mémoire, les lecteurs de disque, les terminaux, les armoires et les câbles pour relier le tout, souvent pièce par pièce. Les vendeurs n’étaient pas toujours des experts techniques; les commandes arrivaient donc régulièrement sans un câble ou un contrôleur, ou avec des pièces qui ne s’assemblaient pas. Chaque erreur entraînait des retards, des clients mécontents et des pièces de remplacement gratuites.

La réponse de DEC a été un programme informatique qui connaissait les règles d’assemblage d’un VAX. Son auteur, John McDermott, de l’Université Carnegie-Mellon à Pittsburgh, l’a appelé R1; chez DEC, il est devenu XCON, abréviation de « expert configurer » (configurateur expert). À partir de janvier 1980, il a été utilisé couramment dans l’organisation de fabrication de DEC, d’abord à l’usine de l’entreprise à Salem, au New Hampshire.

## Ce que faisait XCON

La tâche de XCON, telle que McDermott la décrivait, comportait deux volets. D’abord, il lisait la commande d’un client et remarquait ce qui manquait, en ajoutant les composants nécessaires au fonctionnement du système. Ensuite, il produisait des schémas montrant où chaque composant devait aller : quelle armoire, quelle fente, quel câble. Les techniciens se servaient de ces schémas pour assembler la machine.

Le VAX-11/780 laissait beaucoup de place à l’erreur. Un système typique comptait environ 90 composants, et la base de données qu’utilisait XCON en décrivait 420 différents, chacun avec environ huit propriétés qui comptaient pour la configuration, comme la taille, les besoins en alimentation ou le nombre d’appareils qu’il pouvait prendre en charge.

## Comment il fonctionnait

XCON était un **système de production**, un programme formé de nombreuses règles indépendantes. Chaque règle a des conditions et des actions : si la situation courante correspond aux conditions, la règle se « déclenche » et ses actions modifient la situation. Le programme tient une **mémoire de travail** qui décrit la configuration en cours, et il cherche sans cesse une règle qui correspond, la déclenche, puis cherche de nouveau.

Dans l’article de McDermott de 1980, R1 comptait 772 règles, dont 480 portaient sur la configuration et les autres sur des tâches plus générales. Il était écrit en OPS4, un langage pour systèmes de production créé à Carnegie-Mellon. Un résumé très lu indique plutôt OPS5, un proche parent.

L’astuce résidait dans la méthode que McDermott appelait **Match** (appariement). Bien des programmes d’IA de cette période devinaient une solution, la testaient et revenaient en arrière en cas d’échec. Les règles de XCON contenaient assez de connaissances pour reconnaître, à chaque étape, un geste qui menait à coup sûr vers une configuration valide. Il avait donc rarement à revenir en arrière. Dans les essais de l’article, il traitait chaque commande en environ 2,5 minutes de temps machine, en déclenchant un millier de règles environ.

Voici une image simplifiée de la façon dont quelques déclenchements de règles construisent une commande (une illustration, pas les vraies règles de XCON) :

| Étape | La mémoire de travail indique | Règle qui se déclenche | Résultat |
|---|---|---|---|
| 1 | La commande comprend un lecteur de disque, sans contrôleur | « Si un lecteur de disque n’a pas de contrôleur, en ajouter un » | Contrôleur ajouté |
| 2 | Contrôleur ajouté, pas encore placé | « Si un contrôleur n’est pas placé et qu’une fente du bon type est libre, l’y mettre » | Contrôleur placé dans une fente |
| 3 | Fente occupée; l’armoire est maintenant pleine | « Si une armoire est pleine et qu’il reste des pièces, ajouter une armoire » | Deuxième armoire ajoutée |
| 4 | Plus rien à placer | « Si toutes les pièces sont placées, dessiner le plan » | Schéma pour les techniciens |

Les vraies règles de XCON étaient plus longues et très précises. L’une d’elles, donnée en anglais dans l’article, porte sur l’attribution d’un lecteur de disque à double accès à deux contrôleurs quand aucun des deux n’a encore d’appareil.

> **À essayer :** écrivez cinq règles « si… alors » pour remplir un sac d’école (par exemple : « Si un portable est dans le sac, ajouter son chargeur »). Appliquez-les à la main à une liste d’objets et notez les moments où il vous fallait une règle que vous n’aviez pas écrite. Ce manque, c’est le problème de l’« acquisition des connaissances » en miniature.

## Sa construction et ses essais

Le développement a commencé en décembre 1978. McDermott a passé cinq ou six jours à se faire enseigner la configuration des VAX, a lu les deux manuels de configuration de DEC et, en quatre mois environ, a écrit une première version de moins de 200 règles. Elle traitait les commandes simples, mais faisait beaucoup d’erreurs sur les commandes complexes. Pendant les quatre mois suivants, les experts en configuration de DEC ont vérifié ses résultats et signalé les erreurs; chaque critique menait à une règle corrigée ou scindée, et ses connaissances ont presque triplé.

En octobre et en novembre 1979, six experts ont examiné son travail sur 50 commandes, en consacrant une à deux heures à chacune. Ils ont trouvé 12 connaissances erronées; une fois celles-ci corrigées, les 50 commandes sont sorties justes. Au milieu de 1980, R1 avait configuré plus de 500 commandes, et le personnel des ventes de DEC commençait aussi à s’en servir.

L’histoire derrière le nom est une blague sur le nouveau titre d’emploi d’« ingénieur de la connaissance » (*knowledge engineer*). Dans une note de bas de page de l’article, McDermott écrit que quatre ans plus tôt, il ne pouvait même pas prononcer l’expression; la version populaire lui fait dire que trois ans plus tôt, il ne savait même pas l’épeler.

## Pourquoi il a compté

XCON a prouvé qu’un programme d’IA pouvait accomplir un travail quotidien et précieux au sein d’une grande entreprise. Il a grandi jusqu’à environ 2 500 règles et, en 1986, il avait traité quelque 80 000 commandes avec une exactitude de 95 à 98 %. Les estimations de sa valeur varient : l’une évalue les économies de DEC à environ 25 millions $ US par année, une autre à 40 millions $ US sur six ans. DEC l’a fait suivre de XSEL, qui aidait les vendeurs à configurer les systèmes avec les clients, et de XSITE, qui planifiait le local où un ordinateur serait installé.

Arrivé juste après les compressions de financement des années 1970, XCON a contribué à faire des systèmes experts une industrie. En 1999, l’article de McDermott a reçu le prix AAAI Classic Paper Award.

## Qu’est-il arrivé aux systèmes experts après XCON?

Tout au long des années 1980, les entreprises se sont lancées dans la course pour construire les leurs. Des « coquilles » logicielles (*shells*) facilitaient l’écriture de systèmes à base de règles, des ordinateurs Lisp spécialisés étaient vendus pour les faire tourner, et des gouvernements lançaient des programmes comme le projet d’ordinateurs de cinquième génération du Japon.

Puis les limites sont apparues. Les bases de règles comme celle de XCON demandaient un entretien constant à mesure que les produits changeaient, et chaque nouvelle règle pouvait interagir avec les anciennes. Ces systèmes ne pouvaient pas apprendre par eux-mêmes et se comportaient mal devant des entrées inhabituelles, une faiblesse qu’on qualifie de « fragilité ». Le marché des machines Lisp s’est effondré en 1987, et un deuxième hiver de l’IA a suivi à la fin des années 1980 et au début des années 1990.

Les systèmes à base de règles n’ont pas disparu pour autant. En 2019, des moteurs de règles fonctionnent encore discrètement dans bien des outils d’affaires, comme des configurateurs de produits très semblables à XCON. Ce qui a changé, c’est que les progrès qui font les manchettes en IA sont passés à des systèmes qui apprennent leurs règles à partir de données au lieu de les faire écrire à la main par des experts.

## Sources

- R1: An Expert in the Computer Systems Domain: https://aaai.org/Papers/AAAI/1980/AAAI80-076.pdf
- Xcon: https://web.archive.org/web/20191122032045/https://en.wikipedia.org/wiki/Xcon
- AI winter: https://web.archive.org/web/20190501000000/https://en.wikipedia.org/wiki/AI_winter