Robotique: Articles

Un travail de stabilisation du bipède très impressionnant.



Pour en savoir plus sur le projet : http://www.iit.it/en/robots/coman.html
Lire l'histoire →    0 commentaires   

Très bel "happening" réalisé ce week-end dans le ciel de Londres par le laboratoire autrichien Ars Electronica :

Un trentaine de drones ont occupé durant la nuit le ciel londonien pour former le célèbre logo de la saga.
Magnifique opération de séduction pour les fans de la série, brillante opération de communication décidée par le studio de production du prochain film Star Trek : Star Trek Into Darkness, sortie en France en Mai 2013.

Il ne manquait plus qu'en background sonore le titre "London Skies" par Jamie Cullum, et là le summum de la classe était atteint!




Pour en savoir plus, pour les germanophones :
http://www.aec.at/ae...xels-in-london/
Lire l'histoire →    0 commentaires   

Que penser du nouveau programme de télé-réalité américain Robot Combat League, diffusé sur la chaîne Syfy?

Le concept : des combats de robots humanoïdes, contrôlés par des humains via des exosquelettes.
Un seul survivant humanoïde doit rester à la fin de la compétition, avec 100 000 USD à la clef pour l'équipe gagnante.
Les participants à cette compétition de "robotique" sont des hobbyistes DIY comme vous, mais aussi des scientifiques de métier (NASA etc...), des militaires, des sportifs.





Ridicule? Mauvaise publicité pour la robotique? Qu'en penser?
Participeriez-vous en tant que roboticien amateur à un tel programme si une société de production française vous le proposait?
Lire l'histoire →    3 commentaires   

Motricité exceptionnelle, design, précision, robustesse : le bras robotisé 'Jaco' de la société montréalaise Kinova est un beau produit aux multiples applications potentielles, en premier lieu biensûr pour l'assistance des personnes en fauteuil motorisé souffrant d'une perte d'autonomie au haut du corps.

Vidéo prise le 20 mars 2013 sur le salon Innorobo


Lire l'histoire →    0 commentaires   

Video enregistrée le 21 mars 2013 sur le salon Innorobo par Robot-Maker.com



