La standardisation est une bonne chose
Les anglais ont, enfin, décidé de rouler à droite. Afin de s’y habituer progressivement, ce mois-ci les voitures commenceront et, si l’expérience est concluante, le mois prochain, les camions aussi !
Cette plaisanterie démontre tout l’intérêt de règles communes ou standards. Mais jusqu’où les règles communes ne provoquent-elle pas plus de problèmes qu’elles n’en résolvent ? Quelle est la responsabilité de Microsoft et de chacun d’entre-nous ?
Standard
Dans le domaine de l’informatique comme dans le code de la route, les règles communes sont nécessaires. Le succès de Microsoft est, en partie, fondé sur une certaine standardisation, voire, comme je l’ai entendu dire, d’une socialisation : au niveau d’un ordinateur, chaque programme doit pouvoir communiquer ou, à défaut, fonctionner de manière harmonieuse avec tous les autres. Au niveau mondial, il est important que chacun puisse communiquer avec tous les autres.
Je ne reviendrais pas sur l’opposition entre les normes et standards de fait. Un autre Stéphane (SABBAGUE) ayant déjà évoqué cet aspect dans un éditorial de Technet.
Force est de constater que tous les éditeurs ne font pas les mêmes efforts pour intégrer parfaitement leurs logiciels sur les systèmes sur lesquels ils fonctionnent.
Certains prétendent que Microsoft profite de cette situation. Certes, Microsoft dispose d’une longueur théorique d’avance pour mieux développer ses propres logiciels par rapport aux autres éditeurs. Toutefois, d’une part, la plupart des informations sur le système d’exploitation dont disposent les développeurs d’un Office ou SQL Server sont également disponibles pour les éditeurs tiers. Tout au plus, les équipes internes de développement pourraient bénéficier en avant première des spécifications qui seront divulguées ultérieurement aux autres développeurs, mais ce n’est pas le cas. Les récents événements judiciaires ont renforcé la protection des éditeurs tiers en ce domaine. D’autre part, le cloisonnement des équipes de développement à Redmond est tel qu’il est tout aussi facile à un développeur tiers d’utiliser ces ressources publiées qu’à un développeur interne à Microsoft.
Les équipes de développement d’IBM, lorsqu’elles portent Universal DB2 sur Windows 2000, sont parvenues, à une certaine époque, à des performances comparables, voire supérieures, à celles de SQL Server (cf. www.tpc.org). Si IBM y parvient, pourquoi les autres éditeurs n’y parviendraient pas également ?
Dans certains cas, le portage d’une application développée initialement pour un autre système d’exploitation justifie le manque d’intégration et des performances, voire de qualité de fonctionnement, différentes. Qu’un éditeur se contente d’un service minimum de portage de son application en environnement Microsoft et il ne pourra pas se plaindre de ne pas obtenir les mêmes résultats que ses concurrents qui développent initialement sur cet environnement.
La diffusion en novembre 2003 d’une première version de Longhorn à une conférence pour développeurs vise à donner à tous les moyens de s’y préparer. De même, les informations sur le service pack 2 de Windows XP permettaient à chacun de mesure les différences qui interviennent (et c’eut été une erreur de ne pas l’avoir prévu).
L’alternative proposée par certains consiste à se tourner vers des systèmes dits « ouverts » ou à code libre de manière, paraît-il, à fournir à tous, les mêmes armes de départ. Je ne suis pas sûr qu’il en soit ainsi et même, plutôt persuadé du contraire.
Le tapage actuel autour de Linux et des logiciels du monde soi-disant « libre » laisse craindre un retour aux heures sombres de l’informatique individuelle.
Avant l’apparition de Windows, j’ai été, comme bon nombre d’entre vous, utilisateur de logiciels sous MS/DOS. Pour chacun de ces logiciels, il était nécessaire de rechercher les pilotes d’écran et d’imprimante, voire de clavier. Les développeurs de ces logiciels devaient prendre en charge une multitude de fabricants. Le succès de certains programmes n’était probablement pas dû à la qualité de ces programmes, mais à la capacité de leurs éditeurs à supporter un grand nombre de cartes vidéo et d’imprimantes. Fort heureusement, ce nombre était encore suffisamment réduit par rapport à la situation actuelle.
À cette époque, inclure un tableau, un graphique ou un simple schéma dans un texte relevait du parcours du combattant. Chaque éditeur possédait son propre format d’échange et tentait de l’imposer aux autres (prédisons que ce ne sera ni SYLK, ni DIF, mais XML pour le bien de tous). Un moment, les logiciels dits « intégrés » ont pu représenter une issue de secours. La vision que Microsoft avait à cette époque et qu’elle possède encore aujourd’hui, en a décidé autrement.
En fournissant nativement des pilotes pour les écrans et imprimantes, mais également une interface d’échange entre les programmes, Microsoft a simplifié la vie des développeurs, des responsables informatiques et des utilisateurs. Peu à peu, cette standardisation a gagné d’autres domaines comme l’accès aux bases de données ou la navigation sur Internet. Faut-il s’en plaindre ?
Les limites de la standardisation
Les récentes attaques de virus n’auraient, sans doute, pas pu arriver si Microsoft ne représentait une cible de choix. Tant qu’à développer un virus, autant qu’il touche le maximum de cibles possibles ! Au-delà des polémiques sur le succès des logiciels du monde dit « libre », force est de constater qu’ils ne représentent qu’une infime partie des systèmes en activité.
Que le nombre de systèmes sous Linux augmente et le nombre de virus ciblant cet environnement augmentera naturellement. Les différents éditeurs seront-ils capables de répondre à ces attaques ? À constater la différence d’empressement à corriger certaines failles, permettez-moi d’en douter !
Il est de la responsabilité de Microsoft de faire face à cette situation pour ses systèmes d’exploitation et logiciels. La prise en compte du danger ne date pas d’hier ni du fameux mémo de Bill GATES sur la sécurité. L’équipe en charge de la publication des correctifs de sécurité n’a pas attendu Blaster pour se mettre au travail.
Chaque crise apporte une remise en cause qui est bénéfique pour chacun, à condition de parvenir à la surpasser. Des progrès restent à faire mais il en est sur lesquels Microsoft ne peut pas grand-chose, du moins, à court et moyen terme.
L’interdiction du lancement de pièces jointes jugées dangereuses dans Outlook et Outlook Express vise à réduire le principal obstacle : le facteur humain. Microsoft n’est pas et ne peut pas (ne souhaite pas, non plus, contrairement à ce que l’on entend parfois) être derrière chaque utilisateur à espionner son activité. Il appartient à chacun de prendre sa responsabilité en utilisant son ordinateur avec un peu de bon sens et jugeote.
Quelle responsabilité ?
Prenez un groupe d’utilisateurs plus ou moins au fait des virus et complications de l’informatique (expérience vécue, je ne vous écrirai pas où, mais vous pouvez deviner). Adressez à ce groupe un message dont la pièce jointe est un fichier compressé au nom évocateur d’une séance de voyeurisme en toute discrétion. Près de 50% des destinataires, jetteront directement ce message. Sur les 50% restants, un certain nombre enregistrera la pièce jointe sur son disque dur. Le chiffre exact n’est pas connu pour une question uniquement de manque de transparence (j’ai peine à croire le nombre de personnes qui avouent ne pas avoir ouvert « calendrier_adriana_carambeu.zip »). Ces utilisateurs (plutôt avertis, je le rappelle pour ceux qui ne suivraient pas) découvriront un exécutable du même acabit. À la vue d’un exécutable, bon nombre d’utilisateurs ignoreront le message. Quelques uns enverront un message d’avertissement à l’expéditeur pour lui faire mesurer le danger de son envoi. Il restera toujours un faible pourcentage d’utilisateurs qui iront jusqu’à lancer l’exécutable dont, je le rappelle, ils ne connaissent pas la véritable provenance. Et si c’était un virus, cheval de Troie, vers et autre logiciel espion ?
À l’échelle de la communauté des utilisateurs d’ordinateurs, ce pourcentage, fût-il très faible, représente un très gros danger.
Il ne sert à rien de mettre en œuvre des antivirus, firewall, logiciels de détection d’intrusion et autres barrières tant qu’il restera un petit nombre d’utilisateurs capable de lancer n’importe quel exécutable venu sans en assumer les conséquences !
En attendant une réponse de la part de Microsoft pour limiter les effets dévastateurs de tels lancements, il faut vivre avec les virus et autres failles de sécurité en tentant d’en limiter les effets.
Contres mesures
La plupart des administrateurs mettent aujourd’hui en œuvre des mesures de protection qui, si elles ne sont pas suffisantes, sont au moins nécessaires. Il est néanmoins indispensable d’aller plus loin.
L’éducation des utilisateurs doit être permanente. Mais elle n’empêchera jamais une erreur d’étourderie ou un acte de malveillance.
Les administrateurs ne doivent pas seulement réfléchir en terme de défense de type ligne Maginot. Que se passe-t-il si le premier rempart de défense tombe ? Tel un jeu de domino, il faut, dès la conception de son infrastructure, penser aux mesures suivantes, mais surtout, faire évoluer l’infrastructure au rythme des demandes.
De nombreux utilisateurs n’ayant pas accès à telle ou telle fonction ou service n’hésitent pas à contourner les garde-fous. Que la politique de la société leur interdit l’accès à Internet et qu’ils s’empresseront d’installer des modems sur leurs postes (de moins en moins fréquent, certes, avec la généralisation des accès à Internet, mais cela existe encore). Qu’ils n’aient pas les droits nécessaires pour le faire sur le poste de travail fourni et géré par leur service informatique et ils achèteront sur leur budget de fonctionnement des postes indépendants.
Par ces pratiques dangereuses, ils mettent en danger l’ensemble du système d’information. Peuvent-ils assumer ces risques ? Dans une grande majorité des cas, ils ne le peuvent pas ! Quelles sont, d’ailleurs, les sociétés qui connaissent précisément les conséquences d’une défaillance (arrêt de la production informatique, diffusion d’informations confidentielles, etc.) ? Nick LEESON endossait-il la responsabilité de la faillite de la banque BARINGS ?
Imaginons la société qui refuse d’équiper ces collaborateurs de cartes WiFi. Il sera très facile de monter (sous la ligne radar ; c'est-à-dire sans que le service informatique soit au courant) des bornes pirates qui ne bénéficieront pas de toute la sécurité nécessaire.
Microsoft en fournissant tout ce qui est nécessaire pour faire fonctionner une carte WiFi dans un ordinateur sous Windows XP porte, certes, une responsabilité. Mais, en parallèle, Microsoft fournit également les moyens et méthodes de sécuriser les points d’accès au réseau de l’entreprise par des bornes sans-fil.
L’informatique est passée en quelques années du statut de simple outil à une notion de service. Entre temps, Microsoft est passé de la perspective d’installer un ordinateur sur chaque bureau et dans chaque maison à l’objectif de permettre l’épanouissement de notre potentiel.