FR 2917521 A1 20081219 FR 0755789 A 20070615 Plus précisément, les manuels AMM et TSM se présentent désormais sous la forme de documents électroniques dans laquelle l'opérateur de maintenance peut librement naviguer grâce à des hyperliens. Ces documents contiennent une description des équipements de l'aéronef et des pannes qui peuvent les affecter, permettant à l'opérateur de maintenance d'identifier et de résoudre la panne. De manière similaire, le journal de bord se 10 présente aussi sous la forme d'un document électronique, dit eLogbook . Les documents électroniques précités sont également liés entre eux au moyen d'hyperliens, de sorte que l'opérateur peut aisément passer d'une 15 application à l'autre. En outre, un système de maintenance centralisé, dit CMS (Centralised Maintenance System) permet de lancer le test d'un équipement à distance lorsque celui-ci est équipé d'un module de test intégré 20 ou BITE (Built In Test Equipment), de recevoir les messages d'erreurs éventuels et de les corréler entre eux ou avec des pannes de manière à faciliter le diagnostic. L'opérateur de maintenance a donc à sa 25 disposition une pluralité d'outils informatiques disparates qu'il doit maîtriser pour pouvoir diagnostiquer et résoudre une panne éventuelle. En outre, ces outils de maintenance présentent un certain nombre d'insuffisances : 30 Tout d'abord, l'opérateur n'est pas guidé de manière systématique dans son diagnostic : il est libre de suivre la procédure qui lui semble la plus appropriée et, le cas échéant, de sauter des étapes de test voire d'inverser l'ordre indiqué dans le manuel, avec le risque d'une convergence plus ou moins rapide selon les options qui auront été prises. Ensuite, dans les avions de conception récente, du fait de la partition du réseau embarqué en une zone sécurisée et une zone non sécurisée, il est délicat de prévoir où seront hébergées les applications informatiques relatives à la maintenance. Plus précisément, le réseau embarqué est généralement partitionné en deux sous-réseaux, le premier localisé dans une zone dite avionique, le second dans une zone dite ouverte ou non sécurisée. Les liaisons entre les deux sous-réseaux sont obligatoirement unidirectionnelles, dirigées du sous-réseau avionique vers le sous-réseau ouvert. En revanche, à l'intérieur d'un même sous-réseau les liaisons peuvent être bidirectionnelles. L'hébergement des outils de maintenance dans la zone ouverte ne permettrait pas de garantir leur intégrité, autrement dit de se premunir efficacement contre un accès malveillant et/ou une corruption des programmes et des données qui les constituent. Par voie de conséquence, les outils de maintenance ne seraient pas susceptibles de faire l'objet d'une certification. En outre, une mauvaise utilisation des outils de maintenance (tests intempestifs ou incohérents) pourrait être préjudiciable au bon fonctionnement des systèmes de la zone avionique. A l'inverse, un hébergement de ces outils dans une zone avionique ne serait guère envisageable car il nécessiterait un développement d'applications spécifiques, particulièrement coûteux, et n'autoriserait pas la possibilité d'effectuer de fréquentes mises à jour. Un but de la présente invention est de proposer un outil de maintenance d'un aéronef qui ne présente pas les inconvénients précités, c'est-à-dire, d'une part, qui permette de guider l'opérateur de manière systématique et d'autre part, qui offre une implémentation compatible avec la partition du réseau embarqué. EXPOSÉ DE L'INVENTION La présente invention est définie par un système informatique de maintenance d'un aéronef équipé d'un réseau partitionné en une zone sécurisée, dite avionique, et une zone ouverte, ledit système informatique comprenant un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier module étant adapté à parcourir un arbre de diagnostic, le second module étant adapté à présenter une documentation électronique de maintenance, le parcours de l'arbre de diagnostic par le premier module induisant de manière automatique et synchrone une présentation par le second module de pages de ladite documentation de maintenance respectivement associées à ces nœuds. Avantageusement, chaque noeud dudit arbre de diagnostic correspond au moins une tâche de maintenance et que le premier module transmet au second module un hyperlien pointant vers une page de la documentation de maintenance associée à cette tâche lorsque le premier module atteint ledit noeud. Le premier module détermine typiquement le noeud suivant en fonction du résultat de l'exécution de ladite tâche de maintenance correspondant à ce noeud. L'arbre de diagnostic est déterminé par exemple à partir d'un code identificateur de panne, ledit code étant lui-même obtenu à partir d'une analyse d'une entrée d'un journal de bord électronique hébergé dans la zone avionique. Si le premier module détermine qu'un équipement de l'aéronef est défaillant au terme du parcours de l'arbre de diagnostic, ledit système peut être adapté à vérifier la présence de cet équipement dans une liste minimale d'équipements de l'aéronef, dite liste MEL, hébergée dans la zone avionique. Si ledit équipement défaillant est présent dans la liste MEL, le système est adapté à calculer le coût correspondant en termes de pertes de performances fonctionnelles ou de marges de sécurité de l'aéronef. On peut prévoir en outre un troisième module logiciel, hébergé dans la zone avionique, et un quatrième module logiciel, hébergé dans la zone ouverte, le troisième module étant adapté à parcourir et sélectionner les éléments de la liste MEL, le quatrième module logiciel à présenter des pages de documentation correspondant aux dits équipements, la sélection d'un élément par ledit troisième module logiciel induisant de manière automatique et synchrone une présentation par le quatrième module d'une page de documentation relative à cet élément. Pour chaque élément de la liste MEL, le troisième module transmet avantageusement au quatrième module, un hyperlien pointant vers une URL contenant ladite page de documentation relative à cet élément. Le premier module et, le cas échéant le troisième module, peut(peuvent) être hébergé(s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, peut(peuvent) être hébergé(s) dans un second ordinateur de la zone ouverte, le second ordinateur étant alors relié à la partie du réseau de la zone avionique par une liaison unidirectionnelle vers la zone ouverte et un point d'accès sans fil. Selon une variante, le premier module et, le cas échéant le troisième module, peut(peuvent) hébergé(s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, peut(peuvent) hébergé(s) dans un second ordinateur de la zone ouverte, les entrées/ sorties des premier et second ordinateurs étant reliées à un commutateur KVM, ledit commutateur étant adapté à commuter lesdits entrées/sorties vers une interface d'entrée/sortie commune. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention fait en référence aux figures jointes parmi lesquelles : La Fig. 1 illustre schématiquement un premier mode de réalisation du système de maintenance selon l'invention ; La Fig. 2 illustre schématiquement une variante de réalisation du système de maintenance selon l'invention ; La Fig. 3 illustre l'opération du système de maintenance selon l'invention ; La Fig. 4 donne un exemple d'arbre de diagnostic ; Les Figs. 5A à 5G représentent le contenu d'un premier écran et d'un second écran du système de maintenance, lors de la progression du module de diagnostic le long de noeuds successifs de l'arbre de diagnostic. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'idée à la base de l'invention est de prévoir un système de maintenance comportant un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier étant un module de diagnostic adapté à effectuer un parcours dans un arbre de diagnostic, le second étant dédié à la présentation de la documentation de maintenance, le parcours de noeuds de l'arbre de diagnostic induisant de manière automatique et synchrone une présentation des pages de documentation respectivement associées à ces noeuds. La Fig. 1 illustre un système informatique de maintenance selon un mode de réalisation de l'invention. Le système est composé de deux parties 101 et 102 respectivement comprises dans la zone avionique AW et la zone ouverte 0W. Chacune des parties du système comprend une pluralité d'équipements reliés entre eux grâce à des liaisons bidirectionnelles, par exemple des liaisons virtuelles d'un réseau Ethernet commuté. En revanche, les deux parties ne sont reliées entre elles que par une ou plusieurs liaison(s) unidirectionnelle(s) dirigée(s) de la zone AW vers la zone OW, symbolisées sur la figure par des diodes. La partie de la zone avionique comprend un terminal de maintenance 110 ou OMT (Onboard Maintenance Terminal) hébergeant un système de maintenance centralisé (CMS), 113. Ce système comprend notamment un premier module logiciel, dit module de diagnostic, 115, adapté à parcourir un arbre de diagnostic prédéterminé. Le terminal OMT héberge également un module logiciel 120, chargé de la gestion du journal de bord. Le terminal OMT est par ailleurs relié à des modules de test intégrés, 130, implémentés dans certains équipements à tester, ainsi qu'à une unité 160 chargée de contrôler l'ensemble des disjoncteurs relatifs à ces équipements. L'activation d'un disjoncteur permet de couper l'alimentation d'un ou de plusieurs équipements pour procéder à son remplacement en toute sécurité. Enfin, le terminal OMT possède une interface entrée/sortie 150 comprenant notamment un écran d'affichage et un clavier. La partie du système dans la zone ouverte comprend un terminal permettant la consultation de la documentation de maintenance, ci-après dénommé terminal d'information. Ce terminal peut par exemple prendre la forme d'un ordinateur portable, 190, ou d'une ardoise électronique (Tablet PCTM), 195. La documentation de maintenance est hébergée soit directement dans l'ordinateur portable 190 ou l'ardoise électronique 195, si sa taille mémoire est suffisamment faible, soit dans un serveur embarqué 170, dans le cas contraire. L'ordinateur portable ou l'ardoise électronique pourra être relié par une liaison sans fil au réseau filaire via un point d'accès AP. Si le point d'accès est connecté à la partie avionique du réseau, cette connexion est réalisée au moyen d'une liaison unidirectionnelle 181, comme indiqué sur la figure. Des commutateurs de trames notés SW permettent le routage sur les différentes liaisons du réseau. Selon un second mode de réalisation représenté en Fig. 2, une interface entrée/sortie commune 155 (clavier, écran et le cas échéant souris) est partagée entre l'ordinateur 110 hébergeant le module de diagnostic et l'ordinateur 191 hébergeant la documentation de maintenance. Les entrées/sorties de ces ordinateurs sont reliées à travers le commutateur KVM (Keyboard Video Mouse) 185, à cette interface d'entrée/sortie commune, ledit commutateur permettant de la commuter, de manière manuelle ou automatique, entre les deux ordinateurs. On notera que seul le signal vidéo de l'ordinateur 191 remonte de la zone ouverte à la zone avionique de sorte que la sécurité de cette dernière n'en est pas affectée. L'opérateur de maintenance peut ainsi basculer aisément de l'écran de diagnostic à l'écran de documentation, comme on le verra plus loin. En cas de survenance de panne, le système CMS en est averti soit directement par un message transmis par le système de gestion des alarmes en vol, ou FWS (Flight Warning System), soit par une remarque du pilote consignée comme entrée dans le journal de bord 120, soit encore par les deux conjointement. Le système CMS peut effectuer une corrélation entre différentes pannes de manière à rechercher la/les cause(s) probable(s) commune(s). Dans tous les cas, le système CMS fournit un code d'identification d'une panne probable, associé à un ou plusieurs équipement(s) remplaçable (s) ou LRUs (Line Replaceable Units). Le module de diagnostic, 115, reçoit un code d'identification de panne et récupère l'arbre de diagnostic correspondant à ce code. Le module 115 est adapté à parcourir cet arbre de diagnostic selon les indications fournies par l'opérateur de maintenance et/ou les modules de test intégrés dans l'équipement à contrôler. L'arbre de diagnostic comprend généralement une première partie relative à la confirmation de la panne et une seconde partie, relative à la résolution proprement dite, au cas où la panne est effectivement confirmée. Chaque noeud de l'arbre de diagnostic comprend une tâche ou une suite de tâches à effectuer dont le résultat détermine le choix du noeud suivant. A chaque noeud de l'arbre de diagnostic correspond une page de la documentation de maintenance destinée à être visualisée sur le terminal d'information 190 ou 195. Le parcours de l'arbre de diagnostic induit simultanément et automatiquement une navigation à travers les pages de la documentation associées aux noeuds traversés. Plus précisément, à chaque fois qu'un noeud est visité par le module de diagnostic un hyperlien est transmis par le terminal OMT au dit terminal. Ce dernier comprend un module de navigation qui se synchronise automatiquement en recherchant l'URL pointée par l'hyperlien. La page correspondante peut être récupérée localement dans le terminal d'information si la documentation y est stockée ou encore si ladite page est disponible dans la mémoire cache, ou bien dans le serveur embarqué 170. Alternativement, la page de documentation peut être récupérée à partir d'un serveur au sol. L'opérateur de maintenance est ainsi guidé systématiquement dans la procédure de diagnostic tout en pouvant consulter la documentation de maintenance afférente à chacune des étapes de la procédure. Le stockage de la documentation de maintenance dans la zone ouverte facilite les opérations de mise à jour. Cette dernière peut être effectuée par exemple au moyen d'un procédé de téléchargement de données conforme au protocole ARINC 615 ou par simple remplacement d'un support mémoire. La mise à jour laisse généralement l'arbre de diagnostic inchangé, ce qui garantit l'intégrité du système de maintenance. L'arbre de diagnostic peut être extrait à partir de la documentation de maintenance existante, c'est-à-dire des manuels AMM et TSM précités. Plus précisément, l'arbre de diagnostic correspond à l'arborescence du manuel TSM. Lorsqu'une étape de la procédure de réparation d'une panne, correspondant à un noeud de l'arborescence du manuel TSM, nécessite l'exécution de certaines tâches de maintenance du manuel AMM. Dans ce cas l'arbre constitutif de ces tâches est greffé localement au noeud précité. L'ensemble des noeuds de l'arborescence du manuel TSM auxquels sont ainsi greffés les arbres des tâches de maintenance afférentes à ces noeuds, forme l'arbre de diagnostic. Si les manuels AMM et TSM se présentent sous forme de documents au format XML ou SGML, l'arbre de diagnostic sera obtenu en supprimant les éléments de représentation visuelle, par exemple les éléments de mise en page, les images, les schémas en trois dimensions, les scripts d'animation. Ces éléments sont rejetés dans la partie documentation. En revanche, tous les éléments fonctionnels seront conservés dans l'arbre de diagnostic, notamment les hyperliens permettant de lancer des applications de test, de télécharger un logiciel pour un équipement, d'activer ou de désactiver un disjoncteur, etc. On obtient ainsi d'une part un arbre de diagnostic et d'autre part un fichier purement documentaire, les deux étant, par exemple, au format XML ou SGML mais possédant des DTDs distinctes. En outre, à chaque noeud de l'arbre de diagnostic est associé un hyperlien vers une page du fichier documentaire. L'arbre de diagnostic et le fichier documentaire peuvent également être élaborés en parallèle, à condition toutefois de respecter leurs DTDs respectives et la cohérence des hyperliens entre les deux documents. La Fig. 3 illustre un exemple de fonctionnement du système informatique de maintenance selon l'invention. Un code d'identification de panne est transmis au module de diagnostic, à partir par exemple d'une consigne du journal de bord. Le module de diagnostic recherche l'arbre de diagnostic (indiqué ici par Task N ) correspondant à ce code. Cet arbre est divisé en deux parties notées (I) et (II) correspondant respectivement à la procédure de confirmation de panne et la procédure de résolution de panne. Lors du parcours de l'arbre de diagnostic, la présentation de la documentation de maintenance est synchronisée au passage par chaque noeud de l'arbre. Par exemple, lorsque le module de diagnostic passe par le noeud 5, la page de documentation relative à la sous-tâche 5 est affichée sur le terminal d'information. Il convient de noter cependant que le passage d'un noeud au suivant ne requiert pas nécessairement un changement de la page à afficher. En outre, l'opérateur de maintenance peut naviguer à sa guise au sein de la documentation grâce à des hyperliens. Par exemple, l'opérateur peut cliquer sur l'hyperlien subtask 5- 2 pour voir la page relative à cette sous-tâche. Toutefois, dès lors que le module de diagnostic passera au noeud suivant (en l'occurrence le noeud 8), la page de documentation relative à ce dernier noeud ( subtask 8 ) s'affichera automatiquement à l'écran du terminal d'information. Au terme du parcours de l'arbre de diagnostic, soit la panne est résolue, soit la panne subsiste et la mention correspondante est consignée dans le journal de bord. Si la panne subsiste, les équipements défectueux sont listés et comparés avec le contenu de la liste minimale d'équipements ou MEL (Minimum Equipment List). Cette liste, contrairement à ce que son nom l'indique, donne la liste d'équipements dont le bon fonctionnement est facultatif pour l'opération de l'appareil. Ainsi, si un équipement diagnostiqué comme défectueux ne se trouve pas dans la liste, le vol doit être annulé. En revanche, si un équipement diagnostiqué comme défectueux est dans la liste MEL, le système détermine les contraintes imposées par le dysfonctionnement de l'équipement et le coût qui y est associé en termes de pertes de performances fonctionnelles ou de marges de sécurité. Par exemple, le dysfonctionnement d'un équipement pourra imposer une contrainte sur la quantité de carburant que l'aéronef pourra embarquer, ce qui se traduira à son tour par une limite de son rayon d'action. Les coûts précités sont stockés dans un fichier hébergé dans la zone avionique. Selon une variante de réalisation non représentée, le système informatique selon l'invention comprend un troisième module logiciel, hébergé dans la zone avionique, par exemple dans le terminal de diagnostic, permettant au pilote ou à l'opérateur de maintenance de parcourir la liste MEL et de sélectionner un équipement quelconque de cette liste. Le système informatique comprend également un quatrième module logiciel, hébergé dans la zone ouverte, par exemple dans le terminal d'information, chargé de l'affichage de la documentation relative aux éléments de la liste MEL. Cette documentation est hébergée dans la zone ouverte, par exemple par le terminal d'information ou le serveur embarqué 170. Alternativement, cette documentation pourra être hébergée par un serveur au sol. La liste MEL est, quant à elle, hébergée dans la zone avionique, par exemple dans le terminal de diagnostic. Lorsqu'un élément de la liste MEL est sélectionné grâce au troisième module logiciel, il transmet via le réseau au quatrième module un hyperlien pointant vers une URL donnant la page de documentation relative à cet élément. Le quatrième module logiciel récupère alors cette page et l'affiche sur l'écran du terminal d'information. De cette manière le parcours des éléments de la liste MEL induit de manière automatique et synchrone une présentation des pages de documentation correspondantes par le terminal d'information. La Fig. 4 donne un exemple d'arbre de diagnostic utilisé par le module de diagnostic 115, correspondant à un code de panne déterminé, noté ici TSM 31-50-810-982-A, correspondant à une panne du software d'un système d'alarme en vol FWS 2 (Flight Warning System). La partie de l'arbre relative à la procédure de confirmation et celle relative à la procédure d'isolation sont séparées par un trait discontinu horizontal. Les Figures 5A à 5G montrent le contenu des écrans du terminal OMT et du terminal d'information pour un exemple de parcours de l'arbre de diagnostic représenté en Fig. 4. La racine 410 de l'arbre de diagnostic 400 est associée à une page de documentation représentée dans la partie gauche de la Fig. 5A. Cette page indique les principales étapes de la procédure de confirmation et d'isolation de la panne. En 410, le module de diagnostic teste la panne indiquée dans le journal de bord. Dans le cas présent, le statut de la panne est confirmé (noeud 421) et par conséquent le module de diagnostic passe au noeud 441. Le noeud 441 est associé à l'exécution d'un programme de test intégré (BITE) d'une unité (LRU) du système FWS dénommée CPIOM-C2 (Core Processing Input/Output Module). Comme illustré en Fig. 5B, l'écran du terminal OMT indique le degré d'accomplissement du programme de test, et l'écran d'information les détails de la procédure correspondante. Dans le cas présent, au terme du test, le programme renvoie un code d'erreur comme indiqué sur l'écran du terminal OMT en Fig. 5C. La panne de l'unité CPIOM-C2 est par conséquent isolée (noeud 441 de l'arbre de diagnostic). La page de documentation reste inchangée à ce stade. Le noeud 451 correspond à une procédure de remplacement de l'unité CPIOM-C2, comme illustré en Fig. 5D et l'écran du terminal d'information en indique le détail. Dans une première étape, le disjoncteur du circuit d'alimentation de l'unité CPIOM-C2 est activé, autrement dit son alimentation est coupée, puis dans une seconde étape (cf. Fig. 5E), une nouvelle unité est installée. Un fois la nouvelle unité installée et l'alimentation rétablie, le module de diagnostic teste à nouveau le système FWS, c'est-à-dire retourne à la racine 410 de l'arbre de diagnostic. Le test du système se révèle cette fois-ci satisfaisant (absence de code d'erreur), comme indiqué en Fig. 4G. La page de documentation est bien entendu la même que celle affichée lors du premier passage dans l'arbre de diagnostic. L'opérateur de maintenance conclut par conséquent que la panne a été réparée et porte la mention correspondante dans le journal de bord. REVENDICATIONS 1. Système informatique de maintenance d'un aéronef équipé d'un réseau partitionné en une zone sécurisée, dite avionique (101), et une zone ouverte (102), caractérisé en ce qu'il comprend un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier module étant adapté à parcourir un arbre de diagnostic, le second module étant adapté à présenter une documentation électronique de maintenance, le parcours de l'arbre de diagnostic par le premier module induisant de manière automatique et synchrone une présentation par le second module de pages de ladite documentation de maintenance respectivement associées à ces nœuds. 2. Système informatique selon la revendication 1, caractérisé en ce qu'à chaque noeud dudit arbre de diagnostic correspond au moins une tâche de maintenance et que le premier module transmet au second module un hyperlien pointant vers une page de la documentation de maintenance associée à cette tâche lorsque le premier module atteint ledit noeud. 3. Système informatique selon la revendication 2, caractérisé en ce que pour chaque noeud de l'arbre de diagnostic, le premier module détermine le noeud suivant en fonction du résultat de l'exécution de ladite tâche de maintenance correspondant à ce noeud. 4. Système informatique selon l'une des revendications précédentes, caractérisé en ce que l'arbre de diagnostic est déterminé à partir d'un code identificateur de panne, ledit code étant lui-même obtenu à partir d'une analyse d'une entrée d'un journal de bord électronique (120) hébergé dans la zone avionique. 5. Système informatique selon l'une des revendications précédentes, caractérisé en ce que, si le premier module détermine qu'un équipement de l'aéronef est défaillant au terme du parcours de l'arbre de diagnostic, ledit système est adapté à vérifier la présence de cet équipement dans une liste minimale d'équipements de l'aéronef, dite liste MEL, hébergée dans la zone avionique. 6. Système informatique selon la revendication 5, caractérisé en ce que, si ledit équipement défaillant est présent dans la liste MEL, le système est adapté à calculer le coût correspondant en termes de pertes de performances fonctionnelles ou de marges de sécurité de l'aéronef. 7. Système informatique selon les revendications 5 ou 6, caractérisé en ce qu'il comprend un troisième module logiciel, hébergé dans la zone avionique, et un quatrième module logiciel, hébergé dans la zone ouverte, le troisième module étant adapté à parcourir et sélectionner les éléments de la liste MEL, le quatrième module logiciel à présenter des pagesde documentation correspondant aux dits équipements, la sélection d'un élément par ledit troisième module logiciel induisant de manière automatique et synchrone une présentation par le quatrième module d'une page de documentation relative à cet élément. 8. Système informatique selon la revendication 7, caractérisé en ce que, pour chaque élément de la liste MEL, le troisième module transmet au quatrième module, un hyperlien pointant vers une URL contenant ladite page de documentation relative à cet élément. 9. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le premier module et, le cas échéant le troisième module, est(sont) hébergé(s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, est(sont) hébergé(s) dans un second ordinateur de la zone ouverte, le second ordinateur étant relié à la partie du réseau de la zone avionique par une liaison unidirectionnelle (181) vers la zone ouverte et un point d'accès sans fil (180). 10. Système informatique selon l'une des revendications 1 à 8, caractérisé en ce que le premier module et, le cas échéant le troisième module, est(sont) hébergé(s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, est(sont) hébergé(s) dans un second ordinateur de la zone ouverte, les entrées/sorties des premier et second ordinateurs étant reliées à un commutateur KVM, ledit commutateur étant adapté à commuter lesdits entrées/sorties vers une interface d'entrée/sortie commune (155).