La main de la société londonienne Shadow Robot (fondée en 1987, ce qui en fait l'une des plus anciennes sociétés robotiques britanniques) est certainement l'une des mains humanoïdes les plus avancées du marché, si ce n'est la plus avancée.
Superbe dextérité, pas moins de 129 capteurs.
Lire l'histoire →    0 commentaires   

Le chien de Boston Dynamics devient de plus en plus agressif. Maintenant, il lance des parpaings!
Merci pour cette avancée dans la robotique de service, Boston Dynamics!


Lire l'histoire →    1 commentaires   

Bien que ça ne soit pas purement un robot autonome mais un véhicule commandé, voici la dernière invention japonaise, qui a de quoi faire rêver !


Lire l'histoire →    0 commentaires   

En tant que membre assidus de ce forum, vous connaissez à coup sûr NAO, le robot humanoïde d’Aldebaran Robotics. Je suis sûr qu’en plus vous avez un petit faible pour lui. Et bien nous aussi !

Quand nous avons eu notre premier NAO, on a tout de suite été convaincu par la qualité du produit, par la vision d’Aldebaran Robotics et une grande quantité d’idées ont tout de suite germé dans nos cerveaux.
En parallèle, nous étions un peu déçus de ne trouver que des chorégraphies et danses comme exemple d’usage de NAO, même si elles sont très bien faîtes et qu’elles demandent du temps pour être réalisées. NAO pouvait faire plus que cela.

En début de cette année, nous avons donc décidé de créer un premier comportement interactif où NAO utilisait réellement ses capacités humanoïdes : le jeu de Puissance 4.

Après en avoir parlé avec Sébastien, le Webmaster de Robot-Maker et selon sa suggestion, voici un petite présentation de l’envers du décor, à savoir comment fonctionne techniquement ce comportement.
Avant toute chose, si vous voulez voir les vidéos de NAO qui joue au Puissance 4, voici le lien : http://www.generatio...gram-nao-robot/



Nous appelons une séquence l’ensemble des tâches à réaliser par le robot NAO pour mettre un jeton et revenir à son état initial. Nous n’abordons pas dans cet article la reconnaissance faciale de l’interlocuteur humain, la localisation de celui-ci, la reconnaissance vocale et enfin le moteur d’émotions. Pour tout cela, rendez-vous sur le site qui décrit le comportement.

http://www.generatio...gram-nao-robot/

Séquences de jeu Puissance 4 pour NAO
Voici les différentes étapes d’une séquence :

• Trouver la planche de jeu dans son environnement

• Analyser la planche

• Déterminer le coup à jouer

• Déterminer la distance à la planche

• Avancer vers la planche

• De positionner correctement en fonction de la colonne jouée

• Mettre le pion

• Reculer

• Constater la réussite de la mise de la pièce

La première difficulté que nous avons constatée est que la planche de jeu fait à peu près 2/3 de la hauteur de NAO. Ce qui fait que pour voir toute la planche de jeu et ainsi savoir où il en est, il doit reculer à une certaine distance (imaginez une planche de jeu qui fasse 2/3 de votre hauteur !).

Donc première étape, trouver la planche de jeu. On se base sur les couleurs et la forme. Nous avons bataillé sur ce point et essayé plusieurs algorithmes différents. A chaque fois, et c’est vrai pour tout, nous devions choisir un bon compromis entre efficacité et temps de calcul. Nous avions à disposition des algorithmes très efficaces mais qui prenaient 30 secondes sur NAO, c’était donc inutilisable en pratique. Nous avons essayé quelques algorithmes disponibles dans des librairies graphiques et finalement, nous avons réalisé notre propre algorithme qui utilise la technique des filtres particulaires Bayésiens. Si certaines personnes sont intéressées par ces techniques, qu’elles nous écrivent, nous avons une personne qui adore parler de vision artificielle .

Une fois la planche positionnée, il faut que NAO l’analyse et déduise la position des jetons déjà en place s’il y en a. Un simple algorithme de couleur appris grâce à un algorithme génétique donne de bonnes performances. Tous les algorithmes de vision artificielle sont écrits en C++.



La troisième étape est une étape très simple, elle consiste à déterminer quel est le coup que NAO va jouer. L’algorithme utilisé est un algorithme de minimax que l’on apprend à l’école quand on a des cours d’intelligence artificielle, on n’a rien inventé de ce point de vue.

Ensuite, c’est là que ça se corse. Il faut estimer la distance à la planche et faire en sorte que NAO se déplace vers celle-ci. De plus, le déplacement est différent en fonction de la colonne choisie. Si NAO choisit la colonne la plus à gauche ou la colonne la plus à droite, il ira directement se positionner au bon endroit. Pour déterminer la distance, on utilise de la trigonométrie toute simple à partir de l’image saisie par NAO. Les Bumpers dans les pieds sont mis à contribution afin d’arrêter la marche si d’aventure il heurte la planche.
NAO est ensuite capable de se déplacer latéralement pour se placer de manière optimale. Pour ce faire, nous utilisons une combinaison d’analyse d’image (repère les coins de la planche), trigonométrie et déplacement. Dans ce cas précis, la trigonométrie utilisée est non triviale, croyez nous…

Enfin, l’instant fatidique de la mise de pièce ! D’abord le robot demande à ce qu’on lui donne la pièce. A ce jour, ses doigts ne lui permettent pas de saisir un jeton posé sur le sol. On ne désespère pas pouvoir y arriver un jour en fonction des évolutions matérielles de NAO. Le dépôt de jeton se fait par une boucle d’asservissement visuel conjugué à de la cinématique inverse de manière à ce que le robot sache quelle est sa position par rapport à la planche. On débute par des mouvements grossiers et au fur et à mesure que l’on se rapproche de la fente de la colonne, on affine les traitements.

Pour les lecteurs de Robot-maker uniquement, c’est un scoop, voici la capture d’écran de développement du comportement. Nous utilisons Chorégraphe, l’outil de programmation graphique d’Aldebaran pour orchestrer tous les processus entre eux, du Python pour paramétrer quelques éléments simples et pas mal de modules C++.



La programmation robotique nécessite en effet de pouvoir changer d’échelle de développement comme cela et donc une interface graphique de gestion de flux est totalement nécessaire au même titre qu’un bon vieux éditeur de code C++. Il serait utopique de vouloir tout gérer en code. D’ailleurs, si l’on regarde les autres plateformes de développement (URBI, ROS, MSRS), ils ne se trompent pas non plus et intègrent tous ces outils qui manipulent le code à différentes échelles.

La version 0.4 du comportement
La première version rendue publique est la version 0.4, c’est notre première version totalement fonctionnelle. Dans les prochaines versions, nous allons améliorer la robustesse aux conditions visuelles, diminuer le temps de chaque séquence et améliorer les fonctions d’interaction homme-robot qui sont, pour nous, tout aussi importantes, sinon plus, que le jeu en lui-même.

Un mot sur nous : Génération Robots est un site de commercialisation de robots programmables (http://www.generationrobots.com). Nous proposons également des formations en robotique et allons bientôt lancer notre propre marque de capteurs et accessoires pour robots programmables. En plus de ces activités, une équipe de développement développe en propre des comportements pour les robots et propose ses services à des entreprises ou fabriquant de robots. La partie service de Génération Robots se nomme Humarobotics (http://www.humarobotics.com).

Nous sommes passionnés par ce que nous faisons et nous adorons partager cette passion, alors si vous avez des questions, des remarques, des encouragements, n’hésitez pas à commenter cet article.
Merci à Robot-Maker de nous avoir proposé cette tribune.

@GenerationRobot
Lire l'histoire →    2 commentaires   

Comment parler de Robotique sans évoquer ASIMO de la firme japonaise Honda...

Ce robot humanoïde dont la première version date de 2000 est issu d'une lignée de prototypes (EX,PX,P1,P2,P3) initiée par Honda dès 1986. Il a et fait encore rêver bon nombre de roboticiens en herbe et il semble que ce ne soit pas fini...
En effet, Honda a présenté, le 8 novembre 2011 dernier, une nouvelle version d'Asimo (la 5ème) plus agile et plus intelligente:

Si dans sa précédente version, Asimo avait appris à courir tout droit, en rond ou en zig-zig avec une fluidité et agilité impressionnante, Asimo sait aujourd'hui sauter à cloche-pied et à pieds joints.
Ses mains ont aussi été améliorées: Asimo maitrise dorénavant mieux la péhension grâce à la sensation de "touché" apportée par des capteurs de force et tactiles.
- Il sembe malgré tout que cela ne soit rien comparé aux progrès que lui confère sa nouvelle dotation d'"intelligence". En effet, jusqu'à présent, Asimo était téléopéré. Cette époque est révolue. Asimo dispose désormait d'autonomie, de réactivité face à son environnement.
Il reconnait désormais les voix et visages de ses interlocuteurs (plusieurs à la fois...) et est également capable de réagir en fonction du déplacement des personnes autour de lui...

Jugez par vous-même:





Alors merci Honda de continuer à alimenter nos rêves de roboticiens....
Lire l'histoire →    1 commentaires   

L'informatique, une méthode qui n'a pas évolué depuis un demi-siècle

Plus une machine - ou un être vivant - est équipé de capteurs, plus il lui faut d'intelligence pour les exploiter. Ou… plus une machine dispose d'intelligence, plus elle peut s'équiper de capteurs. Choisissez. C'est la poule et l'œuf.
Ce que l'homme a trouvé de mieux pour donner de l'intelligence à une machine c'est, au milieu du 20ème siècle, l'informatique avec ses ordinateurs animés par des programmes. Ceux-ci contiennent une connaissance humaine et la font "tourner" pour obtenir des résultats sans passer par des cerveaux humains. Un programme, c'est une sorte de mécanisme qui produit de l'information. Le problème, c'est que la façon de le produire est toujours la même depuis l'aube de l'informatique ! Un programme, c'est un liste de procédures chargée de résoudre tous les cas qui se présenteront : le procédural. Comme l'ordinateur est considéré comme un idiot (ce qu'il est très loin d'être !), le développeur informaticien se charge d'apprendre la connaissance qui devra être automatisée (l'analyse) puis il imagine un à un tous les cas qui se présenteront et raisonne pour coder la solution à chaque cas. Le codage est nécessaire pour ne pas faire des programmes inutilement gigantesques. Hélas, il réclame une formation poussée aux langages dits informatiques : Java, C++, Pascal, etc. C'est ainsi que toute l'informatique, encore aujourd'hui, est entre les mains d'une "catégorie de personnel" qui protège jalousement son pré-carré…

Au début des années 1970, les chercheurs informaticiens de la planète se sont passionnés pour l'intelligence artificielle, un peu comme une spéculation intellectuelle. Ils imaginaient qu'on pourrait simplifier définitivement les programmes en leur donnant la structure suivante :
1) un "moteur" universel hyper fiable qu'on n'a pas le droit de modifier et
2) une base de connaissance exprimée sous forme de règles SI.. ALORS… en langage courant qui, elle, est le programme. Le moteur raisonnerait sur la base de connaissance pour exécuter le programme, comme le fait un humain qui raisonne à partir de ce qu'il sait. Le programme devenait ainsi une simple base de données... Donc quelque chose de très fiable et facile à modifier. Avec un avantage de plus : il n'avait pas besoin de toutes les données nécessaires pour fonctionner car il savait dialoguer avec ses utilisateurs et leur réclamer pas à pas les données manquantes. Les Américains développèrent ainsi Mycin en 1971, un système expert d'aide au diagnostic médical des maladies du sang. Ce fut probant en partie ! Car en fait, il fallait piloter le moteur pas à pas pour qu'il puisse exécuter correctement les règles dans le bon ordre (utilisation de mérarègles), ce qui imposait le recours à des informaticiens encore plus diplômés ! Les "cogniticiens". Depuis cette date, rien n'a progressé dans le domaine de l'IA. Il faut toujours des informaticiens spécialistes de l'IA pour mettre de l'intelligence dans quelque chose… Cela indispose nettement les industriels mais ils n'ont pas la compétence pour résoudre le problème. Cela n'indispose pas du tout les développeurs informaticiens qui ont la compétence mais ne s'y intéressent pas pour des raisons que vous devinez sûrement… Cela fait donc quarante ans qu'une bonne idée n'a pas progressé d'un millimètre ! C'est assez unique dans l'évolution des technologies, vous ne trouvez pas ?

En fait, en 1985, l'université française avait concrétisé l'idée testée dans Mycin. Elle avait mis au point le 1er système expert universel, doté d'un moteur qui raisonne sur une base de connaissance en clair: "Pandora". Je fus le seul à le remarquer et j'en fis l'apologie dans un article de Science et Vie en mai 1991. Je fus incendié par l'AFIA, l'association des universitaires spécialisés en IA ! Ce qu'ils avaient fait là, affirmaient-ils, c'était nul ! Quant à moi, j'étais un charlot ! Ayant bien vu qu'il y avait un marché, j'ai donc créé ma société, repris leurs idées, développé une méthode de recueil automatique des savoir-faire d'experts et développé un moteur faisant un vrai raisonnement humain sophistiqué. J'ai baptisé cette nouvelle technologie "La Maïeutique". Et, grâce à elle, j'ai réalisé en 1986 le 1er système expert conversationnel utilisé devant le grand public, à Paris et Rennes, pour la Banque de Bretagne. Baptisé "Joséphine", il était très gros (plus de 1000 règles), et fut développé par un cadre non informaticien que j'avais embauché pour l'occasion (Michel Le Seac'h). Cette réalisation, ainsi que les suivantes, me valurent au cours des années des centaines d'articles dans la presse. J'étais une célébrité. Dans le privé ! Dans le public, pas un mot sur mon invention, sur mes clients, sur ma société, sur mes théories. Pas une ligne sur moi dans les ouvrages scientifiques ou les revues officielles. J'étais même interdit de parole dans les colloques IA organisés par les universitaires (à nos frais…). Heureusement, il restait les colloques privés où j'étais accueilli à bras ouverts.

