La création de Windows 7

L’espace disque

Cet article parle de l’espace disque utilisé par Windows 7. Bien qu’à priori il semble naturel de vouloir utiliser le moins d’espace disque possible, il est de fait que les avantages associés à une plus grande utilisation l’emportent généralement sur les désavantages. Les choses ont changé récemment avec l’avènement des disques électroniques ( « solid-state »), ayant des capacités largement inférieures à celles des disques classiques. En règle générale, et en cas de besoin spécifique (et justifié), la plupart des logiciels, y-compris Windows, n’auraient aucune hésitation à s’approprier 100MB d’un disque de 60GB (ou 1500GB); cependant, au vu des machines performantes maintenant commercialisées ayant des capacités de 16GB en « solid-state », nous nous devons de soigneusement réexaminer l’espace disque utilisé par Windows, à la fois pendant l’installation, et aussi au cours du « vieillissement » du PC. Nous avons tenu à WinHEC une session dédiée aux disques électroniques qui pourra intéresser certains d’entre vous. L’article ci-dessous a été écrit par Michael Beck, un chef de programme dans l’équipe de déploiement du système d’exploitation. –Steven.

Nous allons parler « d’empreinte sur disque ». Dans le contexte de cet article, le terme « empreinte » représente le montant total d’espace disque utilisé par Windows. Ceci comprend non seulement les fichiers de Windows, mais aussi tout l’espace disque utilisé ou réservé pour les opérations relatives au système d’exploitation. J’entrerai plus en détail au cours de cet article sur la façon dont les différentes technologies de Windows utilisent l’empreinte sur disque.

Nous avons reçu pas mal de commentaires et de questions relatifs à l’empreinte sur disque, et sur les attentes que vous pouvez avoir au sujet de l’utilisation du disque dans Windows 7. Comme beaucoup de notions de conception dont nous avons déjà parlé, l’espace disque est aussi un sujet sur lequel nous devons faire des compromis. Cet article détaille certains de ces compromis, et répond aussi à certains des commentaires que nous avons reçus. Il est important de noter cependant que nous n’en sommes pas encore au point d’avoir finalisé les exigences de matériel pour Windows 7, et cet article ne présente donc qu’un contexte où nous nous concentrons sur l’ingénierie.

Nous allons organiser cet article autour de deux thèmes importants émergeant des commentaires et des questions que nous avons reçus :

• Que contient le dossier WinSxS, pourquoi est-il si gros, et puis-je m’en débarrasser ?
• Où va tout l’espace disque utilisé par les composants de Windows ?

Nous parlerons ensuite de l’ingénierie de Windows 7.

Le dossier WinSxS

Depuis Vista, nous recevons énormément de questions sur le nouveau dossier WinSxS (%SystemRoot%\winsxs), et beaucoup d’entre vous sont convaincus que c’est un gros consommateur d’espace disque – une simple consultation de ses propriétés révèle qu’il contient plus de 3000 fichiers, et prend 3.5GB sur le disque d’un système récemment installé. Après utilisation, la taille de ce dossier augmente encore plus. Aïe ! Voici un exemple pris d’une des machines de Steven.

La « modularisation » du système d’exploitation était un principe de base dans Vista, et devait résoudre un grand nombre de problèmes inhérents à l’installation, au support et à la fiabilité de Windows. En fait, le dossier WinSxS représente « l’état d’installation et de support » de tous les composants du système. Mais en réalité il n’utilise pas autant d’espace disque que vous l’indiquent les outils d’utilisation de disque intégrés dans Windows (DIR ou Explorer). Eh oui, le fait que nous rendions difficile de savoir quel espace disque est réellement utilisé dans un fichier est une remarque tout à fait justifiée !

En fait, pratiquement chaque fichier dans le dossier WinSxS est un lien « physique » vers les fichiers réels dispersés dans le système - ce qui signifie que les fichiers ne sont pas réellement dans le dossier. Par exemple, vous trouverez dans le dossier WinSxS un fichier appelé advapi32.dll occupant plus de 700KB, mais le réel fichier advapi32.dll est dans le dossier Windows\System32, et sera compté deux fois (ou plus) si vous regardez dans les dossiers individuels avec Windows Explorer.

Le bénéfice de ce principe est que la plateforme de support de Windows (les outils permettant de déployer les mises à jour logicielles et de sécurité) peut ainsi consulter le dossier WinSxS et aisément collecter un grand nombre de détails cruciaux concernant l’état général du système, comme par exemple ce qui est installé, ce qui est disponible à l’installation (comme les composants facultatifs, sur lesquels je reviendrai plus tard), quelles en sont les versions, ou quelles mises à jours sont sur le système, afin d’aider à déterminer quelles autres mises à jour de sécurité sont disponibles. Cette fonctionnalité nous apporte plus de performance et de fiabilité dans le support, et permettra aussi de développer dans le futur une meilleure structuration en couches du système, et de plus grandes capacités de configuration.

Le dossier WinSxS permet aussi le support hors ligne, et permet d’obtenir un « cliché » de Windows Vista. Avant Vista, le support de déploiement s’effectuait grâce au logiciel d’installation uniquement. Les professionnels IT installaient le système sur une machine, puis utilisaient des outils indépendants pour clicher une image du système installé, qu’ils répliquaient ensuite sur l’ensemble de leurs machines. Windows n’avait en lui-même pas de notion d’ « image ». Ceci signifie que plus de 80% des systèmes étaient déployés et mis à jour grâce à une technologie qui n’était pas supportée nativement, et qui demandait aux services IT de créer leurs propres solutions personnalisées afin de déployer et gérer Windows efficacement. De plus, l’état de système emmagasiné dans le dossier WinSxS peut aussi être consulté « hors ligne », ce qui signifie que l’image n’a pas besoin d’être démarrée ou de tourner pour recevoir des mises à jour. Ces deux fonctionnalités de WinSxS apportent une grande flexibilité et des réductions de cout aux services IT qui déploient Windows Vista, en facilitant la création d’images corporatives et leurs mises à jour hors ligne.

Bien qu’il soit vrai que l’existence même de WinSxS utilise de l’espace disque (il contient un bon nombre de fichiers de métadonnées, de dossiers, de manifestes, et de catalogues), le dossier est beaucoup plus petit qu’indiqué. L’espace de stockage réellement utilisé varie, mais sur un système ordinaire il est à peu près de 400MB. Bien que non négligeable, nous pensons que les bénéfices apportés aux mises à jour en justifient le cout.

Pourquoi le bureau reporte-t-il les liens physiques de cette façon ? Les liens physiques ont pour but d’optimiser l’empreinte sur disque des fichiers dupliqués dans tout le système. Les développeurs de logiciels peuvent aussi utiliser cette fonctionnalité de façon à minimiser la consommation d’espace disque de leurs applications. Il est donc capital que tout chemin d’accès utilisé par un logiciel aboutisse sur un fichier physique du système, de façon à permettre son chargement. Dans ce cas précis, le bureau n’est donc rien d’autre qu’un logiciel fournissant des informations sur les fichiers qu’il trouve. Malheureusement cette confusion, accompagnée du désir d’économiser de l’espace disque, a poussé certains à effacer ce dossier de leurs systèmes.

