Le soleil chante pour Hélène

Un nouvel « Entretien autour de l’informatique ». Hélène Barucq, Directrice de recherche Inria, spécialiste de la simulation numérique de la propagation des ondes sismiques. Hélène Barucq est responsable de l’équipe Magique-3D sur le calcul scientifique en géophysique, commune à  Inria et au département de Mathématiques Appliquées de l’Université de Pau. Elle nous parle des profondeurs de la Terre, de celles du soleil, et d’acoustique musicale. Un coup d’œil passionnant sur un domaine aux frontières des maths, de la physique et de l’informatique.

binaire Comment es-tu devenue chercheuse en mathématiques appliquées ?

HB – Je suis un produit pur jus de l’université. J’ai fait la fac de maths à Bordeaux. J’ai été tentée par l’informatique, mais mes premiers cours m’en ont un peu dégoutée. Et puis, j’ai « rencontré les ondes » dans un projet avec le CEA et Bernard Hanouzet, et comme le sujet m’a conquise,  j’ai choisi ce domaine pour ma thèse sous sa responsabilité. Je découvrais des dialogues fantastiques entre physique et mathématiques, et dans le même temps le plaisir du travail en équipe.  J’ai changé alors d’avis sur l’informatique. C’est passionnant d’expliquer des phénomènes physiques avec des équations mathématiques. Mais c’est encore plus génial, cela prend vraiment son sens pour moi, quand on transforme les équations, les modèles mathématiques, en programmes informatiques. En réalisant des simulations numériques assistées de méthodes de visualisation avancées, on peut alors voir un phénomène physique pour finalement en comprendre les moindres détails.

J’ai obtenu un poste de Maitre de conférence à l’Université de Pau, un peu par chance. C’est là que j’ai commencé à travailler sur des sujets concrets, dans une collaboration avec Total. Et puis j’ai découvert Inria, et obtenu un poste de chercheuse dans l’institut. Cela m’a permis de monter une équipe à Pau. Je me dis parfois que j’aurais aussi bien pu devenir informaticienne parce que les logiciels me fascinent. Aujourd’hui, j’adore mon travail.

binaire – Nous avons entendu dire qu’une de tes caractéristiques, c’est la fidélité ?

HB – Oui ! Je suis toujours à Pau, toujours à Inria. Certaines de mes collaborations durent depuis des années ! Par exemple, je travaille depuis bientôt vingt ans avec Total et Henri Calandra. Nos objectifs ont bien évidemment évolué au cours de ces années, nous conduisant à travailler sur des sujets très variés. Aujourd’hui, nous travaillons ensemble sur des questions liées à la transition énergétique. Surtout, je suis restée fidèle au domaine, les équations des ondes. Bien sûr, j’enrichis sans cesse le groupe de gens avec qui je collabore ; ils deviennent souvent des amis. Et pour les ondes, je considère de nouvelles applications, de nouveaux défis.

binaire – Justement. Il est peut être temps que tu expliques au lectorat de binaire, pour qui cela reste peut être mystérieux, ce que sont les ondes, en quoi consiste ton travail de chercheuse dans ce domaine.

HB – Quand une perturbation physique se produit, elle génère une onde qui se propage en modifiant les milieux qu’elle traverse. Quand on jette un caillou dans l’eau, ça crée une onde à la surface. Quand on pince la corde d’une guitare, cela génère une onde acoustique que les êtres humains à proximité ressentent avec des capteurs situés dans l’oreille. Il existe différents types d’ondes comme les ondes mécaniques qui se propagent à travers une matière physique qui se déforme, ou les ondes électromagnétiques et gravitationnelles qui elles n’ont pas besoin d’un tel milieu physique.

Les études du sol

Figure 1 : simulation de la propagation d’une onde acoustique harmonique dans un milieu terrestre sur un domaine de taille 20 x 20 x 10 kilomètres cubes.

binaire – Ça paraît un peu magique. Pourrais-tu nous expliquer un peu plus en détail comment cela se passe pour l’étude du sous sol. Surtout, nous aimerions comprendre la place des mathématiques et de l’informatique là dedans ?

HB – Supposons que nous voulions cartographier un sous sol pour découvrir des réservoirs d’eau pour de la géothermie. On pourrait faire des forages sans modélisation préalable ; c’est coûteux et ça peut être dangereux : on a vu des forages causer des éboulements très loin de l’endroit où ils étaient réalisés. Plutôt que faire ça, on va utiliser, par exemple, un camion qui vibre en cadence et génère des ondes. Les ondes se propagent dans le sol en gardant des traces de ce qu’elles rencontrent. Pour cartographier le sous-sol, on aimerait découvrir les discontinuités dans la composition de ce sous-sol, et ce qui se trouve entre elles. Pour ça, on va mesurer avec des capteurs les ondes réfléchies et analyser ces données.

Cela demande de développer des modèles mathématiques et des méthodes numériques avancées. Cela demande aussi des calculs considérables souvent réalisés de manière parallèle pour obtenir des simulations précises. En particulier, la détermination des paramètres physiques est un problème d’optimisation qui n’est pas simple car il admet des optimums locaux qui peuvent ralentir voire empêcher la méthode de converger.

Mais on peut faire des trucs sympas. Par exemple, quand un train roule, les frottements sur les rails génèrent des ondes sonores, « tougoudoum, tougoudoum… ». En analysant ces sons, on imagine bien qu’on peut détecter des malformations des rails, des traverses ou du ballast. En Chine, une équipe travaille même à faire des reconstitutions des propriétés du sous sol à partir des ondes générées par un train. Juste en analysant le son du train !

Il existe des tas d’autres applications de ce type d’analyse. Par exemple, en médecine, l’analyse de la propagation d’une onde sonore peut donner des indications sur la présence d’une tumeur, et le même principe peut être appliqué pour réaliser une échographie.

Figure 2 : imagerie sismique par inversion des formes d’ondes : en partant d’un milieu initial représentant le sous-sol (en haut), l’algorithme de minimisation itérative reconstruit un milieu (en bas à gauche) qui permet de reproduire les mesures. Dans cet exemple synthétique, le modèle sous-terrain est connu et représenté en bas à droite.

binaire – Quels sont les freins de tels travaux ?

HB – Le principal frein est que souvent les données sont très bruitées. Pour reprendre l’analogie du cambrioleur, c’est comme si la pluie avait presque effacé les empreintes.

Un autre frein tient dans les besoins de calcul considérables exigés par la simulation. Si vous voulez cartographier un sous-sol dans un cube de 5km d’arête, c’est véritablement des calculs massifs. On peut chercher de manière brutale à faire de plus en plus de calculs mais on atteint vite des limites. On peut aussi essayer d’être astucieux avec les mathématiques ou la simulation. Dans un travail récent, par exemple, nous séparons un grand volume en petits blocs que nous analysons séparément ; ensuite nous « recollons » les morceaux. On pourrait utiliser des bases de données de petits blocs comme ça, et des techniques de machine learning. Il faut essayer d’éviter la force brute, penser autrement.

binaire – Mais beaucoup de ces recherches viennent d’entreprises qui ne voudront pas mettre leurs données, des données qui coûtent cher à produire, à la disposition de tous. Par exemple, est-ce que l’industrie pétrolière accepterait ?

HB – Bien sûr, la recherche de pétrole a été longtemps un moteur du domaine. Mais les temps changent, ce n’est plus le cas. Et même dans des entreprises comme Total qui est très active sur les sujets d’environnement, le partage de données n’est pas exclu.

Les études du soleil

Figure 3 : spectre de puissance solaire correspondant à la propagation d’ondes acoustiques dans le soleil en fonction de la fréquence et du mode.

binaire – Sur quoi portent principalement tes travaux aujourd’hui ?

HB – Je travaille sur l’héliosismologie, l’étude du soleil. Le soleil chante en permanence. Il produit des ondes acoustiques, des ondes à basse fréquence, avec une longue période, que l’on peut détecter par effet Doppler. Leur étude pourrait nous permettre de remonter à l’intérieur du soleil. En comprenant comment il est construit, on espère apprendre à prévoir les irruptions solaires qui peuvent être dangereuses notamment pour nos satellites.

On dispose déjà de cartographies du soleil, on peut même en trouver sur internet. Mais on les aimerait beaucoup plus détaillées. Il faut bien voir la difficulté : le soleil n’a pas de surface comme la terre. La vitesse du son augmente avec la profondeur, tout est en permanence en mouvement.

Ce qui est intéressant pour nous c’est que les méthodes mathématiques à développer reposent sur les mêmes concepts que celles que nous utilisons dans le cadre de la propagation d’ondes dans le sol. Par contre, la physique est différente, plus complexe, par exemple, elle doit tenir compte du champ magnétique.

L’acoustique musicale

Figure 4 : le module du champ acoustique au sein d’une trompette en fonction de la fréquence.

binaire – Ton équipe travaille aussi sur l’acoustique musicale.

HB – Nous avons recruté il y a quelques années Juliette Chabassier qui, dans sa thèse, avait synthétisé le son du piano grâce aux mathématiques. Elle aurait pu travailler avec nous uniquement en Géosciences mais elle aurait été malheureuse car elle est véritablement passionnée par l’acoustique musicale. Nous l’avons plutôt laissée nous transmettre sa passion.