Résultat : vous ignorez que l'IA a percé il y a 25 ans... Depuis, je n'ai cessé d'améliorer mon procédé. Produire du système expert, pour moi, c'est de la routine. Pour mes clients aussi. Mais je dois toujours vaincre mon incognito forcé, les réticences des services informatiques et, le plus extraordinaire, les attaques de l'État lui-même…


La véritable IA, c'est celle qui raisonne !

La véritable IA, c'est celle qui raisonne ! Toute personne qui vous dit le contraire est un charlatan. C'est avec le raisonnement que le développeur programme, c'est avec le raisonnement que le système expert programme …à sa place. Le raisonnement est la 1ère conquête du vivant. C'est lui qui sert à rester en vie, à se nourrir et à sa reproduire. C'est donc le 1er atout à mettre dans un programme. Et tant pis si derrière il n'y a plus de procédural et donc plus besoin d'informaticien… On ne versera aucune larme : l'informaticien est le métier qui a le plus tué les métiers des autres !

Si vous discutez avec lui, il vous dira que ce qu'un système expert ou un Conversationnel fait, il sait le faire aussi bien avec un langage procédural. Il disait aussi il y a 20 ans qu'il pouvait tout programmer en assembleur, mais il a changé d'avis depuis… Il est vrai que, quelque soit le langage informatique, on peut virtuellement tout programmer avec. Mais on ne peut nier le progrès ! Regardez ci-dessous les défauts évidents de la façon classique de programmer par rapport à l'IA que j'ai mise au point, la Maïeutique.