Nous avons vu plusieurs blogs sur internet, et même quelques outils « occultes », vous informant que la suppression du dossier WinSxS était possible. De fait, après installation, il est possible de l’éliminer du système, et votre machine paraitra démarrer et fonctionner correctement. Mais comme nous venons de l’expliquer, c’est une très mauvaise pratique, qui élimine la faculté de mettre à jour les composants système de façon fiable, ainsi que la faculté de mettre à jour ou de configurer les composants facultatifs de votre système. Windows Vista ne supporte le dossier WinSxS que sur un disque physique, et dans son emplacement d’origine. Au vu des données ci-dessus, il est clair que les risques encourus par sa suppression ou son déplacement en dépassent largement les bénéfices potentiels.

Où va l’espace disque ?

Tout le monde sait que l’ajout de nouvelles fonctionnalités nécessite plus d’espace disque – que ce soit dans Windows ou dans tout autre logiciel. Mais en fait, le « code » de Windows n’occupe qu’une portion relativement faible de son empreinte sur disque. La quantité de code nécessaire à l’installation de Windows Vista Edition Intégrale est d’un peu plus de 2GB, le reste de l’empreinte sur disque étant consacrée aux « données », terme défini ici de façon tres générale. Penchons-nous d’un peu plus près sur l’utilisation du disque dans Windows Vista, et sur ce que nous appelons les « données ».

La fiabilité et la sécurité étaient des préoccupations de base durant le développement de Windows Vista. Une grande partie de l’augmentation de l’empreinte sur disque provient de nouvelles fonctionnalités de fiabilité dont les utilisateurs dépendent pour la protection du système, sa performance, la protection des données, et le dépannage. Certaines de ces fonctionnalités comprennent la sauvegarde du système, l’hibernation, le fichier de pagination, la sauvegarde du registre, et l’enregistrement. Chacune de ces fonctionnalités représente un « état de sauvegarde » permettant la récupération du système après un nombre donné de situations, certaines prévues, et d’autres non. Dans Windows 7, nous savons que certains utilisateurs voudront faire d’autres compromis entre l’espace disque et la récupération (surtout sur des machines ayant peu d’espace). Ainsi avons-nous décidé de leur donner plus de contrôle préalable sur l’espace disque utilisé par ces mécanismes, et d’ajuster nos préréglages de façon plus sensible à l’utilisation du disque, au vu des changements en cours dans le stockage.

La sauvegarde du système et l’hibernation sont des fonctionnalités qui aident les utilisateurs à récupérer leur système avec confiance et évitent la perte de données dans bon nombre de situations telles que le déchargement de la pile (pour l’hibernation), ou une mauvaise installation de logiciel ou toute autre corruption du système (pour la sauvegarde). En association, ces fonctionnalités occupent une part importante de l’empreinte sur disque. Vu la place qu’elles occupent sur le disque, il est facile de les isoler et de prendre des décisions à leur sujet.

La sauvegarde du système protège l’utilisateur en clichant le système avant que des changements ne se produisent, et à intervalles réguliers. Dans Windows Vista, cette sauvegarde est programmée de façon à utiliser au moins 300MB, et jusqu'à 15% du disque physique. A mesure que cet espace se remplit par des sauvegardes successives, les clichés les plus anciens sont effacés pour faire place aux nouveaux. Plus vous avez d’espace, et plus de clichés sont donc disponibles pour d’éventuels « retours en arrière » du système. Dans Vista, nous avons reçu pas mal de commentaires d’utilisateurs indiquant que la Sauvegarde du Système prenait trop de place, et était difficile à gérer. Certains d’entre vous auront déjà remarqué dans la version pré-Béta de Windows 7 une interface permettant de mieux gérer cette fonctionnalité.

L’hibernation est principalement utilisée sur les PC mobiles. Elle sauvegarde votre travail sur le disque, puis met l’ordinateur dans un état ralenti consommant extrêmement peu d’électricité. Elle se met en route quand la charge de la pile descend en-dessous d’un certain seuil, ou quand l’ordinateur est éteint ou fermé sans passer par le menu « Arrêter », et permet d’étendre la durée de vie de la pile. Dans Windows Vista, l’hibernation est aussi utilisée automatiquement par la l’option de mise en veille sur les ordinateurs de bureau pour préserver une copie de sauvegarde des programmes en cours et de leurs données. Cette fonctionnalité s’appelle la mise en veille hybride, et est utilisée pour sauvegarder l’état de la machine sur le disque dur, de façon à pallier une panne de courant éventuelle pendant la veille de l’ordinateur. L’hibernation enregistre l’ensemble du contenu de la mémoire RAM sur le disque, dans un fichier appelé Hiberfil.sys. La taille de ce fichier est ainsi égale au montant de mémoire RAM du système. Pendant que nous développions Vista, le montant de RAM intégré dans les ordinateurs a augmenté de façon importante, rendant de fait l’empreinte sur disque de l’hibernation plus évidente qu’elle ne l’était auparavant. Cet espace doit aussi être réservé par avance, pour garantir qu’en cas de décharge critique de la pile, le système puisse facilement enregistrer le contenu de la mémoire sur le disque. Tout utilisateur de PC mobile dont l’ordinateur entre en hibernation à cause d’une pile déchargée peut apprécier la tranquillité d’esprit apportée par cette augmentation de l’empreinte sur disque. Puisque nous parlons d’espace disque et de mémoire RAM dans le même paragraphe, j’en profite pour signaler à ceux qui seraient intéressés que Mark Russinovich a écrit récemment un article traitant de la mémoire virtuelle, et de la taille qu’elle peut, pourrait ou devrait atteindre.

Il est bien sûr évident que dans les descriptions ci-dessus, nous n’incluons pas l’ensemble de l’espace disque occupé par Windows Vista – par exemple, le disque comprend aussi un grand nombre de fichiers modèles, de vidéos ou d’arrière-plans haute-résolution permettant aux utilisateurs de facilement personnaliser leur expérience ou d’essayer de nouvelles fonctionnalités – mais nous avons couvert deux des questions les plus courantes.

Il est aussi important de ne pas se limiter à la taille du système pendant l’installation, mais d’également prendre en compte la façon dont le système croît au cours du temps, quand les services enregistrent leurs données, les mises à jour sont installées, les clichés de sauvegarde sont pris, etc. Pour beaucoup, la « croissance » du système au fil du temps crée une grande perplexité – nous en sommes conscients, et nous nous devons de (a) prendre des décisions plus logiques et (b) être plus clairs quant à la quantité d’espace disque qui est utilisée et peut être récupérée.

Le tableau ci-dessous donne un aperçu de l’empreinte sur disque d’une installation de Windows Vista Edition Familiale Premium ou Intégrale. Il inclut toute l’installation, mais a été séparé en catégories logiques de façon à être plus digeste, et souligne aussi quelques fonctionnalités spécifiques, de façon à présenter le cout d’éléments ayant suscité des questions.

Je relèverai quelques éléments méritant d’être signalés :