Dans l’équipe, avec Juliette, nous travaillons maintenant avec un luthier. Nous cherchons à reconstituer le son d’instruments à vent anciens, de vieux hautbois. Encore une histoire d’ondes. Ce qui est drôle, c’est que nous pouvons partager les équations, les méthodes, les algorithmes. Ce n’est bien sûr pas du tout la même chose. Les problèmes que nous étudions en acoustique musicale sont en une seule dimension, quand nous travaillons en dimension 3 avec la terre ou le soleil. Donc cela demande a priori moins de puissance de calcul. Mais la prise en compte du musicien introduit de la difficulté. Et, d’un autre coté, les problèmes rencontrés en acoustique sont « non-linéaires » et nous donnent l’occasion de tester de nouvelles méthodes, plus complexes.

binaire – Un mot de conclusion, peut-être ?

HB – Les jeunes que nous voyons arriver dans l’équipe viennent le plus souvent d’écoles d’ingénieur. Ce sont souvent des matheux brillants. Mais ils sont également fans de programmation et de calcul parallèle, un peu « geeks ». Historiquement, on sépare l’informatique et les maths applis, par exemple, dans les sections 26 et 27 du CNU (*) ; eux, on a du mal à les situer. Je dirais, en plaisantant, qu’ils sont, un peu comme nos sujets de recherche, dans la section 26.5.

Nous vivons dans un monde numérique où l’informatique et les maths applis prennent un rôle considérable pour expliquer le monde, la société, pour les transformer. J’aimerais que tous les jeunes prennent vraiment conscience de ça, quelle que soit la profession à laquelle ils se destinent.

Il faudrait aussi que les scientifiques soient plus écoutés. Et pour cela, il faut qu’ils fassent l’effort de se faire mieux comprendre. Ce n’est pas simple d’expliquer sur le papier des équations au grand public. N’essayez pas ! On perd tout de suite son auditoire. Par contre, on peut faire des simulations et capturer les phénomènes avec des images, des courbes, des vidéos. Ça, tout le monde peut comprendre !

Serge Abiteboul, Inria et ENS, Paris, Pascal Guitton, Inria et Université de Bordeaux

(*) Le CNU, Conseil national des universités, est chargée en particulier de la gestion de la carrière des enseignants-chercheurs.

Remerciements à Florian Faucher (Post-doc, Université de Vienne) qui a réalisé les trois premières illustrations.

Comment évaluer le niveau de sécurité de vos objets connectés ?

Grâce aux auteurs du Livre blanc sur la cybersécurité qu’Inria a publié en 2019, nous vous proposons une série d’articles sur cette question majeure. Abdelkader Lahmadi  et Isabelle Chrisment nous parle des questions de sécurité soulevés par l’utilisation des objets connectés de plus en plus présents autour de nous. Alors faut-il s’en méfier ? Pascal Guitton.

 De plus en plus nombreux chez les particuliers et les entreprises, les objets connectés font partie de notre quotidien.  Montres, bracelets, interrupteurs, thermostats, systèmes d’éclairage ou de vidéosurveillance sont maintenant capables de communiquer avec leur environnement et d’utiliser l’infrastructure de l’Internet : ils transmettent à des serveurs des informations qui peuvent ensuite être analysées et sont aussi, pour certains, contrôlables et configurables à distance. La domotique entre davantage dans les maisons (surveillance et commande, via notre téléphone, du chauffage, des caméras, des volets, etc.) et les différentes campagnes publicitaires nous vantent déjà un monde futur plus connecté, où les évolutions, au niveau robotique et intelligence artificielle, devraient rendre notre quotidien plus facile en anticipant même des besoins que nous ne connaissons pas encore.

Plateforme domotique d’objets connectés. Crédit © Inria / Photo D. Betzinger.

On estime aujourd’hui à environ 30 milliards le nombre d’objets connectés avec un accroissement de plus de 20% chaque année[1].  Le passage vers le réseau 5G va certainement accroître ce nombre et faciliter le déploiement des objets connectés dans de multiples domaines d’application, notamment dans l’industrie 4.0.

Vulnérabilité des objets connectés  

Devant la multiplication des applications, fabricants et produits, la commercialisation d’un objet connecté représente une véritable course contre la montre. Un large éventail d’objets connectés dédiés au grand public s’appuie donc principalement sur des composants logiciels et de communication pris sur étagère, souvent déjà obsolètes au moment même de la conception desdits objets, et donc possédant des vulnérabilités connues et répertoriées dans des bases de données.

Un exemple récent est celui du robot-cuiseur connecté vendu à un prix défiant toute concurrence dans une chaîne de grande distribution[2]. Non seulement, l’utilisation de la tablette du robot-cuiseur a pu être détournée pour regarder une vidéo ou consulter des sites web, mais de plus, il a été montré qu’un micro était installé sans que le consommateur n’en soit informé. Certes, le micro était désactivé par défaut, mais la tablette fonctionnait avec une version ancienne d’Android  présentant des failles de sécurité.

Ces objets connectés sont donc le plus souvent peu ou pas sécurisés. Les fabricants limitent, à tort ou à raison, les ressources (capacités de calcul, mémoire, stockage, etc.) nécessaires pour ces appareils. Leur sécurité est donc fréquemment sacrifiée, pour des raisons de gain de temps, de coût, et de simplicité d’usage pour l’utilisateur final, avec comme justification – souvent erronée – que l’objet est installé dans un réseau privé sécurisé (le réseau WiFi de l’utilisateur) et donc non vulnérable. Les mises à jour et correctifs sont rares, voire inexistantes, et consistent principalement en des modifications cosmétiques de l’interface de contrôle.

Objets connectés et cyberattaques

Les objets connectés vulnérables représentent une menace grandissante puisqu’une faille dans leurs composants peut avoir un impact sur des milliers, voire des millions d’usagers, et ce pour une période potentiellement longue dans le temps. En effet, une fois installés et configurés, ils restent en service tant qu’ils sont fonctionnels (soit quelques années) et la rareté des mises à jour et de celles de leurs applications (si elles existent) augmente considérablement le risque d’attaques ou de compromissions. Les failles peuvent ainsi être exploitées pour détourner les objets de leurs usages principaux, comme par exemple les faire participer à de grandes cyberattaques coordonnées. Ce fut le cas il y a quelques années avec l’infection de centaines de milliers d’objets connectés par un logiciel malveillant appelé Mirai[3]. Les appareils contaminés, notamment les caméras accessibles à distance, ont été utilisés pour bombarder de requêtes le principal hébergeur français, jusqu’à ce qu’il ne puisse plus fonctionner (attaque « par déni de service distribué » de type DDoS). En 2017, des chercheurs ont mis en évidence une faille dans un contrôleur réseau utilisant le protocole sans fil  Z-Wave[4], largement déployé pour les objets connectés domotiques (éclairage, prises, thermostats, etc.). Dans un réseau Z-wave, l’un des rôles du contrôleur est d’associer les équipements au réseau pour que l’utilisateur puisse les commander à distance. La vulnérabilité découverte permet à un attaquant de dupliquer le contrôleur Z-Wave et ainsi de prendre le contrôle à distance de tous les équipements  de ce réseau, comme s’il était l’utilisateur légitime. Malgré sa dangerosité, la faille reste très spécifique et n’affecte qu’un produit particulier des fabricants de contrôleurs.

Diagnostic des failles de sécurité

On peut en vouloir aux fabricants de ne pas avoir identifié et réparé les failles de sécurité des objet connectés, mais il faut rappeler ici que concevoir et développer des composants logiciels sûrs, même pour les systèmes classiques de l’Internet constitue un problème notoirement complexe. Plusieurs bases de données (nvd.nist.gov, cve.mitre.org, cvedetails.com) et outils existent pour répertorier les vulnérabilités des attaques connues de ces objets connectés, mais aussi de leurs composants logiciels. Il s’agit d’une tâche très fastidieuse qui nécessite une expertise et des compétences techniques très pointues. Cela représente un travail colossal et on est encore très loin d’un monde idéal où 100%, des systèmes informatiques, en particulier des objets connectés, sont prouvés sûrs et sans aucune faille. Les pratiques courantes, souvent artisanales, ne garantissent pas une évaluation précise et sont partielles à cause de l’hétérogénéité, pour ces appareils connectés, des protocoles de communication, des usages et des composants logiciels et matériels.

Pour faire face à ce défi, des travaux de recherche[5][6] proposent des approches capables de cartographier et diagnostiquer les failles de sécurité de ces objets, pour leur associer un niveau de risque lié à leur usage dans un environnement particulier. L’automatisation de la cartographie et de l’évaluation de la sécurité des appareils connectés permet d’alléger considérablement les tâches de détection et de prévention de cyberattaques et elle garantit aussi une meilleure sécurité et confiance dans les appareils numériques et connectés à la fois pour le grand public et les systèmes industriels (actuels et pour l’usine du futur).

La suite d’outils SCUBA (1) permet ainsi d’évaluer automatiquement le risque d’un objet connecté dans son environnement d’usage et de lui attribuer une note, à l’image des labels de performances énergétiques attribués aux appareils électroménagers. L’originalité de ce travail est de permettre d’auditer la sécurité d’un appareil connecté dans son environnement global et non plus de façon isolée. On étudie notamment les interactions de l’appareil connecté avec tous les éléments qui se situent dans son périmètre : une ampoule connectée n’est pas soumise au même environnement ni aux mêmes risques si elle est branchée directement sur une simple prise ou sur un interrupteur également connecté. L’outil SCUBA a permis de diagnostiquer une faille de sécurité entre une sonnette connectée et son service dans le cloud. La sonnette, équipée d’une caméra, envoie vers le cloud la photo de la personne présente à votre porte pour l’acheminer ensuite vers votre téléphone. En revanche, cette communication entre la sonnette et le cloud n’est pas chiffrée et la photo est envoyée dans un message en clair, ce qui permet à un attaquant d’intercepter le message contenant la photo et de  la remplacer par une autre.

