Boîte noire et interface

Boîte noire et interface

On m’a souvent expliqué lorsque j’étais plus jeune qu’un logiciel peut être vu comme une boîte noire : on ne sait pas comment ça fonctionne à l’intérieur mais on sait ce que l’on peut en faire. Ça ne me suffisait pas, je ne comprenais pas comment les logiciels faisaient pour dialoguer ensemble. Une boîte noire, pourquoi pas, mais comment faire pour rentrer dans cette boîte noire ?

C’est ce qu’on va essayer de découvrir dans cet article : comment les logiciels sont structurés pour que les humains puissent interagir avec eux et comment ils font (les logiciels hein, pas les humains) pour se comprendre.

Les interfaces graphiques

Partons d’un exemple simple : si on prend un navigateur comme Mozilla Firefox ou Brave, on sait que l’on pourra naviguer sur internet avec, mettre des pages en favoris, bref, l’utiliser. Les logiciels graphiques disposent d’une interface utilisateur graphique ou IHM pour Interface Homme Machine (ou encore GUI pour Graphical User Interface). L’interface entre le logiciel et l’utilisateur est la fenêtre avec des boutons que vous voyez quand l’application est ouverte.

L'interface utilisateur de Firefox, le navigateur que j'utilise

Ce premier type d’interface est celui que tout le monde connaît. Du point de vue de l’interaction entre l’humain et le logiciel, deux flux d’informations sont présents :

  • L’humain informe le logiciel de l’action qu’il veut effectuer en cliquant sur des boutons ou en remplissant un champ de texte.
  • Le logiciel informe l’humain que l’action demandée a été effectuée en modifiant l’interface.
    Si on prend un exemple, vous êtes sur votre site favori et vous voulez descendre dans la page, vous utilisez soit la molette de votre souris, soit les flèches de la barre de défilement. Instantanément, le logiciel comprend votre action et en retour, il fait descendre la page.

Cette dualité est la base de toutes interfaces, même celles qui ne sont pas graphiques : lorsqu’on “parle” à l’interface, celle-ci nous répond (de préférence le plus rapidement possible) via cette même interface avec le résultat créé par le logiciel. La deuxième chose importante que l’on peut deviner ici est que toutes les actions que l’utilisateur va pouvoir faire avec le logiciel sont définies à l’avance, elles sont codées. De même, toutes les réponses apportées par le logiciel le sont. Une règle de base est que celui qui reçoit l’information définit comment on doit la lui donner, c’est à l’émetteur de se débrouiller pour formater le message correctement.

Pour l’instant, on a donc ce schéma :

Interaction entre un humain et un logiciel

Notez que le logiciel peut également avoir une action sur l’humain sous forme généralement de notifications : lorsque vous recevez un nouveau SMS, vous allez l’ouvrir.
Avant de voir comment les logiciels discutent ensemble on va faire un détour, descendre avec le lapin blanc et aller au pays des merveilles.

La première interface Homme <-> Machine, le terminal

Vous avez sans doute vu dans un film d’action un hacker fou qui rentre dans des systèmes sécurisés comme dans du beurre, le tout de sa chambre en pyjama en tapant pleine balle sur son clavier sans toucher la souris. On va se calmer tout de suite et plutôt prendre comme exemple l’excellente série Mr. Robot. Le héros Elliot est un hacker et utilise le terminal comme interface pour dialoguer avec les multiples logiciels qu’il utilise. Les créateurs de la série ont créé un jeu de piste en ligne dont on va se servir pour illustrer le fonctionnement du terminal. Allez sur whoismrrobot.com et après le chargement, cliquez sur EC_NY puis cliquez sur l’icône du terminal. Vous vous retrouverez avec une fenêtre de ce style :

“Desktop” signifie que vous êtes actuellement sur le bureau. Essayer de taper la commande “help” pour afficher l’aide. On vous dit quelles sont les commandes disponibles et on va utiliser ls, la commande pour lister les fichiers et dossiers qui existent dans le dossier dans lequel on se trouve. Sans surprise, on retrouve tous les fichiers et dossiers qui sont sur le bureau virtuel.

La commande ls