• ~1GB  est consacré au support des polices. Windows Vista fonctionne avec des milliers de périphériques différents. Nos utilisateurs attendent maintenant de Windows qu’il reconnaisse et installe automatiquement tout périphérique qu’ils connectent, même une vieille imprimante. Nous recevons aussi un grand nombre de demandes pour enlever des périphériques, et à chaque version, nous passons la liste de périphériques supportés au peigne fin afin de la faire correspondre à nos données de télémétrie. La possibilité de pouvoir installer une imprimante ou un périphérique USB hors-ligne est très importante, surtout parce que les ordinateurs portables représentent plus de la moitié des ventes de PC. Dans le futur, nous pourrons probablement partir de l’hypothèse que Windows Update sera toujours disponible, mais pour le moment nous n’en sommes pas là dans la majeure partie du monde.
• ~1GB  est consacré à la croissance du système pour les composants remplacés ou mis à jour, de façon à assurer un retour en arrière et une récupération fiables après avoir installé des mises-à-jour de fonctionnalité ou de sécurité importantes. Nous avons reçu beaucoup de louanges sur la fiabilité de notre infrastructure de mise à jour, mais la faculté de pouvoir revenir en arrière après une réparation donnée reste une mesure importante de robustesse et de fiabilité. Nous comprenons aussi les critiques que nous avons reçues au sujet des exigences en disque de l’installation de Vista SP1 sur l’édition de publication (« RTM »). Nous espérons que ceux d’entre vous qui auraient besoin de plus d’espace disque sauront trouver l’outil vsp1cln.exe dans le dossier system32.
• ~1GB  est consacré au support d’hibernation, nécessaire pour éviter la perte de données quand une machine sommeille pendant de nombreuses heures. Cet espace peut être éliminé soit grâce à l’outil Nettoyage de disque, soit dans une fenêtre Commande en mode administrateur (powercfg /h off).
• ~315MB sont consacrés aux polices d’écriture. Windows est utilisé par des utilisateurs parlant des langues diverses, partageant souvent une même machine, et désirant tous pouvoir communiquer avec le système. Vista comprend donc un support extensif de polices natives, permettant à nos utilisateurs ayant un système fonctionnant dans une certaine langue de lire des documents ou des sites internet dans une autre. En cas de besoin, ces polices peuvent être facilement éliminées du système.
• ~52MB vont aux fichiers d’enregistrement. Cet espace est crucial pour les diagnostics d’erreurs, et nous le réservons à l’enregistrement d’événements, de mises à jour, d’installation de périphériques, ou d’autres. Ces enregistrements sont utilisés couramment par nos agents de support ou les agents de support corporatifs pour les diagnostics d’erreurs et les dépannages.

La conception de Windows 7

L’espace disque utilisé par Windows a augmenté au fil du temps. Bien que non désirable, la mesure dans laquelle nous avons accepté cette augmentation est due en majeure partie à l’accroissement incessant de la capacité des disques durs, couplé aux besoins des nos utilisateurs et à notre souci de nous concentrer sur la fiabilité des machines, sur l’extension de notre support de périphériques, et sur la demande de nouvelles fonctionnalités innovatrices. Cependant, la prolifération récente de disques électroniques (« solid-state » ou « SSD ») vient à l’encontre de cette tendance, et nous pousse à être beaucoup plus vigilants quant à l’empreinte sur disque de Windows 7.

Cela ne signifie pas que nous allons arrêter d’ajouter de nouvelles fonctionnalités, ou rendre Windows moins fiable ou moins réparable. Mais à l’avenir, il nous sera critique de savoir innover tout en traitant l’espace disque comme une ressource précieuse, et d’avoir une idée plus claire de la façon dont nous l’utiliserons. Nous voulons nous assurer de faire les meilleurs choix possibles pour la grande majorité de nos utilisateurs, tout en laissant la faculté de modifier ces choix à ceux qui désirent plus de contrôle. Le but de ce concept n’est pas spécifique à une configuration ou à une autre – toutes les versions de Windows pourront bénéficier d’efforts visant à minimiser l’empreinte sur disque.

Par exemple, si nous prenons en considération le problème de support de périphériques mentionné ci-dessus, Windows Vista SP1 installe sur le système presque 1GB de polices de périphériques prêts à tourner (« Plug-and-Play »). Ce cache local se périme quand les fabricants de périphériques publient des mises à jour de leurs polices, poussant ainsi les utilisateurs de ces périphériques à télécharger les dernières versions sur Windows Update.

Pourquoi alors ne pas étendre le principe du prêt à tourner et n’utiliser que le cache de polices de Windows Update, de façon à économiser de l’espace disque ? Ceci a plusieurs avantages :

1. Les PC mobiles étant rarement déconnectés d’Internet, il leur est facile de simplement télécharger la nouvelle police.
2. Pour les périphériques mis à jour, les polices n’auraient pas à être installées deux fois, puisque le système irait sur Internet de toute façon.

Cet exemple démontre ainsi aisément comment la minimisation de l’empreinte sur disque peut aboutir à une meilleure expérience utilisateur dans l’installation de nouveaux périphériques. En même temps, nous nous devons de faire attention à ne pas aller trop loin, ou trop vite. Nous recevons énormément de commentaires sur le « Plug-and-Play », et sur les temps de téléchargement couteux (quand le téléchargement est même possible). Dans Windows 7, nous allons continuer à prendre des décisions délibérées sur ce que nous inclurons dans le système, basées sur un recensement des périphériques existants, et visant à réduire le nombre de polices incluses de façon à couvrir les périphériques les plus répandus dans le monde. En parallèle, nous continuerons à investir d’importants efforts dans Windows Update, de façon à avoir le meilleur site possible pour tous les périphériques que nous pouvons supporter.

Les fonctionnalités installées par défaut dans Windows sont conçues pour couvrir des scénarios multiples. Il nous sera utile d’envisager de rendre certaines fonctionnalités ou certains composants (comme « Media Center ») facultatifs quand ils ne sont pas nécessaires, plutôt que de les installer par défaut sur tous les systèmes. En fait, nous sommes décidés à rendre plus de fonctionnalités de Windows facultatives. Comme vous pouvez le remarquer aujourd’hui dans Windows, quand vous choisissez une fonctionnalité non-installée, Windows ne vous demande pas de « source » (un DVD ou un chemin sur le réseau). Ceci s’explique par le fait que la fonctionnalité est déjà « cachée » sur le disque pendant l’installation de Windows – une fonctionnalité en soi-même. Nous garderons toujours les fonctionnalités disponibles, et nous les mettrons toujours à jour, même quand certains composants ne sont pas installés par défaut – de cette façon si vous ajoutez un composant par la suite, vous ne risquerez pas d’installer de code vous exposant à un problème de sécurité existant. Ceci est un autre moyen important que nous avons de garder Windows à jour et sécurisé, même pour les composants facultatifs.

La croissance du système au fil du temps est aussi un sujet sur lequel nous nous devons de fournir plus de « transparence ». Par exemple, Windows archive les versions antérieures de composants du système mis à jour, de façon à assurer de robustes retours en arrière. Comme prévu, un nouveau système installe les mises-à-jour disponibles sur Windows Update. Assez rapidement après l’installation d’une mise à jour importante (comme un « Service Pack ») qui comprend ou étend des mises à jour précédentes plus mineures, il nous est possible de récupérer l’espace disque occupé par ces dernières.

Pour aider au dépannage, Windows place des enregistrements un peu partout sur le disque, et ces enregistrements peuvent croitre de façon significative. Par exemple, quand une application « crashe », Windows archive un très gros fichier dump qui facilite l’analyse ultérieure du problème. Nous avons beaucoup de bonnes raisons de procéder ainsi, mais dans le souci de préserver le maximum d’espace disque, il nous sera important de penser à la façon dont nous gérerons cette croissance, et dont nous récupérerons l’espace disque quand nous le pourrons. Nous nous soucions aussi de l’espace disque occupé par l’hibernation et la restauration du système. Sur une machine ayant peu d’espace disque, réserver 1GB à l’hibernation coute cher, et il y a peut-être moyen de réduire la taille du fichier hiberfil.sys. De même, il devrait être possible de configurer la restauration du système de façon à n’occuper que le minimum de clichés requis, et non pas 15% du disque par défaut.