Illustration de l’exploitation d’une faille de sécurité d’une sonnette connectée.

Compte tenu de la célérité avec laquelle les objets connectés sont créés et déployés, de nombreux enjeux sont à relever notamment ceux liés à la diversité des protocoles de communication utilisés par les objets connectés : il n’y a pas de standard commun et il y a presque autant de protocoles de communication que de catégories d’équipements (les caméras et les thermostats, par exemple, utilisent des protocoles différents). La complexité des algorithmes à considérer dans le cadre de l’évaluation du niveau de sécurité est également à prendre en compte : ceux-ci doivent en effet  être en mesure de traiter de vastes gisements de données hétérogènes et non-structurées, générées par des machines.

Abdelkader Lahmadi (Université de Loraine, LORIA) et Isabelle Chrisment (Télécom Nancy, LORIA)

[1]https://www.forbes.com/sites/gilpress/2016/09/02/internet-of-things-by-the-numbers-what-new-surveys-found/#2b50369016a0

[2]https://www.numerama.com/tech/525214-monsieur-cuisine-connect-micro-cache-android-non-securise-les-dessous-du-robot-cuisine-de-lidl.html

[3] Une présentation de Mirai est disponible sur cette page wikipedia.

[4] Une présentation de la faille découverte par des membres de l’équipe de recherche RESIST est disponible sous ce lien.

[5] https://foundation.mozilla.org/en/privacynotincluded/

 

[6] https://iot-inspector.princeton.edu/

 

Des connaissances de l’humain au monde de l’entreprise

Les algorithmes d’intelligence artificielle dont nous entendons si souvent parler sont basés sur des apprentissages et des connaissances.  Ces notions sont à l’intersection de plusieurs domaines : sciences cognitives, sciences de l’éducation et désormais sciences du numérique.  A partir d’articles qu’Ikram Chraibi Kaadoud a publié sur son blog Intelligence mécanique, nous vous proposons deux textes pour y voir plus clair. Après avoir traité de l’apprentissage et des connaissances, elle nous explique comment favoriser le passage de l’expertise dans les entreprises. Pascal Guitton

L’ensemble des notions de connaissances et de raisonnement, sont des questions importantes dans les domaines des sciences cognitives et de la psychologie du développement, mais ce sont également des concepts essentiels dans le domaine de l’ingénierie et la gestion des connaissances en entreprise où l’humain est un élément déterminant à part entière !

De débutant à expert : évolution des connaissances chez l’humain

Commençons par un exemple : un conducteur expérimenté ayant plusieurs années de conduite derrière lui, est un expert par rapport à un jeune conducteur qui vient de décrocher son permis. Si ce dernier fait appel à ses connaissances explicites du code de la route et du fonctionnement global de la voiture (positionnement des vitesses, positionnement des différentes pédales du véhicule, etc.) pour utiliser son véhicule, a contrario, le conducteur expérimenté conduit son véhicule de manière plus automatique, car il a développé des habitudes de conduite, des réflexes [Mathern, 2012].

Cet exemple reflète ce que de nombreux travaux en psychologie considèrent comme expert : à savoir un individu possédant un savoir-faire (connaissances et compétences particulières liées à ses expériences) et des ressources tacites par rapport à un novice. Ainsi dans cet article nous considérerons un expert, en général, comme étant une personne surentrainée, qui a acquis des habilités particulières par son expérience et qui a notamment connu une migration de ses connaissances explicites à un savoir-faire implicite.

Figure A – Transformation des connaissances au fur et à mesure de la montée en compétence, c’est-à-dire de la pratique, selon trois étapes.

Il existe 3 étapes d’acquisition de compétences (i.e de montée en expertise) : Le premier stade est qualifié de stade cognitif : les individus cherchent et récoltent des connaissances explicites de plusieurs sources sur le domaine considéré. Dans le cadre de la conduite, ces sources explicites sont le code de la route et les cours dispensés par une auto-école. Pour réaliser une tâche, l’individu sollicite ses connaissances explicites issues de sa mémoire à long terme en rapport avec la tâche à accomplir, sur lesquelles il applique des procédures générales (i.e. des procédures qui peuvent être appliquées à n’importe quel domaine). Lors de cette première phase, les processus de prise de décision et de résolution de problèmes sont lents, fastidieux et sujets à erreurs..

Le second stade est nommé le stade associatif et intervient au fur et à mesure qu’un individu devient de plus en plus compétent dans un domaine. L’utilisation répétée de connaissances explicites dans des situations données aboutit à la formation de connaissances procédurales spécifiques (automatismes) au domaine.  Elles consistent en l’association directe entre des conditions spécifiques du domaine et l’action résultante, ce qui aboutit à l’apprentissage implicite de règles. La nécessité d’analyser des connaissances explicites est progressivement contournée : lorsque les conditions dans l’environnement correspondent aux conditions de la règle procédurale (c’est-à-dire la règle déjà apprise), l’action est automatiquement invoquée. Les processus longs et fastidieux de rappel (souvenir) des connaissances explicites et d’application de procédures générales à ces connaissances sont ainsi contournés.

Enfin, le troisième stade est le stade autonome : les procédures deviennent automatisées. Les associations se renforcent, se spécialisent et/ou s’adaptent à des types particuliers de situations. Les connaissances procédurales deviennent très rapides et automatiques. Durant ce stade, les connaissances procédurales simples sont composées ou remplacées par des connaissances procédurales plus complexes et inclusives. Ce dernier type de connaissances compressant (contenant) un large nombre de conditions d’instanciations et d’actions résultantes, induit une perte de capacité des individus à verbaliser leurs connaissances.. Ainsi au fur et à mesure que les procédures deviennent composées et automatisées, la capacité de verbaliser les connaissances liées à la compétence diminue. Quand la réalisation d’une tâche devient complétement automatisée, le traitement, ne nécessitant plus de ressources cognitives, est autonome et inconscient, autrement dit, il est alors implicite. La figure A illustre les trois stades d’évolution d’un novice au stade d’expert et leur impact sur la capacité de verbaliser ses connaissances. En résumé, un expert, dans un domaine donné, possède des connaissances et des procédures implicites qui lui permettent de choisir rapidement et automatiquement la bonne option dans différents contextes en analysant une situation courante en fonction de ses expériences antérieures. Il évite ainsi l’utilisation d’un processus itératif et laborieux de prise de décision [Bootz, 2016].

Comprendre ses connaissances, en quoi est-ce important dans notre quotidien ?

Dans notre quotidien, la question de l’expert et de la transmission des connaissances se posent constamment !

Lorsqu’un jeune collaborateur (jeune en termes d’expérience) arrive dans une équipe, un stagiaire par exemple, il est formé, accompagné dans son apprentissage de ses nouveaux outils ou méthodes de travail. Il y a alors une passation des connaissances entre les « anciens » et les « nouveaux », et souvent le départ d’un collaborateur senior (senior en termes d’expérience) est souvent considéré comme une perte surtout s’il n’a eu personne à qui transmettre ses connaissances au sein de l’équipe.

A contrario, lorsqu’un expert métier senior forme un jeune collaborateur, deux moyens s’offrent à lui afin transmettre une partie de sa connaissance. Le premier moyen consiste à lui expliquer explicitement le pourquoi et le comment, ce qui correspond à l’acquisition de connaissance explicites pour le jeune collaborateur. Le second moyen consiste à lui montrer, lui faire prendre en main et donc le faire manipuler afin qu’il acquièrt de l’expérience et donc des connaissances implicites autour de son métier.

Figure B – Les quatre transformations des connaissances au sein d’une organisation d’après Nonaka et Takeuchi, deux chercheurs connus pour leurs travaux dans le management des connaissances.

Nous retrouvons alors l’importance de la compréhension de ce qu’est une connaissance et comment l’acquérir, puisque comprendre cela et notamment l’apprentissage implicite, permet de comprendre comment s’acquiert l’expérience, c’est à dire l’ensemble des connaissances implicites relatives à notre vécu.

Dans le domaine des entreprises, l’ensemble des questions autour de la problématique de « comment conserver et préserver les connaissances ? » porte le nom de « Gestion, Ingénierie ou management des connaissances ». Il s’agit d’un axe déterminant dans la mesure où la connaissance est l’équivalent d’un trésor pour ces dernières. En effet, la question de l’expertise métier et de la transmission des connaissances représentent toutes deux un double enjeu pour les entreprises : au niveau des collaborateurs internes des entreprises pour véhiculer le savoir-faire, mais aussi au niveau de la connaissance et de la compréhension des métiers des clients et prospects (clients potentiels).

Coté informatique et IA ?

S’intéresser à l’organisation des connaissances chez l’humain et en particulier à l’acquisition des connaissances implicites permet de mieux comprendre l’apprentissage chez l’humain, et par extension, permet de mieux anticiper, récolter, conserver et diffuser la connaissance autour de soi.

Or s’il est facile de récolter des informations explicites à travers des questionnaires, de l’analyse de documents, l’étude de cahiers des charges et de supports écrits divers, qu’en est-il des connaissances implicites ? Autrement dit comment expliciter le savoir-faire implicite d’un individu ?