Les 9 défauts du procédural

La liste qui suit, vous ne la trouverez nulle part… Il faut être non informaticien pour oser la commettre. J’ai mis l’Intelligence Artificielle raisonnante en parallèle (la Maïeutique) pour que vous puissiez mieux mesurer à quel point ses avantages sont énormes. Ils sont au nombre de huit :

• Le procédural nécessite la présence d’un intermédiaire
  
• il représente la connaissance de façon illisible pour le commun des mortels
  
• il faut coder tous les cas qui se présenteront sans en oublier un seul
  
• le programmeur fait un boulot de dingue …et il en est fier
  
• pendant tout le développement, l’expert ne voit pas son programme !
  
• on ne touche plus au programme une fois écrit
  
• impossible de certifier la fiabilité du programme écrit (théorème de Goedel)
  
• impossible de modifier un programme en cours d’utilisation
  
• impossible d’aborder certains domaines d’applications

1er défaut : Le procédural nécessite la présence d’un intermédiaire

Entre l’expert qui détient la connaissance à mettre dans le programme et les utilisateurs qui utiliseront le programme, il y a un intermédiaire : le programmeur. C’est lui qui est chargé d’écrire le programme. C’est lui - ou un autre - qui sera par la suite chargé de le faire évoluer. Comme il faut tout lui expliquer, c’est long et fastidieux. De toute façon, il ne peut pas comprendre une expertise qui a demandé des années à être acquise par l’expert. ça ne l’empêche pas, par un amour-propre compréhensible, de prétendre le contraire, ce qui a pour effet d’envenimer fréquemment les relations informatique-services utilisateurs…