A WinHEC, nous avions en démonstration plusieurs machines avec des disques ou des partitions de 16GB, et ayant toujours beaucoup d’espace disque disponible. Cependant, comme pour tous les benchmarks, nous ne recommandons pas d’effectuer des mesures d’espace disque sur les versions pré-Béta de Windows 7.

En conclusion, il est probable que les différents efforts en cours dans l’équipe de Windows 7 aboutiront à une empreinte sur disque plus petite que dans Windows Vista, donnant ainsi aux fabricants de PC plus de latitude dans la conception de leurs systèmes. Ceci sera accompli grâce à une meilleure définition des réglages par défaut, et de plus grandes facilités de contrôle pour les fabricants d’ordinateurs, les utilisateurs et les professionnels IT, et sera accompli aussi sans compromettre la fiabilité et la robustesse générales de Windows.

- Michael Beck

L'accessibilite de Windows 7

L’auteur de cet article s’appelle Michael Bernstein. Michael est responsable de développement dans l’équipe de Plateforme d’Interface Utilisateur, où il travaille sur l’accessibilité de Windows. «Accessibilité » est un terme que nous utilisons pour décrire les APIs et fonctionnalités qui permettent à Windows d’être utilisé par le plus grand nombre de personnes, et de donner à chacun la possibilité d’accéder à ses fonctions, quelles que soient ses capacités physiques ou cognitives. Dans ce but, Windows comprend à la fois des logiciels d’accessibilité intégrés, et des APIs que les produits de technologie d’assistance et les développeurs d’applications peuvent utiliser pour rendre leurs logiciels accessibles à tout un chacun. L’accessibilité revêt une grande importance pour Microsoft, et c’est un des pivots clefs dans le développement de Windows 7. Au niveau corporatif, Microsoft dispose également d’une équipe chargée de s’assurer que les PC soient plus faciles à voir, entendre, et utiliser. Vous trouverez plus d’informations sur nos initiatives dans le domaine de l’accessibilité numérique sur nos sites français, ou anglais. – Steven.

Bonjour, je suis responsable de développement pour l’Accessibilité et la Reconnaissance Vocale dans Windows 7, et je me propose de décrire la façon dont nous avons conçu l’accessibilité de Windows 7.

Depuis le début du projet, notre intention était de développer le système d’exploitation le plus accessible que Microsoft ait jamais produit. Nous nous sommes cependant rapidement aperçus que la notion d’accessibilité n’est pas aussi simple qu’il n’y parait. Au début, il est tentant de penser à l’accessibilité en termes binaires, un peu comme on parle de la sécurité : votre système est soit accessible (ou sécurisé), ou il ne l’est pas. Cette approche trouve cependant rapidement ses limites. Elle ne tient par exemple pas compte du fait que les besoins de nos utilisateurs aveugles sont totalement différents de ceux de nos utilisateurs sourds, ou même différents des ceux des malvoyants : une loupe est inutile pour certains, et cruciale pour d’autres. De même, elle n’inclut pas les cas où une fonctionnalité est techniquement accessible, mais source de frustration dans la pratique, nécessitant par exemple 36 frappes sur le clavier pour exécuter. L’accessibilité n’est de fait pas un problème binaire, mais une étude de facilité d’utilisation pour un public spécifique ayant des besoins particuliers.

Ces questions difficiles générant des réponses tout aussi difficiles, nous avons choisi une stratégie en quatre volets afin d’améliorer l’Accessibilité de Windows 7.

I. Une base solide : UI Automation

Microsoft inclut dans Windows Vista une nouvelle infrastructure d’accessibilité appelée « UI Automation ». UI Automation permet aux technologies d’assistance usager (« AT ») de commander l’Interface Utilisateur (« UI ») de façon programmatique, et aux logiciels d’exposer leurs fonctionnalités accessibles de façon plus complète que cela n’était possible dans les versions antérieures de Windows – on peut obtenir plus d’informations, et l’UI peut être mieux manipulée. UI Automation introduit aussi la notion de modèles de contrôle, permettant à chaque contrôle de décider comment il peut être le mieux manipulé. Par exemple les boutons utilisent le modèle de contrôle Invoke, indiquant qu’ils peuvent être cliqués, tandis que les zones de liste déroulante utilisent ExpandCollapse, indiquant qu’elles peuvent être ouvertes ou fermées. Nous permettons ainsi à chaque contrôle d’être différent, au lieu de tous les forcer dans un même moule. Cette infrastructure a fait son apparition dans Windows Vista, et est toujours en cours d’adoption.

Pour Windows 7, nous avons investi dans l’amélioration de la performance de cette infrastructure, et créé pour elle une nouvelle API en code natif, afin de la rendre plus efficacement utilisable par un plus grand nombre de produits de technologie d’assistance. Dorénavant, les logiciels écrits en C++, tout comme ceux écrits sur le .NET Framework, peuvent utiliser UI Automation.

Nous avons également beaucoup travaillé pour nous assurer que l’infrastructure UI Automation s’intègre bien à l’ancien « Microsoft Active Accessibility (MSAA) », et avons développé de nouvelles techniques facilitant la transition de l’ancienne à la nouvelle infrastructure. Les clients d’UI Automation peuvent désormais lire l’information d’accessibilité des logiciels MSAA et vice versa, assurant ainsi une accessibilité maximum, quelle que soit l’infrastructure d’origine utilisée par le logiciel. Ces deux infrastructures (UI Automation et MSAA) collaborant ainsi étroitement, il nous a paru naturel d’appeler leur synthèse le « Windows Automation API ». Cette architecture est à la base de notre effort portant sur l’accessibilité, et nous sommes heureux de l’inclure dans Windows 7.

II. Améliorer nos fonctionnalités d’accessibilité

Nous avons également amélioré les programmes de technologie d’assistance inclus dans Windows. Afin de rendre Windows plus accessible à ses utilisateurs handicapés, Microsoft collabore étroitement avec de nombreuses sociétés de produits de technologie d’assistance, mais nous fournissons aussi dans le système d’exploitation plusieurs programmes nous assurant que ces utilisateurs ont bien accès à Windows, avant même d’installer d’autres logiciels. Pour Windows 7, nous avons décidé d’améliorer deux de ces logiciels : le Clavier Visuel et la Loupe.