Une solution potentielle : le Machine Learning. Lors de la phase d’apprentissage, un réseau de neurones – algorithme du domaine de l’apprentissage automatique – développe une représentation implicite des données qu’il apprend explicitement. De nombreux champs d’études s’intéressent à ces représentations implicites, car elle comporterait des explications sur les prédictions faites par la machine mais aussi des informations importantes sur les données apprises et par extension sur les individus à l’origine de ces données.

Ainsi il semble qu’il y ait encore de nombreux ponts à explorer entre les sciences cognitives et la modélisation de la cognition humaine à travers des algorithmes de machine Learning. L’informatique semble donc être un outil intéressant pour explorer la cognition humaine, et mieux se comprendre en tant qu’humain !

Ikram Chraibi Kaadoud, alors Doctorante Inria au sein de projet Mnemosyne.

Références :

Référence principale :

L’article est adapté des travaux de thèse de l’autrice :

Chraibi Kaadoud, I, 2018. Apprentissage de séquences et extraction de règles de réseaux récurrents : application au traçage de schémas techniques. Thèse de doctorat, Université de Bordeaux. URL : https://tel.archives-ouvertes.fr/tel-01771685, page 1 – 18.

Vous pouvez vous y référez pour de plus amples références bibliographiques ainsi que des explications plus détaillées.

Autres références

Bootz, Jean-Philippe, 2016. Comment définir et gérer l’expert ? Available from : https ://www.agecso.com/wp/wp-content/uploads/2016/01/BourbaKeM-5.pdf (accessed 20 December 2017).

Mathern, Benoît, 2012. Découverte interactive de connaissances à partir de traces d’activité : Synthèse d’automates pour l’analyse et la modélisation de l’activité de conduite automobile. Thèse de doctorat, Université Claude Bernard-Lyon I. URL : https://tel.archives-ouvertes.fr/tel-00864865

 

Autour d’une caisse enregistreuse

ppC’est capable de faire des maths tout seul un ordinateur ? Pas tout à fait 😉 C’est bien notre cerveau humain qui conçoit la preuve mathématique, et la conduit à son terme … mais en utilisant un outil informatique, cela peut-être plus sûr et plus efficace. Marie Kerjean nous explique aussi simplement que si nous étions des enfants ! Charlotte Truchet et Thierry Viéville.
© https://pixabay.com

Deux enfants jouent au marchand:

 » Une pomme à 1 euros et six poulets à deux euros, ça fait 7 euros »

– Non tu triches ça fait 3 euros!

– Non !

– Si !

– ON REGARDE SUR LA MACHINE  »

Et la caisse enregistreuse, cette calculatrice jouet, permit enfin de régler ce conflit : 13 euros donc.

Les nombres, et leurs opérations de bases, font partie des premiers objets abstraits que l’on manipule. On apprend le concept de nombre, on comprend pourquoi 1+6*2 = 13, mais on apprend aussi à se passer d’une calculatrice. A savoir faire tout ça de tête, vite et bien. Certaines trouvent ce jeu rigolo, d’autres détestent. Et pourtant, quand on doit faire des opérations très compliquées (par exemple, une pomme, six poulets et 1857 mg de safran), on est toutes et tous d’accord pour préférer vérifier le résultat sur une calculatrice.

Et quand on fait des mathématiques ardues avec autre chose que des nombres, comment fait-on ? Les calculatrices qui prouvent les mathématiques se nomment les assistants à la preuve.  Les touches de la calculatrices sont les outils à disposition pour reconstruire brique par brique les mathématiques. Ces touches jouent un rôle très important : elles représentent le langage utilisé par l’assistant à la preuve. 

Comment fait-on pour coder n’importe quel théorème – pas seulement des additions – et sa preuve dans un ordinateur ? C’est là qu’intervient le slogan de la correspondance de Curry-Howard : si vous écrivez votre théorème avec le bon langage,  « une preuve est un programme ».  

Une ado lève la tête de son écran.

« Quoi ? Mais qu’est-ce que je programme? 

– Ben tu programmes un … théorème : une affirmation mathématique, que l’on peut prouver. 

– Mais comment ? 

– Par petits bouts, en partant d’hypothèses, puis on déroule des calculs, et -hop- on obtient la conclusion .


Par exemple, si tu veux prouver « 1*4 = 4 et 4*1=4 », tu peux dire à l’assistant à la preuve de s’attaquer d’abord à la preuve à gauche du « et » .

– Et ensuite ? 

– Tu prouves facilement que « 1*4 = 4″et tu passes à la preuve de gauche 

– Un peu comme un dialogue en fait ! 

– Un peu.  »

© Picture by Hannah

Un bon langage permettant d’écrire des théorèmes est celui de la théorie des types. En l’étudiant, les chercheurs et les chercheuses construisent en particulier l’assistant à la preuve Coq. Il sert ainsi à vérifier la preuve de gros théorèmes à l’aide d’un ordinateur (comme le théorème des quatre couleurs) , mais aussi à vérifier que certains programmes calculent bien ce qu’il sont censés calculer. Cela fonctionne même pour de gros programmes, comme le compilateur C du projet CompCert ! http://compcert.inria.fr

 

Deux enfants prennent leur goûter :

«  Un bout de tarte aux pommes pour toi, un bout de tarte aux pommes pour moi, un bout de tarte aux pommes pour toi.

– Ah non tu dois couper un  bout en deux.

– Mais alors je ne pourrai pas compter les bouts sur la machine !

– Tu préfère avoir moins de bouts de tarte mais pouvoir les vérifier sur la machine !?

– Et sur la machine on pouvait compter les moitiés de bouts de tarte ?  »

En effet, et si la caisse enregistreuse possédait une nouvelle touche permettant de calculer avec les portions d’un objet (ces fameux calculs avec des fractions) ?

Faire de la sémantique c’est comme préparer un goûter, c’est utiliser de nouveaux objets pour interpréter le langage de la calculatrice. Ce sont des objets mathématiques, que l’on découvre  sur papier, d’où le slogan* de la sémantique dénotationnelle : « un programme est une fonction (mathématique)».

En bref, ma recherche s’attache particulièrement à bien parler de fonctions avec la logique. À la fois en prouvant des bibliothèques d’analyse fonctionnelle à l’aide de l’assistant à la preuve Coq, mais aussi en rapprochant les objets modélisant la logique de ceux traditionnellement utilisés pour faire de l’analyse.

Marie Kerjean est post-doctorante Inria au LS2N après avoir fait sa thèse à l’IRIF et travaille à la frontière entre la logique formelle, la théorie des types et l’analyse fonctionnelle.

(*) Ce slogan permet parfois de rajouter dans les preuves de la logique de nouvelles règles : ce que l’on sait faire avec des fonctions, il y a un espoir de pouvoir le faire sur des preuves, ou des programmes. C’est ainsi que la logique linéaire introduit la notion de linéarité des preuves : une fonction linéaire c’est une fonction très très simple – une droite qui passe par zéro – et une preuve linéaire d’un théorème c’est aussi une sorte de preuve très très simple. On peut même parler de linéarisation d’une preuve, c’est à dire quelque chose qu’on nomme sa différentielle.

Après le confinement

Chers lecteurs et lectrices de binaire,

Depuis 2014, le blog binaire du Monde est réalisé par un groupe d’éditeurs, d’amis, qui veulent partager leur passion pour le monde numérique, ses avancées scientifiques, ses innovations technologiques, ses enjeux sociétaux majeurs, etc. Avec l’aide d’une communauté d’auteurs et autrices passionnés comme nous par le sujet, nous sommes arrivés à construire le meilleur magazine en français sur l’informatique et le numérique – selon nous en tous cas 🙂 . Nous n’y  serions jamais arrivé sans le soutien d’un réseau de partenaires, le plus souvent incarnés par des amis : la Société informatique de France et son bulletin 1024, Interstices, la Fondation Blaise Pascal, le CNRS, Inria et son association d’alumni, Theconversation, et d’autres.

Le blog binaire, c’est aussi une communauté de lectrices et lecteurs, souvent fidèles. C’est vous !

Pendant le confinement, soutenus par notre communauté d’auteurs et autrices nous avons accéléré la publication pour aller jusqu’à un article par jour. Vous lecteurs avez été au rendez-vous. Nous sommes montés jusqu’à 5000 à 10000 lecteurs par semaine (contre environ 2000 à 3000 en temps normal). Merci !

Continuez à nous lire ! N’hésitez pas à nous interpeller pour nous critiquer, nous suggérer des sujets, dénoncer des auteurs potentiels, ou juste pour nous dire que vous aimez trop binaire. Parlez de nos publications autour de vous et sur les réseaux sociaux !

Amitiés binairiennes

Antoine, Charlotte, Clémentine, Éric, Lonni, Marie-Agnès, Pascal, Pauline, Pierre, Serge, Tamara, Thierry

La logique: un instrument théorique pour des problèmes pratiques.

Prof Franco RaimondiQu’est-ce que la logique ? À quoi sert-elle ? Pour répondre à ces questions, remontons dans l’histoire et retraçons parcourons l’évolution de la logique à travers les siècles, de la Grèce antique aux Temps modernes, en allant à la rencontre de celles et ceux qui l’ont construite. Ce faisant, nous verrons que nous devons reformuler la question et demander plutôt : « Qu’est-ce que la logique aujourd’hui ? Et à quoi sert-elle aujourd’hui ? », donnons la parole à Franco Raimondi., Professeur et chercheur en science informatique à l’Université de Middlesex à Londres, pour nous emmener dans ce voyage à travers les siècles. Charlotte Truchet et Thierry Viéville.

