L’avenir des systèmes embarqués sera-t-il « Model-Based Design » ?

18 octobre 2017

En 2020, les algorithmes assurant le fonctionnement des quelque 20 milliards d’objets connectés qui peupleront nos existences (soit environ trente objets par foyer français selon Gartner) deviendront aussi importants que l’air que nous respirons. Mais qu’arrivera-t-il aux maisons, voitures et villes connectées si une faille apparaît dans la programmation ? The Atlantic a donné la parole à des experts pour le moins alarmistes sur la complexification déjà inquiétante du code. « Le problème est que les ingénieurs software ne comprennent pas le problème qu’ils tentent de résoudre, et ils s’en fichent », selon Nancy Leveson, une experte logiciel du MIT citée par la revue américaine. Le tragique accident, comme celui arrivé en 2007 à Jean Bookout au volant de sa Toyota, lorsque le système de navigation électronique du véhicule était resté bloqué sur l’accélérateur, feront-ils demain régulièrement les gros titres ? « Avec 100 millions de lignes de code dans une voiture aujourd’hui, vous ne pouvez pas tout anticiper », affirme le MIT. A l’âge de l’IoT, il est possible de conjecturer une telle multiplication des risques.

Pour éviter les scénarios catastrophes, le Communication Design Group, initiative financée par SAP, qui réunit des ingénieurs-programmeurs – dont Bret Victor, ancien ingénieur Apple, prône une nouvelle méthode, celle du «WYSIWYG (what-you-see-is-what-you-get)”, mais cette fois-ci, entièrement appliquée au code. L’objectif : sortir les codeurs de l’abstraction en leur donnant un aperçu instantané du langage qu’il est vital, selon lui, de simplifier. « Le problème le plus grave qui apparaît avec les logiciels provient des prérequis, et non d’erreurs de code (…) Depuis 40 ans, les ordinateurs ont doublé leur puissance tous les 18 mois. Pourquoi la programmation, n’a, elle, jamais évolué ? » interroge la revue américaine. L’enjeu autour de cette nouvelle manière de coder – également appelée approche « Model-Based Design » (MBD) – est de pouvoir identifier les erreurs liées au codage et de générer automatiquement du code – notamment pour les systèmes embarqués. A l’ère de la voiture autonome, elle devient aussi un enjeu business. Rappelons à cet effet que Toyota a du récemment rappeler 9 millions de véhicules et payer 3 milliards de dollars d’amendes suite des dysfonctionnements liés à des accélérations subites impulsées système embarqué.

L’idée de Bret Victor recoupe celle consistant à lutter contre le syndrome de la programmation spaghettis, un code impossible à maintenir, prédire, tester dans ses défauts de façon exhaustive. Ce qu’il manque dans le milieu des programmeurs est selon lui une représentation visuelle du comportement dynamique de nos systèmes.

Bret s’intéresse en effet à la façon dont le code peut être un outil de compréhension. Dans son talk, « Stop drawing dead fish », il prend ainsi deux exemples de programmes qu’il a lui-même conçus pour les réduire à jouer dans une interface et simuler ainsi en temps réel le programme informatique pour rendre compte de la connexion entre le comportement d’un système et son code immédiat.

Lors d’une autre vidéo-conférence « Inventing on Principle » portant sur le futur des interfaces de développement au CUSEC2012, il va jusqu’à interroger ainsi le rôle même des développeurs : « Si nous écrivons du code sur un ordinateur, pourquoi est-ce que nous simulons ce que l’ordinateur devrait faire dans notre tête ? Pourquoi l’ordinateur ne peut pas juste le faire et nous le montrer ? ».

Les ingénieurs ne devraient pas selon lui développer de grands systèmes complexes en tapant des millions de lignes de code dans un environnement de développement (IDE). L’enjeu serait d’aller vers une forme d’ingénierie générative, ou de façon plus pragmatique de s’appuyer sur la conception d’une classe d’outils et d’interfaces permettant une modélisation MBD et dans lesquels le développeur écrit des règles que le programme devrait suivre et où l’ordinateur génère le code en fonction de ces règles. L’inspiration est sous cet angle à chercher dans des solutions proposées par exemple par d’Eric Bantégnie, fondateur d’Esterel Technologies – une société française (rachetée par l’américain Ansys en 2012) qui fabrique des outils pour la construction de logiciels critiques pour la sécurité, ou encore Leslie Lamport, qui a créé le langage algorithmique TLA+, qui, tout comme l’approche MBD, vise à attirer l’attention sur les structures de haut niveau d’un système et sa logique essentielle, plutôt que sur le code qui l’implémente.

A l’instar de la période où nous sommes passés progressivement du « langage d’assemblage » au langage de programmation informatique type « C », les sceptiques brandissent à nouveau ce risque de perdre le contrôle face au code. Ce qui semble certain, c’est que le niveau de complexité impose de penser aujourd’hui les logiciels d’une manière différente, en évitant les biais de conception et en pensant le systèmes informatique non pas comme un produits ou un service – mais comme « un medium de la pensée ».

« Le code, c’est l’arbre qui cache la forêt : il attire votre attention sur le fonctionnement des pièces individuelles, plutôt que sur la façon dont votre programme est embarqué, ou sur ce qu’il est censé faire et s’il correspond à ce que vous aviez imaginé », résume ainsi The Atlantic.

Le futur des systèmes embarqués va-t-il donc nous renvoyer à une transition vers une informatique dirigée par les modèles (IDM) ? A suivre !

Hello Open World

Equipe de rédaction

Linkedin

A lire aussi

La communauté des leaders de l'innovation

Innovating in good company

Rejoignez-nous