Le changement le plus apparent du Clavier Visuel est bien-sûr son nouveau look, mais nous avons aussi inclus des améliorations plus subtiles. L’apparence de ce logiciel n’avait pas changé depuis Windows XP, et nos utilisateurs nous demandaient également de le rendre redimensionnable. Afin de répondre à ces deux requêtes, nous avons travaillé étroitement avec les développeurs du Tablet PC, et partageons maintenant avec eux une base de code commune pour le Clavier Visuel et le clavier d’écran tablette. Ces deux claviers ont désormais une apparence plus attrayante aux normes de Windows 7, et sont tous deux redimensionnables. Ils sont toujours cependant distincts, car nos utilisateurs les emploient différemment : les utilisateurs de Tablet PC peuvent par exemple avoir besoin de passer rapidement du clavier à l’écriture manuscrite, tandis que les utilisateurs du Clavier Visuel nécessitent des touches qu’ils puissent taper simplement en se positionnant au-dessus, si leur handicap les empêche de cliquer la souris. Dans la même veine, nous avons aussi ajouté la prédiction textuelle, qui permet à nos utilisateurs handicapés de taper du texte plus rapidement. Ceux d’entre vous qui auront déjà essayé d’utiliser un clavier visuel apprécieront à quel point la prédiction textuelle peut améliorer la vitesse de frappe.

La Loupe a subi par un remaniement plus substantiel. La Loupe de Windows Vista et Windows XP ne fournissait pas une expérience très intuitive : quand vous pointiez sur une région d’écran, les éléments agrandis apparaissaient dans une fenêtre distincte, généralement ancrée en haut de l’écran. Il vous fallait pointer sur une zone, et en regarder une autre. Pour résoudre ce problème, nous avons considéré deux solutions possibles : soit élargir tout l’écran, soit faire en sorte que la zone agrandie suive le pointeur de la souris, en laissant le reste de l’écran inchangé. Ces deux solutions sont devenues nos deux modes pour la Loupe de Windows 7 : le mode « plein-écran », et le mode Lentille.

Le mode « plein-écran » est conçu pour agrandir tous les éléments de l’écran en même temps. Si vous positionnez la souris ou le focus du clavier vers le centre de l’écran, la vue reste la même ; si vous vous déplacez vers les côtés, la Loupe défile la vue pour vous suivre. Un inconvénient de ce mode est que l’utilisateur risque de perdre la référence de son contexte. Pour pallier ce problème, nous avons ajouté une animation contextuelle qui permet de localiser votre zone de travail par rapport à l’écran par un zoom arrière, puis d’y revenir par un zoom avant.

Le mode Lentille, en comparaison, est utile pour agrandir un élément en particulier. Dans ce mode, la lentille est centrée sur le pointeur de la souris, donnant l’impression d’utiliser une loupe. Il est possible de redimensionner la lentille et de la rendre par exemple courte et très large, un format particulièrement utile pour lire un document ligne-par-ligne. Nous avons basé ce concept sur celui de la loupe de la souris Microsoft IntelliPoint, et l’avons rendu maintenant disponible pour n’importe quelle souris.

Nous avons aussi répondu aux demandes de nos utilisateurs concernant la trop grande place prise sur l’écran par la fenêtre de la Loupe. Nous avons commencé par repositionner les contrôles les plus utilisés (comme zoom avant et arrière) dans une petite barre d’outils qui disparait en filigrane semi-transparent quand elle n’est pas utilisée. Les autres options sont disponibles dans un dialogue d’options en cas de besoin. Nous avons aussi donné à toutes les fonctionnalités de la Loupe des raccourcis clavier, les rendant ainsi directement accessibles sans interface utilisateur. Win-+ permet d’utiliser le zoom à tout moment dans Windows 7.

Ces outils améliorent directement l’accessibilité de Windows pour nos utilisateurs malvoyants, ou ayant des handicaps de dextérité, mais il est évident que tout le monde pourra bénéficier d’un PC plus facile à voir ou à utiliser, et ces deux exemples démontrent bien l’intérêt global des outils « AT » - au PDC, nous avons montré le Clavier Visuel et la Loupe, et chacun a pu voir les avantages que présentent ces outils, quels que soient ses aptitudes ou ses handicaps.

III. Faciliter le développement de logiciels accessibles

En elles-mêmes, les APIs de Windows ne suffisent pas à rendre Windows accessible ; il est tout aussi essentiel que les logiciels développés pour Windows jouent leur rôle en fournissant des données accessibles aux programmes AT. Par exemple, un lecteur d’écran peut être un excellent outil, mais son intérêt sera limité s’il ne peut pas lire votre navigateur préféré. Les outils d’assistance usager comme les lecteurs d’écran ou les loupes sont les clients de l’infrastructure d’accessibilité, et les logiciels que vous souhaitez utiliser (comme les navigateurs ou les logiciels de traitement de texte) en sont les fournisseurs. L’utilisation de Windows ne sera accessible que si les deux fonctionnent main dans la main – il faut à la fois un client de qualité et un fournisseur bien programmé pour une bonne expérience d’accessibilité. Ceci dit, il y a énormément de fournisseurs dans l’écosystème informatique de Windows, et il nous est difficile de travailler avec chacun d’entre eux pour s’assurer qu’ils sont bien écrits.

Pour relever ce défi, notre équipe a développé deux outils : « UI Accessibility Checker » (Vérificateur d’Accessibilité d’Interface Utilisateur), aussi appelé AccChecker, et « UI Automation Verify » (Verificateur d’UI Automation), aussi appelé UIA Verify. Ensemble, ces deux outils peuvent analyser un logiciel (un fournisseur), et indiquer les problèmes courants d’accessibilité. Les développeurs de logiciels peuvent ainsi utiliser AccChecker et UIA Verify et détecter les erreurs dans le code de leur fournisseur avant que le produit ne soit sur le marché. Les ingénieurs d’assurance qualité peuvent les utiliser pour vérifier la qualité du travail de leur entreprise. Nous sommes tellement convaincus de l’importance de ces outils que nous diffusons AccChecker et UIA Verify en Open Source, afin de toucher le plus grand nombre possible d’utilisateurs. Si vous n’êtes pas un programmeur, vous n’utiliserez peut-être jamais ces outils, mais vous bénéficierez certainement de leur capacité d’élimination de bogues avant qu’ils ne vous atteignent.

IV. Planifier l’accessibilité dès le premier jour

Pour nous assurer que les fonctionnalités de Windows elles-mêmes étaient de bons fournisseurs, nous avons emprunté un concept au Cycle de Développement de Sécurité : l’estimation de risque. Avant qu’une seule ligne de code ne soit écrite, nous avons attribué à chaque fonctionnalité de Windows 7 en cours de planification un niveau de « risque d’accessibilité ». Les fonctionnalités qui utilisent les contrôles les plus courants sont généralement les plus accessibles, puisque Windows inclut des fournisseurs pour ses composants de base ; les fonctionnalités plus élaborées, ayant leurs propres routines de dessin d’écran, présentent plus de risques. Ceci a permis à chaque équipe de quantifier le niveau de « risque d’accessibilité » auquel elle faisait face, et de planifier en conséquence. Cela a aussi permis à notre équipe de travailler plus étroitement avec les équipes présentant un niveau de risque élevé, et de nous assurer qu’elles possédaient les ressources et les outils dont elles avaient besoin pour rendre leur fonctionnalité accessible. Nous nous sommes également assurés qu’elles bénéficiaient de plus de test et de validation. En fin de compte, la plupart des fonctionnalités de Windows 7 sont plus accessibles qu’elles ne l’étaient dans les versions précédentes, garantissant ainsi une meilleure expérience utilisateur.