Le mot « logique » en grec ancien signifiait « mot » et « raison » et était utilisé pour désigner l’art de construire des formes de raisonnement correctes (« he logike Aristoteles Louvre.jpgtechnè »). Dans la Grèce antique, l’objectif de la logique d’Aristote était « l’élaboration d’un système cohérent […] pour enquêter, classer et évaluer les bonnes et les mauvaises formes de raisonnement« . Vers 1600, Bacon a déclaré que « la logique diffère de la rhétorique … en cela, que la logique de la raison raisonne exactement et en vérité, et la rhétorique la manipule telle qu’elle est implantée dans les opinions et les manières populaires ».

 

Depuis plus de 2000 ans, la logique est essentiellement utilisée pour « modéliser des arguments exprimés en langage naturel » et pour formaliser le raisonnement : c’est-à-dire que le rôle de la logique est de fournir un moyen de répondre aux ambiguïtés qui surgissent lorsque nous utilisons notre langage. Par exemple, si je dis « je vois un homme sur la colline avec un télescope », cela signifie que j’utilise un télescope pour voir l’homme, ou bien que je vois un homme sur la colline, qui a un télescope : l’utilisation de la logique peut nous permettre de lever cette ambiguïté. On peut probablement résumer cette vision de la logique en disant que la logique peut être un instrument pour fournir un langage bien formalisé et partagé pour élaborer des pensées complexes et pour identifier des formes de raisonnement correctes (et incorrectes).

C’est au XIXe siècle que la logique a considérablement évolué : les travaux Description de cette image, également commentée ci-aprèsde Gottlob Frege (à gauche) et  George Boole  (à droite) ont Young frege.jpgcommencé à dessiner les bases formelles de la logique. Ces fondations sont fournies en utilisant le langage des mathématiques :  Boole et Frege sont tous deux des philosophes et des mathématiciens. La naissance de la discipline de la logique mathématique peut probablement être attribuée à cette période historique. Encore aujourd’hui, la logique est enseignée  en mathématiques, dès l’école primaire, et la logique est également l’un des principaux cours enseignés dans les cursus universitaires de philosophie.

C’est une révolution, vers la fin du XIXe siècle, Frege et autres mathématiciens et philosophes ont proposé un nouveau véhicule pour la logique : au lieu d’essayer de formaliser le raisonnement en langage naturel, ils ont commencé à formaliser le raisonnement avec un langage et au sein mathématique. Cela peut sembler évident pour nous aujourd’hui, parce que nous utilisons la logique pour raisonner sur les mathématiques dès le plus jeune âge, et on utilise quotidiennement la logique si nous écrivons des logiciels. Toutefois, au Description de cette image, également commentée ci-aprèsdébut du XXe siècle, cette approche était nouvelle et au tout début du XXe siècle, David Hilbert (à gauche) a publié une liste de problèmes, dont l’un était : « Prouvez que les axiomes de l’arithmétique sont cohérents » (vous pouvez considérer la cohérence comme une propriété qui dit « vous ne pouvez pas déduire de contradictions des axiomes »). Le but ici était de fournir une caractérisation de l’arithmétique basée uniquement sur la logique. Et … ce fut une tragédie !

Entre 1930 et 1931, Kurt Gödel a démontré deux théorèmes, appelés Description de cette image, également commentée ci-aprèsthéorèmes d’incomplétude de Gödel (à droite), qui se sont révélés catastrophiques pour les objectifs de Frege et le programme de Hilbert. Le premier théorème montre que si un système d’axiomes pour l’arithmétique est cohérent, alors il n’est pas complet. Cela signifie que pour chaque énoncé, ni l’énoncé lui-même, ni sa négation ne peuvent être démontrées. Pire encore, le deuxième théorème montre que tout système axiomatique suffisamment fort pour  formaliser l’arithmétique ne peut pas prouver sa propre cohérence. Bref, le défi lancé avec le 2ème  problème de Hilbert, sera à tout jamais en échec.

Le théorème d’incomplétude de Gödel a-t-il marqué la fin du mariage entre la logique et les mathématiques ? La logique ne devrait-elle être utilisée que pour formaliser le langage naturel ? Définitivement pas. Peu de temps après le Ada Byron daguerreotype by Antoine Claudet 1843 or 1850 - cropped.pngtravail de Gödel, une nouvelle discipline, dans laquelle la logique a joué (et joue Description de cette image, également commentée ci-aprèstoujours) un rôle central, a commencé à gagner de plus en plus d’importance : l’informatique. L’idée d’un « ordinateur mécanique » remonte (au moins) à Charles Babbage (à droite) et Ada Lovelace (à gauche) vers 1840. La première trace d’exécution d’un algorithme publiée, conçu comme une séquence finie d’instructions pouvant être exécutées par une machine appelée « Analytical Engine », est apparu en 1843 et a été écrit par Ada Lovelace pour calculer les nombres de Bernoulli (Voir Vardi, « A Brief History of Logic »).

Description de cette image, également commentée ci-aprèsEntre 1930 et 1950, le travail, entre autres, d’Alan Turing (à gauche), d’Alonzo Church (à droite), et de Claude Shannon (ci-dessous) a posé les fondations de plusieurs domaines de recherche théorique en informatique. Il a aussi permis de répondre négativement à une autre question posée par Hilbert : il n’est pas possible de construire un algorithme qui puisse prouver un énoncé logique donné, à partir des axiomes de la logique (au sens du calcul des prédicats).

Malgré ce résultat négatif pour le problème de la décision (connu sous le nom de Entscheidungsproblem), le lien entre la logique et l’informatique a permis le développement des premiers ordinateurs réels. De nombreux problèmes sont en effet décidables. Les mathématiciens ont donc pu, en utilisant le langage de la logique, concevoir des machines et des programmes pour résoudre des problèmes pratiques. Par exemple, pendant la seconde guerre mondiale, Alan Turing a conçu « La Bombe« , une machine capable de déchiffrer les messages allemands. Les mathématiciens ont continué à travailler sur les questions de calcul, et ont franchi une étape clé vers la fin de années 50, lorsque les langages de programmation ont commencé à être conçus, permettant ainsi d’écrire des logiciels indépendamment du hardware. Le travail de Grace Hopper (à droite) au milieu des années 50 a conduit à la création d’un des premiers langages de programmation dans lequel les instructions pour l’ordinateur sont données en utilisant de la logique, exprimés avec des mots simples. En facilitant l’écriture de programmes informatiques, les langages de programmation ont conduit à l’expansion massive des ordinateurs dans l’industrie.

La logique est un ingrédient fondamental dans tous les langages de programmation utilisés aujourd’hui : il ne serait pas possible d’écrire un logiciel significatif sans utiliser la logique pour coder les conditions et les conditions de sortie de boucle. Mais la logique a des applications dans plusieurs autres domaines  : la logique est un instrument théorique qui, aujourd’hui, nous permet de résoudre des problèmes très pratiques. La logique a aussi été utilisée pour modéliser et analyser les circuits électroniques digitaux (ou hardware)  : la logique permet aux ingénieurs d’optimiser et de vérifier le comportement d’un circuit avant même qu’il ne soit construit.

Pour être précis, il faut aujourd’hui parler des logiques (au pluriel), plutôt que d’une seule « logique ». Les résultats négatifs mentionnés ci-dessus pour la décidabilité et la complétude se réfèrent principalement à cette logique appelée « calcul des prédicats ». Toutefois, une quantité substantielle de recherches a étudié les restrictions et les variations de cette logique. Par exemple, il existe des logiques pour raisonner sur le temps, exprimant des notions telles que « suivant » ou « dans le futur ». Il existe des logiques qui peuvent modéliser l’échange d’informations entre des agents et leurs obligations. Ces logiques ont servi à modéliser et à vérifier des protocoles de sécurité, et d’autres systèmes complexes, à la fois dans le monde universitaire et dans l’industrie.

Philippe Roussel informaticien.jpgLa logique a également des liens directs avec l’intelligence artificielle. Vers 1970, Philippe Roussell (à gauche) et Alain Colmerauer (ci-dessous) ont développé un langage de programmation appelé PROLOG, qui signifie « Programmation en Logique ». Depuis lors, ce langage de programmation et ses variantes ont été largement utilisés dans la prise de décision (decision making) automatisée et la planification automatisée. De même, la logique fournit les instruments théoriques pour étudier et optimiser les structures de données et les langages de requête pour les bases de données, mais aussi pour la planification, le scheduling et l’allocation des ressources.A-Colmerauer web-800x423.jpg

Un autre domaine important où la logique joue un rôle clé est la vérification des logiciels : au cours des vingt dernières années, il y a eu un énorme progrès dans la vérification automatisée des logiciels basée sur la logique pour raisonner sur l’exécution des programmes. Les entreprise dans des domaines tels que l’aéronautique ou le médical, mais aussi des sociétés comme Microsoft, Facebook, Amazon, Google, Apple et bien d’autres, ont des équipes dédiées travaillant sur les logiques de vérification :.
– https://aws.amazon.com/security/provable-security
– https://fbinfer.com
– https://www.microsoft.com/en-us/research/group/research-software-engineering-rise