Je vais m’arrêter là, rendre son terminal à Elliot et analyser un peu ce que l’on vient de faire. Encore une fois, l’humain en tapant une commande vient de donner une action à faire au logiciel. Le logiciel a répondu en donnant la liste des fichiers présents dans le dossier dans lequel l’utilisateur se trouve.
Plus précisément, l’humain a tapé la commande ls dans le terminal, celui-ci a invoqué le logiciel ls qui s’est ouvert, a affiché le résultat (les fichiers et dossiers contenus sur le bureau) et s’est fermé tout de suite après. Le terminal est une des façons les plus simples de communiquer avec un ordinateur. Il est même possible de travailler exclusivemet avec le terminal si on n’a pas besoin de résultat graphique comme des images.
Le serveur sur lequel est hébergé ce blog par exemple n’a pas d’interface graphique, tout ce fait en ligne de commande. Pour mettre mon site en ligne, je n’ai besoin de taper qu’une seule commande dont on reparlera :

$ docker-compose up -d

“C’est bien gentil ton histoire de terminal de hacker mais à la base on devait parler d’interfaces logiciels non ?” Tout à fait Watson et on va s’y attaquer maintenant.

Les interfaces entre logiciels

Vous avez entendu parler d’API ? Eh bien c’est le sujet précis du paragraphe : les interfaces de programmation d’application ou Application Programming Interface en anglais. Ce sont les interfaces les plus intéressantes pour moi car elles permettent non seulement d’interagir avec des logiciels de façon très précise mais elles permettent en plus de mieux comprendre comment ceux-ci fonctionnent. Et vous savez comment ces interfaces fonctionnent ? Eh bien exactement comme entre les humains et les machines : via actions/réactions.
Je vous propose un petit exemple en m’appuyant sur le précédent article qui parlait des systèmes d’exploitations. On a vu qu’un OS se positionne entre le matériel et les applications. Ce qu’on peut rajouter maintenant et qu’une application interagit avec l’OS via l’API du système d’exploitation.

Un exemple ? L’application qui vous permet de parcourir les dossiers qui sont sur votre PC Windows se nomme File Explorer. Lorsque vous demandez la création d’un nouveau dossier (clic droit -> créer un dossier ou CTRL + MAJ + N), File Explorer va faire un appel à l’API de Windows (action) pour demander la création d’un nouveau dossier. Windows va demander à votre disque dur via l’interface de son driver de créer le dossier “physiquement”. Si le disque dur a assez de place, il crée le dossier, répond à l’OS que l’action s’est bien déroulée. Seulement après ça, Windows répond à File Exploreur que le dossier a été créé. File Explorer va ensuite vous afficher un nouveau dossier, le tout en quelques millisecondes. On peut résumer cette série d’actions par ce diagramme :

Création d'un dossier

Évidemment, ce que je viens de décrire est très simplifié, il y beaucoup plus d’étapes entre l’action que l’humain fait et l’écriture sur le disque dur. C’est le but de la boîte noire et de l’interface : on cache le fonctionnement du logiciel dans la boîte noire et on fait une belle interface pour qu’un autre logiciel ou un humain puisse interagir avec en connaissant :

  • le format d’appel a l’API
  • le format de retour de l’action

Le fait de faire un appel à une API et d’avoir un retour est appelé une transaction et si vous observez bien autour de vous, vous découvrirez que beaucoup de services (public ou privé) sont bâtis sur ce principe. Lorsque vous allez à la boulangerie pour acheter un éclair au chocolat, l’action est de demander un éclair et donnant de l’argent (défini à l’avance) et le retour et de recevoir un truc beaucoup trop bon.

En résumé

Deux grands types d’interface existent : les interfaces utilisateur qui peuvent être graphique ou via un terminal et les APIs. Tous les logiciels discutent entre eux via des APIs et pour communiquer, ils s’envoient des requêtes. L’émetteur fait un appel (call) à l’API du récepteur. Le récepteur traite la demande, peut-être en faisant d’autres appels à d’autres API. Lorsque le récepteur a toutes les informations nécessaires, il répond à l’émetteur. L’appel et la réponse sont appelés une transaction.

La semaine prochaine, on met tout ça en pratique en faisant des appels aux APIs que le gouvernement met à disposition et on regardera ce qu’elles nous répondent.

Commentaires

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×