Avec la Maïeutique, c’est l’expert qui écrit l’application et la fait lui-même évoluer, en collaboration avec les utilisateurs. Une fois terminée, il la remet au service informatique pour intégration dans le système d’informations. Le poids de l’erreur dans les logiciels repose désormais sur les experts (qui s’en accommodent très bien…). Les informaticiens sont libérés des tensions avec les services utilisateurs. Ils deviennent des collaborateurs « normaux » parlant le langage de tous.


2ème défaut : Le procédural représente la connaissance de façon illisible pour le commun des mortels

Un programme, ce sont des pages de « code » cryptées dans un langage hermétique qu’on ne peut comprendre qu’après avoir suivi une longue formation. Même le programmeur ne s’y retrouve pas quand il remet le nez dans un programme qu’il a écrit il y a plusieurs mois… Et je ne parle pas du malheureux qui doit se replonger dans un programme écrit par un autre !

La Maïeutique présente, elle, un savoir-faire ET une connaissance humaine en langage courant, qu’elle sait « faire tourner » comme du procédural bien écrit. Avec elle, le programme se réduit à une petite base de données toute bête : une « base de connaissances ». C’est quelque chose d’infiniment plus concis et clair que du procédural.


3ème défaut du procédural : il faut coder tous les cas qui se présenteront