Voilà, la logique a non seulement une longue histoire théorique, mais elle a aussi des applications très pratiques de nos jours : à partir de la logique comme instrument initialement développé pour formaliser le raisonnement avec la langue humaine, cet « instrument » a  évolué dans la direction des  mathématiques, puis est devenu un ingrédient clé pour le développement du hardware et des logiciels. Aujourd’hui, les logiques sont nombreuses et leurs applications ont un impact direct et croissant sur notre vie quotidienne.

Franco Raimondi est professeur d’informatique à Middlesex University, London. 

– Il remercie Giuseppe Primiero, Fabio Roda, Francesca Invernizzi and P.B. pour leur aide et leurs commentaires dans la préparation de cet article.
– Le contenu de cet article a été initialement présenté en italien à une conférence organisée par www.libreriaparoleneltempo.it, Lecco, Italie.
– Toutes les opinions sont les siennes.
– Toutes les photos des personnes célèbres sont issues de wikipédia.

Apprendre sans le savoir ?

Les algorithmes d’intelligence artificielle dont nous entendons si souvent parler sont basés sur des apprentissages et des connaissances.  Ces notions sont à l’intersection de plusieurs domaines : sciences cognitives, sciences de l’éducation et désormais sciences du numérique.  A partir d’articles qu’Ikram Chraibi Kaadoud  a publié sur son blog Intelligence mécanique, nous vous proposons deux textes pour y voir plus clair ; voilà le premier. Pascal Guitton

Deux types de connaissances

Le raisonnement fait partie des fonctions exécutives chez l’humain [Chraibi Kaadoud & Delmas, 2018]. Il s’agit d’un processus cognitif de haut niveau qui permet à un individu de s’adapter à son environnement en fonction des informations perçues, de son expérience et de son objectif [Dubuc, 2002]. Cela permet par exemple de faire face à des situations complexes, d’interagir avec son environnement, ou encore d’établir des plans. Lors du processus de raisonnement, deux types de connaissances sont sollicitées : les connaissances explicites et implicites.

Connaissances explicites & implicites

Les connaissances explicites sont l’ensemble des connaissances qu’un individu peut mémoriser et récupérer consciemment puis exprimer par le langage. Elles sont souvent apprises sous forme verbale. Elles sont associées à la mémoire explicite qui concerne l’ensemble des événements biographiques (mémoire épisodique) et la mémoire des concepts et des objets (mémoire sémantique). Ces connaissances, formalisables et transmissibles, sont exprimables par l’individu et peuvent donc être stockées sur un format extérieur (document, rapports, etc.). Elles sont considérées facilement extractibles puisque facilement verbalisables.

A contrario, les connaissances implicites sont non exprimables et celles dont l’individu n’est pas conscient. Elles sont liées à la mémoire implicite. L’apprentissage de telles connaissances est implicite : c’est par l’imitation, la pratique, le vécu et l’expérience, qu’un individu acquiert ce type de connaissances. Elles regroupent les connaissances procédurales (liées par exemple aux capacités motrices comme faire du vélo), celles liées à la mémoire perceptive (mémoires des formes, des couleurs, des odeurs, des sons), celles des réflexes et des apprentissages non-associatifs comme l’habituation et la sensibilisation. Ces connaissances sont importantes car elles sont associées au vécu d’une personne et ont une incidence directe sur le raisonnement. La connaissance implicite est présentée comme inflexible, inaccessible et liée à la nature de l’information (i.e. aux caractéristiques du matériau) utilisé lors de l’apprentissage.

Figure A : Différentes mémoires à long terme.

La compréhension de ce type de connaissance, son acquisition et son extraction ont fait et font encore l’objet de nombreux travaux de recherche. Il existe notamment un paradoxe dans cette connaissance implicite : c’est à la fois la plus recherchée (liée à l’individu, elle porte plus d’information que des données), mais c’est aussi la moins accessible.

Or quand il convient de partager son savoir avec autrui, surtout son expertise, son savoir-faire et son expérience, sur un domaine en particulier, c’est l’ensemble des connaissances implicite et explicite qu’il faudrait partager.

Enjeu en entreprise

En entreprise, le partage et la transmission des connaissances est un réel axe stratégique. L’extraction de l’expertise, c’est à dire des compétences spécialisées et poussées dans un domaine, est d’autant plus complexe qu’il existe plusieurs stades d’acquisition de ces compétences en fonction desquels, les experts – personnes surentrainées, qui ont acquis des habilités particulières par leur expérience et qui ont notamment connu une migration de leur connaissances explicites à un savoir-faire implicite – peuvent ou non verbaliser leurs connaissances.

En effet, notre cerveau transforme les connaissances acquises au fur et à mesure que l’on monte en compétences. Conduisez-vous aujourd’hui comme lors des premiers jours de l’obtention de votre permis ? Il est fort probable que non !

Apprendre sans le savoir, est-ce possible ?

Mémoire et apprentissage implicite

Les connaissances implicites sont liées à la mémoire implicite. Cette dernière se distingue de la mémoire explicite d’une part au niveau de l’apprentissage utilisé pour acquérir les connaissances et d’autre part au niveau de l’utilisation de ces connaissances.

La majorité des preuves de l’existence d’un système de mémoire implicite sont basés sur des travaux dans lesquelles une modification des performances des participants a été observée pour une tache donnée durant les expériences menées, et cela sans que les participants ne soient conscients d’avoir appris quoi que ce soit. On parle alors d’apprentissage implicite.

Un exemple typique de ce type d’apprentissage est le langage. C’est par la pratique (répétition et imitation) que le langage s’apprend chez l’enfant (langue maternelle), et non par l’apprentissage explicite des règles grammaticales. Or l’enfant n’est pas conscient du fait de son jeune âge, entre autres, de l’apprentissage qu’il est en train de réaliser.

Ce phénomène d’apprentissage implicite a été étudié pour différentes tâches appliquées à différents types d’informations (grammaire ou musique) et différentes populations (adulte et enfants).

En 1999, deux chercheurs de l’université de Bourgogne, Annie Vinter, chercheuse en psychologie du développement et Pierre Perruchet, chercheur étudiant la place de l’inconscient dans les apprentissages, ont notamment définit l’apprentissage implicite comme « un mode adaptatif par lequel le comportement des sujets se montre sensible aux caractéristiques structurales d’une situation à laquelle ils ont été préalablement exposés, sans que l’adaptation qui en résulte soit due à une exploitation intentionnelle de la connaissance explicite des sujets concernant ces caractéristiques ». En d’autres termes, le terme d’apprentissage implicite recouvre toutes les formes d’apprentissage qui opèrent à l’insu du sujet, sans que ce dernier soit conscient du fait qu’il est en train de modifier de manière stable son comportement [Witt, 2010].

Les circonstances de ce type d’apprentissage sont donc plutôt accidentelles qu’intentionnelles, ce qui ne l’empêche pas d’être considéré robuste et indépendant des mécanismes explicites. L’apprentissage implicite possède par ailleurs un bon maintien dans le temps, mais ne permet pas de transfert des connaissances assimilées à de nouvelles situations.

Apprentissage implicite :  Comment fonctionne-t-il ?

Grace à la structure statistique de l’environnement ! Autrement dit, la présence répétée d’une même suite de symbole en fait une règle implicite. Plus cette suite sera présente, plus la règle est prise en compte. Par exemple, considérons les débuts de séquences suivantes :

BTS.., BTSX…, BTX, …

BPTTTT…, BPTV…., BPV…

Le symbole B étant souvent suivi de P ou T dans l’ensemble des séquences, laisse émerger l’intuition d’une règle stipulant que « B est toujours suivi de P ou de T ». La fréquence d’apparition d’un phénomène en fait une règle !

L’apprentissage implicite extrait donc la structure statistique de l’environnement (ici les séquences). C’est ce qui permet aux mécanismes d’apprentissage implicite de produire donc des performances améliorées à la suite de répétitions.

En 2006, Jean Emile Gombert, un psychologue et professeur d’université français, spécialisé dans la psychologie de l’enseignement et celle du développement, affirme d’ailleurs à ce propos que « le moteur des apprentissages implicites est de nature fréquentielle » : la fréquence d’exposition à des éléments associés est fondamentale pour que le phénomène d’apprentissage implicite ait lieu et cela indépendamment de l’intention de l’apprenant.

En résumé, et s’il ne fallait retenir qu’une chose, c’est qu’il existe chez l’humain une capacité d’apprentissage séquentiel implicite. Cette dernière se manifeste dès lors que l’individu est soumis de manière répétée à une même séquence d’événements et permet une amélioration de la performance sans que l’individu en soit conscient. C’est l’apprentissage implicite qui nous permet d’acquérir des connaissances implicites, importantes pour l’acquisition de l’expérience.

Coté informatique et IA ?

A l’heure où la cognition humaine est une source d’inspiration pour les modèles d’apprentissage machine (Machine Learning) dans le domaine de l’Intelligence artificielle, la compréhension de l’apprentissage chez l’humain revêt une double importance : D’une part, l’humain étant la machine la plus puissante pour le traitement de l’information, adaptable, adaptée et flexible, cela nous permet d’aller toujours plus loin dans la conception de nouveaux modèles d’IA. Mais surtout comprendre l’apprentissage de l’humain et le fonctionnement cognitif et mnésique, amène aussi à se poser la question de l’impact des biais cognitifs humains sur les algorithmes d’IA et de comment y remédier. Un humain étant la somme de son vécu et ses expériences, et un algorithme de machine Learning étant le résultat de son apprentissage sur des données en particulier selon des paramètres donnés, une IA n’apprend-elle pas implicitement les biais présents dans les données et par conséquent les biais de humains à l’origine de ces données ?