En conclusion, nous avons mis l’accent sur l’accessibilité dans la conception de Windows 7. Nous avons fait des progrès considérables dans le renforcement de l’infrastructure d’accessibilité, et dans l’amélioration de logiciels inclus dans Windows, comme le Clavier Virtuel et la Loupe. Les outils AccChecker et UIA Verify ont grandement facilité la validation de logiciels, afin de les rendre non seulement compatibles avec les outils d’assistance usager actuels, mais aussi avec les futures générations d’outils basés sur les APIs de Windows Automation. Notre approche concernant l’accessibilité des fonctionnalités et composants de Windows s’est consolidée, et est devenue plus méthodique et plus intégrée, grâce au travail de centaines d’ingénieurs dans toute la compagnie. Nous sommes fiers de ce que nous avons accompli dans Windows 7, et espérons permettre à nos utilisateurs handicapés de décupler leur potentiel et de connaitre une expérience encore plus satisfaisante avec Windows.

-- Michael.

L’équipe de Windows 7

Merci à tous pour vos commentaires et courriels. C’est avec beaucoup de plaisir que je vois ce dialogue s’établir, et le lancement de ce blog a aussi insufflé une énergie nouvelle dans l’équipe. Il me parait maintenant naturel de procéder aux présentations, et de décrire même sommairement la composition de l’équipe représentée par ce blog.

Avant de commencer, je voudrais dire quelques mots sur ce que l’on est en droit d’attendre de ce blog, et en premier lieu sur les nombreux commentaires et courriels que j’ai reçus – de fait, j’ai passé la plus grande partie de mon weekend à lire vos réponses. Certains thèmes sont récurrents. En général le blog a été reçu de façon très chaleureuse, et nous en sommes ravis. La requête de loin la plus fréquente concerne la performance de Windows, souvent simplement pour nous demander de « rendre Windows plus rapide ». C’est un sujet complexe, et nous avons l’intention d’y consacrer du temps sur ce blog dans les mois qui viennent. Il y a aussi de nombreuses requêtes spécifiques représentant souvent toutes les opinions possibles sur un même problème – certains nous suggèrent de nous « débarrasser de la fonctionnalité <X> », ou de ne « pas faire <X> », alors que d’autres nous confirment que « quoiqu’il arrive, il est très important de garder (ou faire) <X> ». Personnellement, je pense que l’intérêt de ce blog est en grande partie de pouvoir discuter des différents aspects d’un problème donné. Même une notion aussi cartésienne que la performance d’un système présente de nombreuses subtilités. Par exemple, certains suggèrent que la meilleure solution pour améliorer la performance de démarrage serait de ne rien charger au lancement de l’ordinateur, tandis que d’autres pensent que retarder le chargement ne ferait que les ralentir plus tard ; d’autres enfin suggèrent que la meilleure approche serait de fournir un gestionnaire de démarrage laissant à chacun son libre choix. Chacune de ces méthodes a ses avantages propres, et mérite d’être débattue, mais démontre aussi les subtilités et complexités d’un sujet apparemment simple.

En second lieu, et à notre grande surprise, un certain nombre d’entre vous ont mis en question l’authenticité de ce blog. Certains ont même suggéré que les articles étaient écrits par des prête-noms, ou que ce blog n’est qu’un stratagème. Soyez rassurés : j’écris ce blog dans « Windows Live Writer », et je le publie directement. Ce blog est authentique – y compris les fautes de frappe, les fautes d’orthographe, et toutes les autres. Il n’y ni intermédiaire ni filtrage. Des membres de l’équipe y contribueront aussi, et ils signeront leurs articles en nom propre (je signerai mes commentaires avec mon identité msdn, steven_sinofsky).

Troisièmement, quelle sera la fréquence de parution, et quand allons-nous aborder des thèmes portant sur « les fonctionnalités de Windows 7 » ? Quand nous avons dit que nous allions publier « régulièrement », nous n’avions pas réellement de plan ou de calendrier particulier en tête ; nous astreindre artificiellement à une fréquence donnée serait contradictoire à la nature même d’un blog. En gros, nous avons l’intention de suivre un modèle similaire à celui que vous connaissez sur IEBlog. Je vous dévoilerai qu’à Microsoft, personne ne m’a encore accusé de ne pas participer suffisamment à mon blog interne. J

Comme nous l’avions dit dans notre premier article, nous avons l’intention de parler de la création de Windows 7 (le « comment »), et la première étape est de vous présenter les ingénieurs qui réalisent le projet. Nous nous pencherons par la suite sur le « pourquoi » et le « quoi » du produit lui-même.

Commençons donc par rencontrer l’équipe…

Il est facile de se représenter l’équipe Windows comme un groupe ou une entité, ayant à l’occasion une personne donnée agissant en tant que porte-parole – soit au cours d’une présentation lors d’une conférence, ou à l’occasion de la publication d’un livre ou d’un article, ou de la parution d’un blog. En fait, Windows est le produit de tout Microsoft, le fruit d’une multitude d’apports provenant d’individus et d’équipes de développement divers répartis dans toute l’entreprise. Cependant, l’équipe de conception de Windows à proprement parler est cogérée par Jon et moi. Jon dirige le système d’exploitation qui comprend entre autres le noyau, toute l’infrastructure des pilotes, le système réseau et les outils de développement (pour le client ainsi que le serveur). Quant à moi, je travaille sur l’équipe « Windows Client Experience » qui développe entre autres le « shell Windows », le bureau de travail, les composants graphiques, et tout l’audiovisuel. Windows Media Center, un autre composant important du produit Windows, est développé par l’équipe responsable des produits TV Microsoft (IPTV, extendeurs, etc.).

Organiser et mettre en place une telle équipe est une entreprise difficile, dont la partie la plus importante reste de planifier et de répartir l’ensemble du travail. Cette planification fait partie intégrante de notre objectif d’améliorer la cohérence et l’intégration de Windows 7. Aussi au lieu d’une organisation monolithique, ou de deux équipes, nous considérons que l’équipe Windows 7 est constituée d’environ 25 « équipes de fonctionnalité » différentes.

Chaque équipe de fonctionnalité  est responsable d’une partie spécifique de Windows 7 – code, fonctionnement, qualité, et développement. L’équipe de fonctionnalité est l’unité de base dans la répartition et la coordination du travail à travers l’organisation. Ce niveau de granularité présente certains avantages pratiques – une équipe de fonctionnalité  peut tenir entière dans une salle de réunion, ou aller ensemble au cinéma. La taille moyenne d’une équipe est d’environ 40 développeurs, quoique ce chiffre varie. Une équipe de fonctionnalité  est définie à la fois par ce sur quoi elle travaille, et par les ingénieurs qui la constituent.

En général, les équipes de fonctionnalité  de Windows 7 portent les noms des divers composants de Windows avec lesquels vous êtes déjà familiers. Certaines équipes associées aux éléments de base de Windows sont restées pratiquement inchangées depuis plusieurs versions, alors que de nouvelles équipes ont été créées pour travailler sur de nouvelles fonctionnalités. Certaines équipes travaillent principalement sur la version serveur (par exemple la Machine Virtuelle), alors que d’autres (tel que Internet Explorer) créent des produits aussi disponibles en dehors de Windows 7.

En général, une équipe de fonctionnalité  est responsable à la fois de composants d’architecture et de divers scénarios de Windows. Le terme « fonctionnalité » lui-même est ambigu ; certains parlent de fonctionnalité  pour un élément de l’interface utilisateur, alors que d’autres utilisent le terme pour designer des composants d’architecture (tel que TCP/IP). Notre philosophie est d’établir un équilibre entre scenarios et architecture. Nous évitons aussi de séparer la partie infrastructure de la partie interface utilisateur afin de faire en sorte que les équipes soient responsables d’un scénario de bout-en-bout (par exemple, « Recherche et Organisation» construit à la fois le moteur d’indexation et l’interface utilisateur de recherche). Voici une liste partielle des équipes de fonctionnalité  de Windows 7 (par ordre alphabétique anglais) :