Que fait l’expert quand il travaille avec sa connaissance : il raisonne sur LE cas qui se présente et il le résout. Après, il l’oublie et passe à un autre ou à autre chose. Ce n’est pas fatigant. Que fait le programmeur une fois qu’il a compris la connaissance de l’expert à mettre dans le programme : il raisonne sur l’ensemble des cas qui peuvent se présenter au programme et il code chacun d’eux ! Quand on sait qu’il peut y en avoir des centaines ou des milliers, parfois beaucoup plus, on comprend qu’écrire un programme réclame beaucoup de temps.

Que fait le système expert de type Pandora, lui ? Il raisonne sur LE cas qui lui est présenté, il le résout et il l’oublie. Exactement comme l’expert. Pourquoi le programmeur se casserait-il les pieds à imaginer puis créer une procédure traitant de tous les cas possibles si le programme peut inventer immédiatement la solution pour chaque cas ?


4ème défaut du procédural : le programmeur fait un boulot de dingue …et il en est fier

Non seulement le pauvre programmeur est obligé de comprendre une expertise qui n’est pas la sienne, non seulement il doit imaginer tous les cas possibles, mais encore il doit suivre une procédure complexe s’il veut être sûr que son programme tourne et soit accepté : analyse, ordinogramme, codage, tests/modifications. Plus toutes les étapes nécessaires à l’intégration définitive du nouveau programme dans le système informatique : présentation du programme aux utilisateurs, prises en compte des demandes de modifications des utilisateurs, modifications de l’ordinogramme, re-codages, re-tests/modifications, re-présentations du programme aux utilisateurs, etc. Je dis « etc. » car ces allers-retours entre l’utilisateur non satisfait du programme et le bureau du programmeur peuvent se compter par dizaines. Et je ne parle pas du travail de mises à jour sur les programmes, tâche encore plus complexe qui prend un temps énorme. En effet, le programmeur doit relire des pages de codes dont il ne se souvient plus et, pire, que souvent il n’a pas écrites lui-même. Cette re-programmation est une tâche très stressante pour lui : il s’agit de modifier un outil maintenant fiabilisé et utilisé couramment par des gens qui ne peuvent s’en passer et il sait d’avance qu’il va le leur livrer avec des bugs... Bonjour l’ambiance !

Ceci dit, il est conscient que personne ne peut mettre le nez dans un tel travail, que les utilisateurs n’y comprennent rien et qu’il est de ce fait incontournable… L’évolution des langages informatiques dans le temps est le signe tangible qu’en matière d’informatique, le pouvoir n’est pas entre les mains de ceux qui l’utilisent. Tout indique qu’il faut plus longtemps aujourd’hui qu’hier pour développer un programme et que ça s’aggrave sans cesse. Un langage comme Java, très récent, plébiscité par la communauté des informaticiens au point que la majorité des projets nouveaux sont prévus avec lui, réclame davantage de temps en développement que le langage « C » plus ancien ! Les services utilisateurs d’entreprises se rendent bien compte de cette dérive et font de plus en plus pression pour maîtriser eux-mêmes les développements. Encore faudrait-il qu’ils soient tenus au courant des progrès réalisés pour eux…