A l’échelle d’une entreprise, qui représente -entre autres- la somme des collaborateurs qui la constitue, comment est-ce que les connaissances implicites et explicites viennent-elles impacter son fonctionnement ?  Et quel est le lien avec le domaine du numérique ?

Cela semble être une autre histoire, un autre article !

Ikram Chraibi Kaadoud, alors Doctorante Inria au sein de projet Mnemosyne.

Références :

Référence principale :

L’article est adapté des travaux de thèse de l’autrice :

Chraibi Kaadoud, I, 2018. Apprentissage de séquences et extraction de règles de réseaux récurrents : application au traçage de schémas techniques. Thèse de doctorat, Université de Bordeaux. URL : https://tel.archives-ouvertes.fr/tel-01771685, page 1 – 18.

Vous pouvez vous y référez pour de plus amples références bibliographiques ainsi que des explications plus détaillées.

Autres références

Chraibi Kaadoud, Ikram et Delmas, Alexandra. 2018. La cognition ou qu’est-ce que les sciences cognitives?. Publication sur le blog de http://www.scilogs.fr/intelligence-mecanique, URL : http://www.scilogs.fr/intelligence-mecanique/la-cognition-ou-quest-ce-que-les-sciences-cognitives/

Dubuc, Bruno, 2002. Mémoire et apprentissage. URL : http://lecerveau.mcgill.ca/flash/i/i_07/i_07_p/i_07_p_tra/i_07_p_tra.html

Witt, Arnaud, 2010. L’apprentissage implicite d’une grammaire artificielle chez l’enfant avec et sans retard mental : rôle des propriétés du matériel et influence des instructions. Thèse de doctorat, Université de Bourgogne.URL : http://www.theses.fr/2010DIJOL019

D’où viennent les bugs en informatique ?

Jean-Marc Jezequel, est Professeur d’informatique à l’Université de Rennes 1 et directeur de l’IRISA. Il a reçu en 2016 la médaille d’argent du CNRS. Jean-Marc nous explique d’où viennent ces petites bêtes que sont les bugs qui régulièrement nous dérangent dans nos activités numériques et peuvent coûter cher… et nous emmène au fond des enjeux théoriques et techniques de cette déboguisation.  Pierre Paradinas
Photo : Univ Rennes 1, Dircom/Cyril Gabbero

Le processus de création du logiciel est assez extraordinaire. D’un coté, il est si facile d’écrire des programmes simples qu’un enfant de 6 ans peut, après seulement quelques minutes de formation, déjà réaliser des programmes spectaculaires avec des langages comme Logo ou Scratch.

Mais d’un autre coté, il est si difficile d’écrire des programmes complexes que, fondamentalement, personne n’est capable d’écrire de grands programmes sans bugs. Pour écrire un programme de 100 lignes de code source, la méthode ou le langage de programmation utilisé n’a pas vraiment d’importance, et si vous échouez, vous pouvez tout simplement recommencer à zéro à très peu de frais. Cependant, il est bien connu depuis l’époque des années 70 où Fred Brooks a écrit son livre « The Mythical Man Month », que la rédaction d’un programme de 100 000 lignes est beaucoup plus difficile que 1000 fois l’effort nécessaire pour écrire un programme de 100 lignes.

Courtesy of the Naval Surface Warfare Center, Dahlgren, VA., 1988. U.S. Naval History and Heritage Command Photograph. Catalog #: NH 96566-KN

D’où vient cette complexité, cause première de l’occurrence de « bugs » dans les programmes informatiques? En mettant de côté les vrais « bugs » (voir photo au dessus), les fautes de frappes et autres étourderies qui sont pour l’essentiel éliminées à la source dans les environnements de développement modernes, nous pouvons classer leurs principales sources en 3 catégories fondamentales : complexité inhérente, complexité due à la taille, et complexité due à l’incertitude.

Complexité inhérente des logiciels

Cela est dû aux racines du logiciel, comme expliqué dans la théorie du calcul universel d’Alan Turing, à l’origine de l’informatique. Même les programmes extrêmement courts et simples peut être impossible à prouver ou même avoir des propriétés indécidables, c’est à dire que l’on ne peut pas prouver qu’elles sont vraies, ni qu’elles sont fausses. Des choses très simples, comme savoir si une variable a une certaine valeur, ou si on va passer par une certaine instruction, ou si on va faire une division par 0 à un moment donné, ne sont dans le cas général, tout simplement pas prouvables. En d’autres termes, répondre à la question : « ce petit bout de code a-t-il un bug? » n’est en général pas possible. C’est donc une limitation intrinsèque de la nature de ce qu’est un logiciel, pris en tant qu’objet mathématique.

Petite illustration de la difficulté à prouver même des programmes simples, issue de la conjecture de Syracuse. Prenons ce petit programme :
Lire une valeur positive:
Tant que n > 1 faire
   si n est pair
   alors n prend la valeur n / 2
   sinon n prend la valeur 3 n + 1
Fin du tant que
Sonner alarme

Peut-on prouver que l’alarme est sonnée pour tout n ?
En fait on ne sait pas si on peut le prouver, ni même si c’est vrai (car c’est une traduction informatique de la célèbre conjecture de Syracuse).
Mais si je suis ingénieur et que je dois me rassurer sur le fait que ce code n’a pas de bug, j’ai usuellement recours au test, c’est-à-dire que j’essaye pour différentes valeurs de n, et je regarde si l’alarme est sonnée à chaque fois. Mais je n’aurai aucune certitude tant que je n’aurai pas essayé toutes les valeurs, c’est à dire pour une machine 32 bits, 2^31, soit environ 10 milliards de cas de tests pour ces malheureuses 6 lignes de code. Tester exhaustivement un logiciel un tant soit peu complexe est donc en pratique impossible.

Complexité due à l’échelle.

Un être humain a la capacité de le comprendre dans son intégralité un logiciel relativement petit, mais rapidement, quand celui-ci grandit, la compréhension complète devient difficile. Ceci n’est, au contraire du cas précédent, pas propre à l’informatique, et se retrouve sous une forme ou une autre dans tout domaine d’ingénierie complexe. Il faut cependant savoir que les logiciels grandissent à peu près d’un facteur 10 tous les 10 ans (à notre époque du Covid-19, tout le monde est maintenant familier avec la signification d’une croissance exponentielle). De plus, l’une des caractéristiques des logiciels est qu’ils relèvent des sciences discrètes (le « numérique ») et non pas continues (comme c’est généralement le cas en physique, sauf aux échelles quantiques). Ils peuvent être constitués de centaines de millions de pièces individuelles, toutes différentes, interagissant entre elles de manière complexe et non linéaire, voire chaotique. C’est à dire qu’un petit problème, à un moment donné, peut se propager et complètement mettre par terre l’ensemble du logiciel (c’est le bug !), ce que l’on ne va pas trouver dans d’autres disciplines d’ingénierie beaucoup plus continues : ce n’est pas parce qu’il y a un écrou qui saute d’un pont que le pont va s’écrouler, alors que l’équivalent dans un logiciel peut faire s’écrouler l’ensemble (voir à ce propos E. Dijkstra).

Dans cette dimension de complexité, Fred Brooks (encore lui) avait identifié deux sous-catégories : la complexité essentielle et la complexité accidentelle. La première est inhérente au problème que le logiciel doit résoudre, et peut découler, par exemple, de la variété des événements ou des données d’entrée qui doivent être correctement traités par le logiciel, ou encore de la criticité des fonctions qu’il doit réaliser, comme dans le cas des logiciels de contrôle d’un avion commercial. La complexité accidentelle provient en revanche de choix technologiques inappropriées au contexte (ou qui furent appropriés mais qui ne le sont plus), ce qui conduit à des efforts humains importants (voire démesurés) consacrés au développement et à la maintenance du logiciel. Le fiasco du logiciel de paye de l’armée française en est sans doute un exemple parmi tant d’autres.

Complexité due à l’incertitude

Cette dimension de complexité, n’ayant à nouveau rien à voir avec les deux premières, est liée au fait que les logiciels ne sont pas seulement des algorithmes abstraits, mais sont plongés dans le monde réel. Le raisonnement mathématique s’arrête à la limite de ce passage dans le monde réel, puisque qu’il ne peut atteindre qu’un modèle du monde, et non la réalité de celui ci. Or dans le monde réel, les logiciels sont comme pris en sandwich entre d’une part la machine sur laquelle ils s’exécutent et d’autres part les humains qui les utilisent. Or il y a toujours un écart entre le logiciel et ce qu’on est capable de savoir formellement sur son environnement : la réalité de la machine d’une part et la réalité de ce que veulent les humains d’autre part. En particulier sur les grands logiciels ayant de multiples parties prenantes, beaucoup d’utilisateurs aux métiers très différents doivent interagir. Les exigences auxquelles doit se conformer le logiciel, notamment les règles commerciales ou juridiques et le comportement humain attendu sont généralement non seulement incomplètes mais encore évoluent avec le temps. Cela conduit à des exigences qui peuvent être floues, voire contradictoires, instables et donc source de malentendus. Ceci est en pratique la plus grande source de bugs des logiciels. Mais l’incertitude dans le développement de logiciels provient aussi de nombreuses autres sources : par exemple les hypothèses sur le monde dans lequel évolue le logiciel sont généralement assez grossières, implicites, et sauf pour les projets les plus critiques (avionique, centrales nucléaires…), ne prennent pas en compte de tous les cas particuliers. L’incertitude peut encore provenir de la machine sur laquelle s’exécute le logiciel, soit de manière inhérente (pannes de matériel ou même simples perturbations sur le réseau), ou accidentellement en raison, par exemple, de mauvaises interprétations ou de modifications des API. Ainsi même un logiciel comme le compilateur CompCert prouvé correct dans le monde abstrait (ce qui est en soi une prouesse intellectuelle qui force le respect), se révèle truffé de bugs lorsqu’on le teste pour de vrai dans certains contextes un peu tordus (les recoins glauques de la norme du langage C, ou les comportements surprenants de certaines architectures de processeurs).