• Applets and Gadgets : Petites Applications et Gadgets
• Assistance and Support Technologies : Techniques de Support et d’Assistance aux Utilisateurs
• Core User Experience : Expérience Utilisateur
• Customer Engineering and Telemetry : Télémétrie
• Deployment and Component Platform : Déploiement et Plateforme
• Desktop Graphics : Graphiques
• Devices and Media : Périphériques et Audiovisuel
• Devices and Storage : Périphériques et Stockage
• Documents and Printing : Documents et Impression
• Engineering System and Tools : Outils de Développement
• File System : Système de Fichiers
• Find and Organize : Recherche et Organisation
• Fundamentals : Systèmes Fondamentaux
• Internet Explorer : Internet Explorer, y compris le déploiement hors Windows
• International : Internationalisation
• Kernel & VM : Noyau et Machine Virtuelle
• Media Center
• Networking – Core : Réseau – Base
• Networking – Enterprise : Réseau – Entreprise
• Networking – Wireless : Réseau – Sans Fil
• Security : Sécurité
• User Interface Platform : Plateforme d’Interface Utilisateur
• Windows App Platform : Plateforme d’Applications Windows

Je pense que pour les besoins de cet article, la plupart de ces noms parleront d’eux-mêmes – dans nos publications futures les auteurs feront référence à cette liste pour indiquer l’équipe à laquelle ils appartiennent.

Ceci devrait vous donner une idée des multiples sous-systèmes de Windows, ainsi que de la façon dont nous avons divisé un projet complexe en équipes plus petites. Bien entendu tout au long de ce projet de nombreuses fonctionnalités sont développées par plusieurs équipes travaillant en collaboration. Cela requiert de la pratique. Par exemple, pour des raisons d’efficacité ou de performance, il est souvent naturel de développer une fonctionnalité par « couches » successives, en général de bas en haut (en commençant par la plateforme, et en finissant par l’interface utilisateur). Cependant, l’usager utilisera souvent plusieurs couches en parallèle, et les administrateurs de réseaux souhaitent en général gérer les ordinateurs de haut en bas.

Je reconnais qu'il peut s'agir ici d’un point de vue interne, puisqu’en général il vous est impossible de savoir dans quelles équipes « vivent » diverses fonctionnalités. Par exemple, les plateformes de Tablet PC et d’encrage, ainsi que la reconnaissance vocale, le « multi-touch » et les modèles d’accessibilité font partie de l’équipe de Plateforme d’Interface Utilisateur. Cela s'explique par la nécessité de partager l'infrastructure de tous les mécanismes « de saisie », même si un même usager n’en utilisera pas tous les niveaux. Cette conception commune d’API pour toutes les saisies de données permettra aux développeurs de bénéficier de tous les modes d'interaction utilisateur au travers d'un seul jeu d'API.

Une autre caractéristique de nos équipes de fonctionnalité est la façon dont elles sont composées. Une équipe de fonctionnalité comprend trois branches d’ingénierie: les ingénieurs de développement de logiciel (« software development engineer », « sde » ou « dev »), les ingénieurs de développement de logiciel de test (« software development engineer in test », « sdet », désolé, je n’ai pas encore écrit de profil de travail à usage externe) et les responsables de programmes (« program manager », « pm »). La combinaison de ces trois disciplines est une caractéristique unique de Microsoft qui a même attiré l'attention de certains chercheurs. Les liens ci-dessus vous référeront aux descriptions de « dev » et de « pm » décrites sur mon ancien blog. (je dois toujours créer un article similaire sur le « sdet » !).

De façon succincte, le « dev » est responsable de l'architecture et du code, le « pm » est responsable de la définition et de la spécification de la fonctionnalité, et le « testeur » est responsable de la validation et défenseur ultime de l'expérience du client. Tous sont responsables de la qualité et de la performance, chacun apportant une perspective différente. Pour chaque fonctionnalité, des ingénieurs de dev, test et pm collaborent en équipe, à la fois conceptuellement et littéralement. Cet équilibre des pouvoirs est un concept clé dans notre façon de travailler, et assure une approche équilibrée dans le développement de Windows 7. Notre organisation est structurée pour permettre à des dev de travailler pour des dev, des sdets pour des sdets, et des pm pour des pm. En d’autres termes, nous sommes organisés par « fonctions de développement ». Deux optimisations sont ainsi obtenues – nous mettons l’accent sur la compétence dans un domaine et une discipline donnés, et nous nous assurons également de concevoir le produit conjointement et non pas en silos.

Nous parlons de ces trois disciplines comme un tout, car nos équipes de fonctionnalité sont composées de n développeurs, n testeurs et 1/2 n responsables de programme. Ce ratio est assez constant à travers l’organisation. En moyenne, une équipe de fonctionnalité dans Windows 7 compte environ 40 développeurs.

Notre équipe de conception comprend aussi un certain nombre de personnes qui travaillent sur l’ensemble du produit :

• Développement de contenu – les rédacteurs et les éditeurs qui créent l’aide en ligne, le site Web, les documents SDK et les documents de déploiement.
• Planification du produit – responsable de l’étude des besoins des clients qui informe la sélection des fonctions du produit. La planification produit coordonne également notre travail avec nos partenaires dans l’écosystème Windows en matière de design et de développement.
• Design – développe le modèle d’interaction, le langage graphique, et le langage conceptuel de Windows 7.
• Recherche et ergonomie – crée des études en laboratoire et sur site qui montrent comment les utilisateurs répondent aux produits existants et aux fonctions proposées.

Certains d’entre vous ont émis des doutes ou des questions quant à l’effectif de l’équipe de Windows – trop importante, sa taille poserait maintenant problème. Je ferai simplement remarquer que l’ensemble de vos réponses sur ce blog indique une importante demande de nos usagers en faveur d’une gamme de fonctionnalités nouvelles, et de modifications à apporter à Windows. Windows est un énorme projet qui requiert énormément d’effectifs. Au risque de paraître trivial, mon opinion est que l’équipe Windows doit avoir la taille appropriée – ni trop grande, ni trop petite, mais doit surtout être gérée efficacement pour que sa charge de travail soit proportionnelle à sa taille, de façon à produire les résultats attendus. Dans une scène du film Amadeus, l’empereur fait remarquer que le Mariage de Figaro contient « bien trop de notes », ce à quoi Mozart répond : « Il y a juste le nombre de notes nécessaires, Majesté, ni une de plus, ni une de moins ». Lorsque l'empereur insiste et demande à Mozart d'ôter quelques notes, Mozart répond simplement : « A quelles notes pensez-vous en particulier ? ». Ce sont les personnes composant l'équipe qui définissent le produit et développent les scénarios de bout en bout, et notre défi est donc d’avoir l'équipe et la structure appropriées pour maximiser notre capacité à accomplir ces taches - ni trop, ni trop peu.

Je me suis promis qu'aucun de mes billets ne ferait plus de 4 pages, et je crois en être proche. Vos commentaires sont excellents, et nous aident à cibler nos prochains billets. J'espère que celui-ci aidera à préciser le bon contexte.