Avec la Maïeutique, l’ordinateur fait déjà 50 % du travail, ce qui est un gage de rapidité et de fiabilité. L’expert n’a à réfléchir que sur son savoir-faire, pas sur le futur programme. Les utilisateurs et lui voient le programme s’élaborer sous leurs yeux. Ils peuvent rectifier au fur et à mesure si nécessaire. Il n’y a plus besoin de la présence du programmeur et de toutes les étapes imposées par Le procédural. Ca va au moins 10 fois plus vite. La mise à jour des programmes est encore plus facile que le développement, la connaissance étant déjà structurée dans un certain nombre de pages identifiées. Sauf que là, ce n’est plus l’ordinateur qui guide l’expert, c’est l’expert qui guide l’ordinateur : il cherche la page où se trouve la partie de son savoir-faire à modifier, la lit (ce sont des arbres de décision écrits en langage courant, vous allez voir plus loin) et modifie l’endroit désiré. L’ordinateur re-génère l’ensemble du programme, en quelques secondes, et fournit un nouveau programme totalement fiable. Avec la Maïeutique, l’ordinateur est au service de l’utilisateur, pas l’inverse !


5ème défaut : pendant tout le développement, l’expert ne voit pas son programme !

Quand l’expert (ou un utilisateur) demande la réalisation d’un programme, il ne peut dire en général au programmeur quelle tête ce programme devra avoir à la fin. Ce n’est pas son métier d’imaginer le programme en train de tourner alors qu’il ne sait déjà pas de quoi est faite sa connaissance ! Quant au programmeur, bien qu’il soit expert en informatique, il ne peut pas lui dire non plus à quoi ressemblera le programme à la fin : il n’a aucune idée de l’expertise à recueillir. Son métier c’est informaticien, pas expert-comptable ! Il ne sait pas non plus comment les collègues de l’expert travaillent actuellement avec cette expertise et donc il ne peut décrire le programme qu’il serait bon de leur proposer pour que ce soit mieux. C’est un dialogue de sourds. Tout ce petit monde n’aura une idée du programme que …lorsqu’il sera terminé ! C’est à dire bien tard. Et là, les utilisateurs ne seront pas d’accord, l’expert dira qu’il y a des erreurs …d’où les allers-retours.

Avec la Maïeutique, no problem : le programme est développé dans le service concerné, par les personnes concernées, qui le voient évoluer sous leurs yeux et peuvent le tester en permanence « pour voir ». Ils le rectifient ensemble autant de fois que nécessaire. Quand il est fini, il est fini. Il n’y a plus qu’à le transmettre au service informatique pour intégration avec les autres programmes existants.


6ème défaut du procédural : on ne touche plus au programme une fois écrit

Il faut tellement de temps pour modifier un programme et sa fiabilité devient alors tellement incertaine qu’on ne le modifie que le plus rarement possible : tous les 6 mois, tous les ans… Un tel délai ne convient en général pas aux services utilisateurs, mais c’est comme ça…

Avec la Maïeutique, tous les programmes peuvent être modifiés quotidiennement s’il le faut. Ce sont des bases de données, ce qu’il y a de plus fiable et de plus facile à modifier en informatique. Du coup, les mises à jour peuvent être quotidiennes.


7ème défaut du procédural : impossible de modifier un programme en cours d’utilisation

Avec le procédural, on ne sait pas dans quel état sont les données ni où en était la procédure si on remplace brutalement la version courante du programme en cours d’utilisation par une version ultérieure. L’exécution ne peut donc repartir du bon endroit. Les utilisateurs devront recommencer le travail, en plus sans savoir à partir de quand ! C’est pourquoi la version d’un programme procédural n’est remplacée par une autre que la nuit, lorsque tous les utilisateurs dorment, ou alors pendant une période où leur utilisation est interdite : « Désolé, cette application est en cours de maintenance, veuillez attendre SVP… ».

Au contraire, un système expert de type Pandora peut être remplacé par une nouvelle version en cours d’utilisation, de la même façon qu’une base de données …puisque c’en est une ! En effet, ce qui évolue constamment dans un système expert, c’est sa base de données de connaissances : la base de règles. Sur Internet, ce type d’opération est fréquent : on l’appelle « mise à jour de bases de données en temps réel ».


8ème défaut du procédural : impossible de certifier la fiabilité du programme écrit (théorème de Gödel)