Et tout ceci sans même compter les cyber-attaques et autres altérations malveillantes de l’environnement de notre logiciel. Ce tableau est bien sombre, mais bien sûr les chercheurs et les ingénieurs ne sont pas restés les bras croisés devant ces difficultés.

Pour faire face à la complexité inhérente aux logiciels, on a inventé toute une gamme de techniques allant de la preuve formelle complète d’éléments de logiciels sous certaines hypothèses, à la construction d’une forme de confiance avec des mécanismes tels que la conception par contrat ou les tests unitaires, qui ne peuvent en aucun cas suffire, mais c’est déjà bien mieux que ne rien faire.

En raison de la capacité limitée de l’esprit humain (personne ne peut comprendre pleinement un million de lignes de code), faire face à la complexité due à l’échelle ne peut se faire que par l’abstraction et la modularité. En effet si un programme d’un million de lignes est composé de 10 modules, chacun composé de 10 sous-modules, chacun composé de 10 autres sous-modules, et chacun de ces modules de 1000 lignes de code, alors je peux à la fois comprendre « totalement » un module donné et comment il s’intègre dans les 999 autres, à condition d’avoir un résumé hiérarchisé (abstraction) pour la compréhension de ces derniers (ce qu’ils font, pas comment ils le font).

Pour faire face à la complexité due à l’incertitude, il faut intégrer la gestion de l’incertitude au processus de développement, ce qui est par exemple en partie le cas des méthodes dites « agiles », avec leurs retours fréquents vers les utilisateurs finaux pendant la phase de développement. Il faut aussi être capable d’anticiper correctement les zones des changements éventuels, en identifiant et en isolant (ou du moins en réduisant le couplage avec) les parties incertaines, et donc qui pourraient changer. C’est l’idée de la séparation des préoccupations, ainsi que la gestion explicite des variations, selon les deux dimensions de l’espace (existence de plusieurs variantes simultanées pour prendre en compte des particularités locales ou des contradictions dans les exigences) et du temps (existence de versions successives).

Sur ce dernier plan, les recherches actuelles portent sur le fait de donner de la flexibilité sur comment et quand peut être prise la décision de choisir une variante dans le cycle de vie des logiciels : au moment de la formulation des exigences (domaine de l’ingénierie des exigences), au moment de la conception (domaine des lignes de produit logiciels), ou au temps de l’exécution (domaine des systèmes adaptatifs), avec à l’intersection de ces deux domaines, le temps de la compilation, du chargement, et celui de la compilation à la volée, dite « Just In Time ».

L’ensemble de ces dimensions forme ce que l’on appelle de nos jours les sciences du logiciel, qui, aux frontières des mathématiques et de l’ingénierie des systèmes complexes sont des domaines passionnants où beaucoup reste encore à découvrir.

Jean-Marc Jézéquel (@jmjezequel)

Pour en aller plus loin :

Le livre de Brooks

 

Chercheur·e·s en sciences du numérique ? Venez publier sur un site ami !

 

La médiation scientifique ? On pense que c’est souvent l’affaire de vieux chercheurs, Ikram Chraibi-Kaadoud  prouve le contraire ! Thierry Viéville.

 

Piger l’intelligence naturelle et artificielle.

Du robot au smartphone elle se demande avec nous quelle forme et qu’elle part d’intelligence mécanique contiennent ces machines, sur son blog scientifique http://www.scilogs.fr/intelligence-mecanique proposé par Pour la Science.

L’originalité scientifique de cette collègue qui a travaillé sur l’apprentissage de séquences et l’extraction de règles en utilisant des réseaux récurrents de neurones artificiels  est d’aborder ces questions liées à l’intelligence artificielle en privilégiant notre compréhension des fonctions cognitives au niveau de l’intelligence biologique, elle nous aide à mieux comprendre comment marchent ces algorithmes qui ajustent leurs calculs en fonctions de données mais aussi comment fonctionne notre pensée.

Et si on participait ?

Ikram lance un appel à contribution et invite tou·te·s les collègues qui travaillent en lien avec ces sujets, à partager ce qui va permettre à chacune et chacun de mieux comprendre, de démystifier, de développer un esprit critique vis à vis de sujets, bref de décider quoi faire au mieux avec les technologies disruptives créées par ces disciplines scientifiques.

Son appel est doublement original :

– (i) English contribution are welcomed :  elle propose ici d’offrir le service à ces jeunes étudiant·e·s venu de l’international et qui travaillent avec nous dans nos équipes de recherche de partager leurs travaux avec le public francophone,

– (ii) Un vrai mécanisme éditorial : depuis des années, côté Inria et ailleurs aussi,  le fait de ne pas publier uniquement des articles scientifiques pour les spécialistes mais aussi des articles de popularisation pour aider à faire le lien entre science et société est reconnu comme un point positif lors des évaluations, et réalisé de telles publications, validées et reconnues, ouvertes et librement réutilisables est un point fort de cette proposition.

Bien entendu, les contributions ne se limitent pas à des autrices ou auteurs académiques, les collègues ingénieur·e·s et même les curieux/ses de science sont bienvenu·e·s.

   Vers l’appel à contributions pour des articles
de vulgarisation sur le blog de « Pour la Science ».

Alors … à nos claviers !

Raconte-moi un algorithme : éternelle cadette

En 2020, chaque mois, Charlotte Truchet et Serge Abiteboul nous racontent des histoires d’algorithmes. Des blockchains aux algorithmes de tri en passant par le web, retrouvez tous leurs textes, ainsi que des petits défis mathématiques, dans le Calendrier Mathématique 2020 et dans la série binaire associée… Antoine Rousseau

Juin : Éternelle cadette

 

Si vous avez, disons, une grande sœur de deux ans votre aînée, lorsque vous étiez enfant vous avez probablement eu des pensées du genre : certes, je n’ai que 4 ans alors que ma sœur en a 6, mais un jour j’aurai 7 ans et je la dépasserai ! Et pourquoi pas, après tout ? C’est logique : chaque année, vous gagnez un an, vous aurez donc forcément 7 ans un jour ou l’autre. Certes, votre sœur aussi gagne parfois un an, mais c’est compliqué, négligeons ce détail… Bien sûr, une fois adulte, vous vous rendez compte que cette ambition est vouée à l’échec : une grande soeur sera toujours plus grande.
En informatique, les propriétés (comme « être plus vieille »), qui sont toujours vraies pendant l’exécution d’un programme, s’appellent des invariants. Peut-on démontrer qu’il y a un invariant comme “être la plus vieille” pour un programme qui prendrait en entrée un entier n (l’année pour laquelle on fait le calcul) et calculerait vos deux âges cette année-là le jour de votre anniversaire ? La difficulté c’est que, dans ce programme, les deux âges ne seraient sans doute pas directement reliés par un calcul. Il n’est donc pas immédiatement évident que votre âge reste inférieur à celui de votre sœur. On pourrait laisser tourner le programme, année après année, et vérifier à chaque fois. Si on ne met pas de borne, la vérification ne s’arrêtera jamais. Alors ajoutons une borne, mais… laquelle ? 120 ans ? On a envie de prendre large, mais il ne faut pas oublier que plus la borne est grande, plus on a de calculs à faire. De plus, dans de nombreux programmes, il est impossible d’établir de telles bornes.
On peut aussi faire un raisonnement inductif : la propriété est vraie l’année de votre naissance, puisque votre grande soeur a deux ans et vous en avez 0. Si elle est vraie une année quelconque, l’année suivante les deux âges auront augmenté de 1 et donc la propriété est toujours vraie. Elle est donc éternellement vraie. On dit alors qu’on fait un raisonnement par récurrence. Ce genre de raisonnement est un des piliers de la vérification de programme, et on sait dans certains cas les algorithmiser. En vérifiant que certaines propriétés bien choisies sont toujours vraies quand on fait tourner un programme, on peut être sûr de ne pas rencontrer certains effets indésirables, par exemple que la valeur d’une variable devienne trop grande et dépasse les valeurs acceptées par la machine.
La démonstration automatique d’invariants est à la base de logiciels de vérification de codes informatiques. Ces logiciels servent en particulier à démontrer l’absence de bug dans des logiciels critiques, dans le transport aérien, les stimulateurs cardiaques, les centrales nucléaires… des situations où le coût d’un bug est jugé inacceptable. On sait aujourd’hui vérifier que le code machine d’un gros logiciel (le compilateur CompCert) est conforme à sa spécification dans un langage formel.

Serge Abiteboul et Charlotte Truchet