--Steven

Note sur la traduction des billets et articles de E7

Merci de lire notre blog. Nous sommes heureux de constater l’engouement qu’il suscite, comme en témoignent les innombrables emails et courriels que nous avons reçus. Vous aurez peut-être remarqué que l’une des nouveautés du blog E7 est d’être traduit en plusieurs langues. Notre équipe de développement comprend des ingénieurs venus du monde entier, et effectue toutes les traductions. Ceci nous permet de conserver l’ensemble du blogging dans l’équipe technique de Windows 7 - cette même équipe lira vos commentaires, dialoguera avec vous, et m’aidera aussi à traduire vos courriels.

Pour cette raison, il est probable que vous constatiez un bref délai entre la parution d’un article en anglais et ses traductions. Nous regrettons ce délai, et vous prions de nous en excuser à l’avance. Nous pensons que c’est que c’est un bien petit prix à payer pour nous permettre de garder ce dialogue authentique, et au sein de l’équipe.

La création de Windows 7 - Bienvenue sur « E7 »

Bienvenue sur notre blog! Ceci est le premier article d’un nouveau blog de Microsoft, dédié à la conception et la réalisation de Windows 7. En abrégé, nous l’appelons E7 (de l’anglais « Engineering Windows 7 »).  E7 est l’œuvre de Jon DeVaan et Steven Sinofsky, les deux chefs de projet qui supervisent le développement de Windows 7. Jon et Steven, en collaboration avec les ingénieurs de l’équipe, posteront et  commenteront des articles, et participeront personnellement à ce blog.

Ensemble, et en commençant par ce premier article, nous nous proposons de jeter un regard avant-coureur sur Windows 7. Nous sommes conscients que le projet suscite beaucoup de questions, et que beaucoup d’entre vous désirent mieux comprendre ce qu’apportera la prochaine version de Windows. Croyez-nous, nous sommes tout aussi impatients d’en parler ! Depuis la mise sur le marché de Vista il y a 18 mois, l’équipe a travaillé d’arrache-pied pour créer cette nouvelle version de Windows !

Ce blog est donc destiné à tous les enthousiastes, blogueurs, et passionnés de Windows. C’est une invitation au dialogue autour d’un thème central: la création de Windows 7. Windows présente toutes les complexités d’un projet informatique de grande envergure : choisir les fonctionnalités, les concevoir, les développer, et s’assurer de leur haute qualité. Mais Windows est aussi confronté au défi supplémentaire de devoir résoudre ces complexités pour une clientèle extraordinairement diverse et variée. C’est une formidable responsabilité pour notre équipe et pour tous les ingénieurs qui la composent.

Nous sommes persuadés que le succès d’un logiciel à l’échelle de Windows passe par l’établissement d’une tribune libre, ouverte et honnête, où nous pourrons discuter de la façon dont nous mitigeons tous ces intérêts. Ce blog représente à la fois la promesse et le point de départ d’un tel dialogue.

La conception d’un produit comme Windows implique un apprentissage systématique des besoins de toutes sortes d’usagers. Dès le départ, et pour planifier le projet, nous avons travaillé avec un ensemble très varié d’utilisateurs et de partenaires (fabricants de PC, développeurs de matériels, entreprises, développeurs de logiciels, et bien d’autres). Nous continuons aussi à nous informer sur les besoins de nos utilisateurs par télémétrie (« Customer Experience Improvement Program »), par des études de facilité d’utilisation, et bien d’autres. Ce blog explorera bientôt tous les moyens différents dont nous explorons les besoins  de nos utilisateurs et du marché, et qui nous permettent de mieux cibler notre logiciel.

Cet automne, nous organisons deux événements majeurs pour les développeurs et tout l’écosystème de Windows. Le PDC (« Professional Developers Conference ») le 27 Octobre, et WinHEC (« Windows Hardware Engineering Conference ») la semaine suivante seront les premiers salons où nous dévoilerons en profondeur des informations techniques sur Windows 7. Pendant les deux prochains mois, et par le biais d’articles réguliers sur le développement du logiciel vu des coulisses, ce blog nous permettra donc d’établir un contexte pour ces deux conférences. Il continuera ensuite jusqu'à la commercialisation finale du produit.

Devançant ce blog, nous avons vu beaucoup de discussions dans les forums à propos des objectifs présumés qu’aurait Microsoft en maintenant un peu plus de contrôle qu’à l’accoutumée sur les communications portant sur Windows 7 (certains penseront sûrement que c’est un euphémisme). Le fait est : notre équipe a appris les risques attenants aux « révélations prématurées », et à quel point il nous est facile de trop nous avancer sur des points de fonctionnalité hypothétiques, avant que nous n’en ayons nous-mêmes pris la pleine mesure.  Pendant tous les communiqués précédant la sortie de Windows 7, notre promesse restera de ne parler d’aucune fonctionnalité pour laquelle nous n’aurions pas atteint un degré suffisant de certitude. Notre souci premier est avant tout la responsabilité que nous avons vis-à-vis de tous nos partenaires et usagers ayant d'énormes investissements misés sur l’évolution de Windows. Il est primordial pour nous de ne pas vainement désorganiser leurs priorités, chambouler l’affectation de leurs ressources, ou leur causer de confusion stratégique. 

Dans le même esprit, nous voulons également nous assurer de ne pas créer d’attentes que le logiciel risquerait de décevoir – par exemple des morceaux de fonctionnalité que nous ne pourrions pas finir, ou des promesses que nous ne pourrions pas tenir, ou un niveau de support que nous ne pourrions pas fournir. Depuis le tout début de Windows 7, notre équipe s’est engagée à tenir ses promesses, et c’est toujours notre but – partager avec vous ce que nous allons développer, pourquoi nous allons le développer, et le finir avec qualité et en temps voulu.

Nous sommes enthousiastes à l’idée de ce blog. Nous sommes nous-mêmes des blogueurs actifs sur l’intranet de Microsoft, et nous nous réjouissons de pouvoir tourner notre attention et notre énergie vers une communauté hors campus ! Nous connaissons les tenants et aboutissants du « blogging », et nous nous attendons à nous amuser, à répondre à beaucoup de questions bien sûr, mais aussi à faire quelques erreurs. Nous le savons déjà : nous ferons quelques faux pas, ou ce que nous dirons sera perçu différemment. Cela ne nous inquiète pas. Tout ce que nous recherchons, c’est un dialogue basé sur le respect mutuel, et l’objectif commun de faire de Windows 7 un excellent logiciel !

Nous nous proposons de poster des articles de façon régulière. Nous lirons vos commentaires, et y répondrons soit directement, soit par de nouveaux articles si nécessaire. Nous nous assurerons aussi que les membres de l’équipe de développement de Windows 7 puissent parler en nom propre. Nous souhaitons préserver le dialogue sur un forum public, mais vous pouvez également nous contacter directement sur email/courriel à steven.sinofsky@microsoft.com si vous le désirez. Un email/courriel est en particulier un bon moyen de suggérer un thème de conversation que nous pourrions avoir sur le blog.

En conclusion de ce premier article de bienvenue, nous vous remercions à l’avance de rester à l’écoute, et espérons que vous vous joindrez à nous dans ce dialogue sur le développement de Windows 7 !

Steven et Jon