Le procédural oblige à tout recoder en repartant de zéro, ou presque. Même dans les langages objets, conçus pour éviter le codage au maximum, la partie essentielle, l'expertise, reste à coder par des "méthodes". Ce qui rend le concept objet encore plus complexe à mettre en œuvre que la programmation classique. Mais il y a autre problème avant même le codage : l'incomplétude. Celle-ci est le pire ennemi de l'analyse en informatique : des voies de codage sont oubliées par erreur humaine et on ne s'en apercevra souvent que trop tard, quand le logiciel est en exploitation depuis des mois ou des années. D'où de gros soucis d'exploitation, surtout si le programmeur du logiciel en cause n'est plus là pour rectifier le plus rapidement possible.

L'IA raisonnante, elle, ramène tout programme à une base de données simple, la forme logicielle la plus ancienne, la plus simple et la plus fiabilisée : une base de règles. Celle-ci est exploitée par un moteur raisonnant de 900 Ko, toujours identique donc hyper-fiabilisé avec les années d'utilisation. Pour les applications batch, il peut même être réduit à sa plus simple expression : sa seule tâche consiste à tester l'une après l'autre les règles pour voir si elles peuvent produire une conclusion à partir des faits initiaux et des faits déduits obtenus avec les règles précédentes, puis de reprendre au départ avec les conclusions obtenues pour tester les premières règles avec les connaissances fraîchement acquises par les dernières. Il s'arrête quand aucune production de faits nouveaux n'a pu être obtenue sur un nouveau cycle à travers toute la base.

Avec la Maïeutique, la complétude est automatiquement vérifiée puisqu'elle matérialise visuellement toutes les voies possibles du raisonnement et détecte celles qui ne mènent pas à la conclusion voulue par le programme. Elle en profite pour faire d'autres vérifications : détection des contradictions logiques, test partiel de l'expertise métier, de la cohérence des types, des expressions obsolètes, des expressions utiles mais inexploitables (non demandables et non déductibles), etc.


9ème défaut : impossible d’aborder certains domaines d’applications

Aujourd’hui, à cause de tous ces défauts, plusieurs domaines d’applications ne sont jamais traités. Ceux où règne « l’explosion combinatoire » : le nombre de cas à traiter dans le programme devient tellement énorme que l’on sait d’avance - théorème de Gödel oblige - que l’on n’arrivera jamais à un programme fiable. Ceux ensuite des applications qui évoluent fréquemment pour ne pas devenir obsolètes, ce que le procédural ne sait pas faire vu le temps qu’il met déjà à réussir une mise à jour fiable (6ème défaut).

Ces domaines d’applications sont les suivants :
• les Conversationnels car 1) c’est le règne de l’explosion combinatoire et 2) ils reposent sur des connaissances pointues sans cesse affinées et il faut les faire évoluer constamment
• La simulation logique d'idées, l'aide à l'invention comme nous le faisons dans notre tête en déroulant un raisonnement pour tester une idée ou simuler un système et voir s'il marche.
• les aides au diagnostic et les aides à la décision, sujettes à l’explosion combinatoire et qui doivent s’améliorer sans cesse en fonction du retour d’expérience, les logiciels d’aide à la configuration de machines complexes
• les didacticiels, puisqu'un système expert raisonne sur une vraie connaissance lisible par tous et peut expliquer pas à pas son raisonnement …jusqu'à signaler les contradictions !
• les logiciels constamment évolutifs, car la maintenance est le problème n° 1 de l'informaticien contrairement à la Maïeutique qui s'en charge facilement puisque tout est écrit en clair
• le diagnostic de panne, un domaine à part où la logique est reine avec l'utilisation de la "contraposée", un raisonnement très puissant.


JEAN-PHILIPPE DE LESPINAY



BIBLIOGRAPHIE
• Article Science et Vie mai 1991 : "Du zéro pointé au Zéro Plus" de Jean-Philippe de Lespinay, Science et Vie mai 1991
• L’IA raisonnante Automates Intelligents (déc 2008) :
• Les centres d’appels et le Conversationnel
• Définition de l'IA et du système expert chez Larousse
• Joséphine 28/01/87
• Joséphine opérationnel ? Oui, mais…
• Les Echos du 11 juillet 1986
• Ouest France, Miao, (diagnostic de panne)
Lire l'histoire →    19 commentaires