Les jeux sont faits

Depuis le 16 décembre 2011 est en ligne la version 1.0 du Référentiel d’exigences pour la labellisation des prestataires d’audit SSI - qui font partie des PSCO (Prestataires de Services de COnfiance, une notion introduite par le RGS). D’ailleurs l’article de l’ANSSI précise que le document actuel sera intégré à la prochaine version du RGS.

Ce document - qui avait déjà fait parler de lui - n’est pas applicable en l’état : on peut lire page 7 que: « La procédure d’évaluation de la conformité des prestataires d’audit aux règles du Référentiel qui leur sont applicables fera l’objet de documents complémentaires ».

Néanmoins le document existant mérite d’être étudié, car il est appelé à devenir une référence dans les futurs appels d’offres de l’administration – du moins si un nombre suffisant d’acteurs jouent le jeu, puisqu’on peut lire sur le site de l’ANSSI que : « Les autorités administratives peuvent utiliser ce référentiel, en totalité ou en partie, dans les cahiers^[1] des charges de leurs appels d’offres de prestations d’audit. Une fois le nombre de qualification de prestataire d’audit suffisant, elles pourront également requérir que l’audit soit réalisé par un prestataire qualifié ».

Que le lecteur se rassure : je ne vais pas me lancer dans une analyse différentielle ligne à ligne des versions 0.9 et 1.0 du même document, mais plutôt jeter quelques bouteilles dans l’océan qui me sépare de l’administration.

Premier point qui me fait chaud au cœur : la page 10. Oui, vous ne rêvez pas, le terme « ingénierie inverse » fait partie des compétences nécessaires au pentester. C’est une révolution de palais – ou une facétie de l’éditeur, car ce terme n’apparaît plus en page 21 (tous les audits applicatifs nécessitent d’avoir accès au code source) ni en Annexe B (dans la liste des compétences techniques).

Deuxième point notable : il n’est plus nécessaire de savoir tout faire. Un prestataire peut être certifié sur tout ou partie des périmètres suivants :
•    Audit d’architecture
•    Audit de configuration
•    Audit de code source
•    Test d’intrusion
•    Audit organisationnel

Il est précisé toutefois page 7 qu’un prestataire ne peut pas être certifié uniquement sur le test d’intrusion ou l’audit organisationnel : « une telle activité étant jugée insuffisante si elle est menée seule ». Voilà qui risque d’éliminer un certain nombre de micro-entreprises … a contrario, j’en connais d’autres qui doivent jubiler devant une définition aussi proche de leur activité – il ne manque qu’une exigence sur les compétences juridiques et/ou CNIL pour éliminer le peu de concurrents encore en lice.

Le document se prononce également sur le délicat sujet du social engineering : on peut lire page 14 que les tests doivent être conduits « dans le respect des personnels ». Ce sujet épineux avait déjà beaucoup agité la Fédération des Professionnels du Test d’Intrusion – lorsqu’elle existait.

Enfin le document donne en page 12 la réponse à la sempiternelle question : « qu’est-ce qu’un ancien hacker » ? Dormez tranquilles : « Le prestataire d’audit peut également demander au candidat une copie du bulletin n° 3 de son casier judiciaire ». Le principe de bon sens « pas vu – pas pris » continue donc de s’appliquer. Désolé pour les « hackers repentis » … Il faut dire que les prestataires de services auraient été victimes de concurrence déloyale s’ils ne pouvaient pas recruter d’anciens hackers comme l’ANSSI ;)

Pour finir, une nouvelle compétence a fait son apparition en page 10 : « L’auditeur doit disposer de qualités rédactionnelles et de synthèse et savoir s’exprimer à l’oral de façon claire et compréhensible, en langue française ». Moi qui était déjà favorable à la dictée lors des entretiens d’embauche, voilà désormais qu’il va falloir introduire le PowerPoint Karaoké … ce qui risque d’être autrement plus sélectif que le challenge SSTIC !

Pour conclure, il est encore difficile de dire où tout cela va nous mener. Quels vont être les critères techniques d’évaluation des prestataires, particulièrement dans des sciences molles comme l’audit organisationnel ? Qui va faire passer les certifications ? Des sociétés privées mandatées par l’ANSSI ? Y aura-t-il un QCM ? Sera-t-il possible de tricher ? Et surtout : est-ce que les prestataires vont se ruer vers la certification ?

L’expérience de la CSPN semble montrer que le ratio complexité/intérêt s’est avéré trop élevé pour les prestataires d’audit comme pour les éditeurs de logiciels.

Même si ce référentiel va s’imposer de lui-même pour la prestation de service aux administrations, il n’est pas dit qu’il connaisse le même succès dans le domaine des prestations privées … surtout si un standard ou une norme - américaine ou internationale - apparaît d’ici là !

PS. Bonne année à tous ! Et oui, j’ai pris la résolution de bloguer plus en 2012 :)

[1] Je me suis permis de corriger une typo ici, car les correcteurs orthographiques Microsoft sont notoirement meilleurs que leurs équivalents Open Source ;)

Yahoo! (ou Android ?) #fail

Un micro-post pour faire suite à mon intervention au SSTIC (et dissiper les malentendus lus sur Twitter).

L'application "officielle" Yahoo! Mail pour Android communique périodiquement en HTTP avec "controller.php" ... et fait fuir le cookie de session au passage.

A ne jamais utiliser sur un WiFi non protégé, donc.

Challenge #fail

Je ne parle pas du Challenge SSTIC évidemment, qui était encore une fois de très bonne facture (félicitations aux gagnants … et aux organisateurs).

Je parle plutôt du Challenge iAWACS/RSSIL. Enfin le challenge officiel, pas celui qui consiste à pirater des sites Internet en live et pouvoir rentrer chez soi tranquillement.

Le principe de ce challenge est simple: deux fichiers chiffrés avec un algorithme “maison” sont publiés. La première personne capable de produire les fichiers source gagne 3000€.

Bien entendu, afin de respecter le principe de Kerckhoffs, l’algorithme utilisé a également été publié. Le challenge consiste donc à cryptanalyser cet algorithme. Ou plutôt devrait consister.

En effet, une lecture attentive des sources permet d’identifier la séquence de code suivante:

PUNCT_CONC_CODE * generateCode()
{
(...)
  now = time(NULL);
  while(now == (time_t)(-1)) now = time(NULL);
  srand(now);

(...)

 

Et dans le programme de test:

aKey->INIT1 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());
aKey->INIT2 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());
aKey->INIT3 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());
aKey->INIT4 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());

 

Sachant que la définition de la macro alea() est plutôt simple:

/* alea(): a random float in [0, 1]      */
#define alea() (rand()/(RAND_MAX + 1.0))

 

Le lecteur averti aura remarqué que la simple connaissance du time() – en secondes - à l’instant de la génération du fichier permet de casser entièrement le challenge. Même en visant large - disons 1 an – la complexité calculatoire reste donc inférieure à 2²⁵.

Je ne cours pas après l’argent, mais 3000€ en 10 minutes reste une affaire rentable :) Toutefois les deux fichiers fournis présentent un entête qui ne semble pas provenir de la librairie fournie par l’auteur.

$ xxd -l 64 challenge_lipperseus1
0000000: 4631 3232 3938 4630 3030 0067 51b3 df01  F12298F000.gQ...
0000010: b663 4b33 4565 0637 0c1f 7912 4e39 64e5  .cK3Ee.7..y.N9d.
0000020: 7f71 3678 5438 2276 3c34 4726 13b8 6b37  .q6xT8"v<4G&..k7
0000030: 3a4a d9c5 3f9c 6d43 ccc6 37f8 59ec 33df  :J..?.mC..7.Y.3.
$ xxd -l 64 challenge_lipperseus2
0000000: 4638 3230 3946 3030 3030 ad94 31b0 1ec1  F8209F0000..1...
0000010: 82c1 4de0 9c97 2797 52f1 458a 5b40 2fe7  ..M...'.R.E.[@/.
0000020: 09b8 fe85 2ea7 2f7a 186b 277f 65a4 5275  ....../z.k'.e.Ru
0000030: 6cfb 845d c6a7 32b3 9141 db25 3526 456b  l..]..2..A.%5&Ek

D’ailleurs, la librairie disponible en ligne ne compile même pas à cause d’une typo. Il est donc difficile de croire que les fichiers aient été “produit directement à partir de ce code source” ;)

Je m’enquière donc du programme original (principe de Kerckhoffs, toujours). Et visiblement je ne suis pas le seul à avoir remarqué le problème.

L’affaire aurait pu en rester là, mais l’auteur a cru bon de répondre. Et là, à défaut d’un gros chèque, je tenais un solide blogpost ;)

Je vous laisse lire la réponse en question, car chaque ligne est délectable. Vraiment. Tenter de la résumer en quelques lignes serait risquer d’en perdre le substantifique fiel. Sans parler du blogpost d’origine qui a lui aussi été édité (oh la vilaine pratique).

Dans tous les cas, en ce qui me concerne, je vais continuer à penser “que les attaquants feront toujours des erreurs exploitables”, puisque l’usage de rand() pose toujours autant de problèmes en 2011 qu’en 2008 … ou qu’en 2003.

Le diable est dans les détails

Ainsi donc l'activité d'audit sécurité va être réglementée en France. Le projet est encore en phase expérimentale, mais le processus étant enclenché, il est inéluctable (modulo le temps de convergence des autorités concernées). Il faut dire que l'ARJEL avait déjà ouvert cette voie[1] en fournissant une liste d'organismes certificateurs.

C'est une idée qui circule depuis quelques temps, sans que j'en aie bien compris les avantages. Car si tout un chacun peut effectivement constater que le marché est inondé par des charlatans ou des sociétés unipersonnelles[2], l'apport effectif d'une réglementation reste à prouver. En théorie "la main invisible du marché" est censée faire son travail. Et elle le fait plutôt bien: la plus grosse partie de l'activité fonctionne par bouche à oreille. Quant aux "tests d'intrusion qui n'intrusent pas", ils correspondent aussi à une demande de certains clients: les mauvais ont donc leur place dans l'écosystème, c'est pour cela qu'ils y survivent.

Maintenant regardons de plus près l'avant-projet produit par l'ANSSI (version 0.9).

Chapitres 3 et 4: de la mesure des compétences techniques

Ce qui frappe en premier lieu, c'est le très haut niveau d'exigence requis par ce document. J'ai immédiatement pensé à la VAE ESSI, qui nécessite des compétences aussi diverses que la cryptographie, l'intelligence économique, la gestion d'une équipe et d'un budget, et un anglais parfait. Au passage, si quelqu'un a des chiffres sur le nombre de VAE ESSI délivrées, merci de les poster en commentaire …

Dans l'avant-projet, on peut lire que "le prestataire d'audit doit s'assurer que les compétences [techniques | organisationnelles], théoriques et pratiques, de l'ensemble des auditeurs qu'il emploie couvre les domaines suivants […]". S'en suit une longue liste à la Prévert, allant des systèmes & réseaux, du développement d'outils intrusifs[3], à la maitrise de la norme ISO 27001, de la méthode EBIOS et du RGS, entre autres. Cette liste est détaillée dans les grandes largeurs en annexe A.

Puisque nous sommes dans le chapitre 3, cette exigence s'applique a priori à la société prestataire et pas à chaque auditeur individuellement. Mais la plupart des prestataires de taille moyenne (disons, moins de 20 personnes) - et il en existe beaucoup dans le secteur - sont quasiment assurés d'avoir un "trou dans la raquette" … Quant aux autres, il restera très difficile de valider que toutes les compétences soient disponibles, persistantes (dans un contexte de turn-over important), et utilisées si la mission le requière.

Dans le chapitre 4 - qui concerne les auditeurs eux-mêmes - il est recommandé que les auditeurs, disposent d'un bac+5 reconnu d'état, justifient en sus de 2 ans d'expérience en informatique "pure", 1 an d'expérience en sécurité, et 1 an d'expérience en audit. Autant dire qu'on n'est pas loin du mouton à 5 pattes, surtout avec les difficultés de recrutement actuelles (et futures, à en juger par la production du système éducatif dans le domaine).

De mon expérience, la mesure objective des compétences techniques est un exercice très difficile … et inutile.

Difficile, car à moins d'enfermer le candidat dans une pièce pendant des heures (sans accès Internet) pour le faire plancher sur des travaux pratiques, il n'est possible d'estimer "au jugé" qu'une infime partie des compétences annoncées sur le CV (dont la liste dépasse souvent les 50 entrées).

Comme l'ANSSI, nous disposons d'un questionnaire technique "infaisable"[4] qui sert uniquement à disqualifier de manière objective un candidat "qu'on ne sent pas". Mais un simple QCM ne peut pas valider des compétences techniques très poussées (tout au plus peut-il servir à délivrer une certification ;).

Inutile, car c'est plus la capacité à apprendre rapidement qui est importante. Le document cite des technologies de bases de données: Oracle, MS-SQL, MySQL et PostgreSQL. Mais j'ai également été confronté à SolidDB (produits Cisco), Access, SQLite (Android), Sybase SQL Anywhere, et probablement d'autres oubliés depuis.

Or aucune société ne peut maintenir à jour des auditeurs sur toutes ces technologies: ce qui compte c'est la rapidité avec laquelle l'auditeur appréhende une nouvelle technologie. Tout candidat qui n'a pas déjà réellement utilisé au moins 3 systèmes d'exploitation, 3 architectures matérielles, et 3 langages de programmation est pour moi un rookie (quelle que soit son expertise dans un domaine très pointu tel que "l'assembleur Intel x86 en environnement Microsoft Windows").

L'exemple des challenges de sécurité (tels que celui du SSTIC) est frappant: le top 10 est à peu près toujours le même. Or je ne peux pas croire que les gagnants récurrents ont étudié a priori des technologies aussi variées que le mode V8086 du processeur Intel ou le système d'exploitation Android. Ils ont appris sur le tas, en temps contraint. C'est à mon avis la seule qualité nécessaire à la pratique du test d'intrusion, compte-tenu de la diversité des missions et de l'environnement technologique mouvant dans lequel nous évoluons.

Chapitre 5: incise sur l'obsolescence des technologies

Le chapitre 5, comme l'Annexe A, contiennent des détails techniques tout à fait inattendus.

Il est question de chercher des failles de type Cross-Site Scripting (le terme n'a pas été francisé ;), injection SQL, et Cross-Site Request Forgery. Pourtant la liste des erreurs potentielles est bien plus longue.

Il me semble ambitieux de citer des technologies, voire des produits commerciaux, dans un document de référence sur les technologies que doit maitriser un auditeur ou un prestataire d'audit. Il m'a déjà été donné de voir du code FORTRAN en audit, tout autant que des applications Android. Comme explicité précédemment, c'est la maitrise de quelques concepts fondamentaux et la capacité à apprendre qui me semblent essentiels à mesurer.

Le paradoxe français, premier acte

J'aimerais ici parler du voile pudique jeté sur l'audit d'applications en source fermée.

Compte-tenu des technologies mentionnées en annexe, on sent que le document s'applique à un nombre limité de prestations d'audit: les réseaux internes, les réseaux d'interconnexion, les applications Web, la téléphonie (sur IP … ou pas), et les environnements virtualisés.

Exit donc par exemple les audits de systèmes embarqués (comme les imprimantes, les caméras WiFi les caisses de cantine ou les badgeuses). Le cas de "l'audit d'applications lourdes de type client/serveur" est réglé en une ligne dans l'annexe ... Quant au problème du Cloud Computing, il ne semble pas encore avoir atteint l'administration:

"Les tests d'intrusion ne devraient pas être réalisés sur des plate-formes d'hébergement mutualisées."

D'après ce document, aucune compétence en reverse engineering n'est donc requise pour être un excellent auditeur sécurité. Ce qui est bien entendu faux dans la pratique, ne serait-ce que pour le développement des codes d'exploitation dont il va être question juste après.

Le paradoxe français, deuxième acte

Bien entendu, l'administration se doit d'être exemplaire et ne peut mentionner la pratique du reverse engineering dans un document officiel. D'ailleurs il est bien précisé que: "f) Le prestataire d'audit est tenu de respecter la législation et la réglementation en vigueur […]".

Mais là où ça devient cocasse, c'est lorsqu'il est dit plus loin que: "Le prestataire d'audit doit fournir, à la fin de l'audit, les développements spécifiques réalisés lors de l'audit pour valider les scénarios d'exploitation des vulnérabilités. Ces développements peuvent être fournis sous la forme de scripts ou de programmes compilés, accompagnés de leur code source, ainsi que d'une brève documentation de mise en œuvre et d'utilisation".

Non seulement il me semble difficile de mettre au point des codes d'exploitation sans pratiquer un minimum de reverse engineering (passons là-dessus), mais surtout cela me semble tout à fait coller avec ce texte (pour avoir fait l'expérience de la rigueur avec laquelle il était interprété par les instances de la SSI française):

"Le fait, sans motif légitime, d'importer, de détenir, d'offrir, de céder ou de mettre à disposition un équipement, un instrument, un programme informatique ou toute donnée conçus ou spécialement adaptés pour commettre une ou plusieurs des infractions prévues par les articles 323-1 à 323-3 est puni des peines prévues respectivement pour l'infraction elle-même ou pour l'infraction la plus sévèrement réprimée."

En clair, livrer à ses clients des exploits "clé en main", c'est (probablement) mal.

Des chiffres et des lettres (et des couleurs, aussi)

Un dernier point qui me tient à cœur, c'est la caution officielle apportée aux matrices de risque, d'impact, etc. qui doivent enrichir et colorer[5] le rapport.

Pour mémoire, ces matrices ont pour but:

• De lutter contre les consultants qui n'hésitent pas à faire mousser la production d'un outil automatique et brodent sur la dangerosité des "ICMP Timestamp".
• D'en faire le moins possible après l'audit (c'est-à-dire d'économiser des sous), en supprimant toute action qui n'a pas été parée de rouge[6] dans le rapport.

En ce qui me concerne, j'essaie de résoudre le problème à la source: la seule classification que j'utilise dans les rapports est PWN ou PAS PWN. Ce qui évite de ratiociner pendant des heures sur la criticité d'une faille sur une échelle de 0 à 4, 10 ou 20.

En guise de conclusion

Il y a de bonnes idées dans ce document.

Par exemple, il y est rappelé que le test d'intrusion ne prend tout son sens qu'en complément d'un audit préalable du système (au sens large), d'abord dans le chapitre 2:

"Un test d'intrusion seul n'a pas vocation à être exhaustif. En revanche, il s'agit d'une activité qui peut être effectuée en complément des activités décrites dans les chapitres 2.1, 2.2, 2.3, 2.4 afin d'en améliorer l'efficacité (…)".

… mais surtout en annexe B:

"En revanche, l'activité de test d'intrusion ne devrait jamais être réalisée seule et sans aucune autre activité d'audit."

Cette même annexe B rappelle que l'audit "à l'arrache" d'un sous-système juste avant sa mise en production est inefficace, voire contre-productive:

"Les audits devraient être le plus exhaustif possible (…)".

Personne ne me demande mon avis, mais puisque je suis sur mon blog, je vais le donner quand même :)

Il me semble qu'une certification aussi ambitieuse, à destination essentiellement des grosses entreprises, va:

• Disqualifier tout un tas de petits prestataires pourtant très compétents dans leur(s) domaine(s).
• Etre inapplicable en pratique, particulièrement dans la phase d'évaluation des compétences (aussi bien collectives qu'individuelles).

Enfin ce document continue à nier la réalité de l'activité d'audit sécurité, ce dont Cédric s'est par ailleurs ému sur son blog, et ne règle pas le problème du bootstrapping (comment former des auditeurs qualifiés alors qu'il faudrait une vie pour acquérir les compétences recommandées à titre individuel).

Voici donc une proposition alternative:

• Faire du métier d'auditeur en sécurité une profession réglementée (sur le modèle des notaires, des pharmaciens, des médecins, etc.).
• Certifier les personnes sur leurs compétences (un gynécologue n'est pas un urologue), en organisant de réelles sessions d'examens.
• Exiger (éventuellement) un renouvellement périodique de la certification.
• Créer une instance représentative de la profession, qui collecterait tous les rapports d'audit, ce qui permettrait d'avoir un catalogue de produits audités un peu plus étoffé que celui de la CSPN. Cette instance pourrait éventuellement servir d'interface avec les éditeurs logiciels, ou de tiers de confiance pour l'achat/revente de codes d'exploitation (missions qui ne sont pas actuellement dans les compétences du CERTA, sauf erreur de ma part).

Les commentaires sont ouverts.

---

[1] Comme celle du filtrage d'Internet diront les mauvaises langues.
[2] HSC n'en est plus une depuis quelques temps.
[3] Avec un "motif légitime" je suppose.
[4] Curieusement, aucun candidat n'a été capable de reconnaitre une implémentation MD5 en assembleur MIPS à ce jour.
[5] Sauf avec Latex, puisqu'on ne peut pas mettre de couleurs dans les tableaux.
[6] Certains préfèrent le noir pour les failles critiques, les goûts et les couleurs …

Une semaine avec l'iPad

Il se trouve que j'ai récupéré par hasard un iPad, dans des circonstances qui ne peuvent s'expliciter qu'autour d'une bonne bière. N'ayant aucune attente particulière par rapport à cet objet - qui commence à fasciner et inquiéter les entreprises - je vais donc pouvoir en faire un compte-rendu dépassionné et objectif.

Pour commencer, l'engin est assez élégant, quoique pesant. On reconnait la qualité du design Apple, y compris en ce qui concerne l'emballage.

La prise en main est bonne - il y a peu de chances de le laisser choir par inadvertance.

Ce qui ne marche pas

A l'usage, voici plusieurs lacunes qui apparaissent assez rapidement:

1. Tout d'abord, ça n'est pas l'objet ubiquiteux qu'on nous promet. J'ai un toujours un téléphone dans la poche, mais emporter son iPad demande une certaine planification (y a-t-il un vestiaire à destination, etc.). Et le sortir dans le métro pour lire son journal favori relève encore de la science-fiction.
2. C'est très cher à l'usage. Autant l'iPhone nous avait habitués à des applications gratuites (en version bridée, ou financée par la publicité), autant les applications iPad se destinent immédiatement à un public de gens "qui ont les moyens".
3. Même les applications gratuites font un usage intensif du "in app purchase". Laisser ses enfants jouer avec l'iPad peut rapidement se transformer en drame. Le jeu "village des schtroumpfs" en est la caricature: tous les éléments du jeu sont payants. Si les enfants aiment la salsepareille, papa va devoir sortir l'oseille …
4. L'absence de multifenêtrage fait cruellement défaut quand on vient de la bureautique traditionnelle. Impossible de copier/coller rapidement un morceau de texte d'une application dans une autre: il faut suspendre la première application, ouvrir la deuxième, puis revenir à la première …
5. La communication avec le monde extérieur se limite au navigateur Web (impossible de brancher une clé USB par exemple). Du coup la suite d'applications Google devient rapidement indispensable pour entrer et sortir de l'engin (prendre des notes, sauvegarder des signets, etc.)
6. Impossible d'avoir confiance dans les applications disponibles sur l'App Store. Il existe bien des clients RDP et SSH gratuits par exemple, mais il faut réaliser un sérieux background check sur l'éditeur avant de saisir son mot de passe root dans une telle application.
7. Mon efficacité au clavier virtuel reste inférieure à celle d'un clavier réel, en particulier à cause de la séparation entre lettres, chiffres et signes de ponctuation dans trois claviers distincts. Autant dire que taper des lignes de commandes shell avec un clavier virtuel relève de l'épreuve de nerfs. Les gens qui utilisent des mots de passe robustes prennent rapidement l'habitude de les mémoriser dans les applications ...
8. Il est impossible d'imprimer (par exemple un plan Mappy).

Maintenant il est clair que cet objet remplit parfaitement son rôle dans plusieurs domaines.

Ce qui marche

Sa supériorité sur un PC (et sa qualité principale à mon avis) c'est que … ça marche ! Grâce à la maitrise complète du matériel et du système d'exploitation par Apple, et au cloisonnement des applications tierces, plus besoin de se préoccuper d'une incompatibilité entre un antivirus et une protection logicielle par exemple …

Sans parler des problèmes de drivers insurmontables sur PC (surtout depuis la cohabitation entre drivers Windows XP, drivers Windows Seven 32 bits, et drivers Windows Seven 64 bits - lorsqu'ils existent). Sur mon Dell E4300, même en installant la "suite de sécurité Trust Wave Embassy" livrée par Dell, je ne sais pas comment utiliser le lecteur d'empreinte digitale ou le lecteur RFID intégré. Quant au "hub de sécurité Broadcom", il contient des commandes cachées[1], et ne peut être reflashé officiellement que sous MS-DOS. De même pour la carte 3G intégrée[2], qui est horriblement instable par ailleurs.

Alors que sous iPad … tous les périphériques (WiFi, accéléromètre, etc.) fonctionnement out of the box !

La gestion de l'énergie est également un point fort de l'appareil. Plusieurs jours d'autonomie en veille, plusieurs heures en fonctionnement, et surtout un allumage instantané.

A contrario, sous Windows et encore plus sous Linux, la gestion de l'énergie a toujours été un problème insurmontable:

• Autonomie ne dépassant pas les 4h quel que soit le matériel.
• Charge erratique (Windows et Linux ne s'accordent pas sur la capacité et la performance de ma batterie).
• Impossibilité de prévoir l'autonomie réelle lorsque la batterie se dégrade (ce qui arrive de plus en plus rapidement).
• Modes de fonctions incompréhensibles (veille, veille hybride, hibernation) et ne fonctionnant pas toujours (selon le matériel ou le support du noyau).
• Mise en veille ne fonctionnant pas à cause d'un driver bogué.
• Allumage intempestif de la machine (par exemple pour installer des correctifs de sécurité[3]).
• Et surtout … plusieurs secondes pour sortir de veille dans tous les cas.

Dès qu'il me faut consulter rapidement un article ou un plan, je sors désormais l'iPad - je sais que j'en ai pour moins de 5 secondes et que je peux m'interrompre à tout moment sans risquer de tout perdre.

Quant aux logiciels, on trouve par exemple des jeux de qualité tout à fait correcte pour moins de 10 euros. Disponibles immédiatement et sans problèmes de protections logicielles incompatibles.

Enfin l'écran tactile est un must pour les jeunes enfants qui ne peuvent pas se servir d'un clavier et d'une souris. D'ailleurs les éditeurs ne s'y sont pas trompés et proposent de nombreuses applications pour les plus jeunes (livres interactifs, jeux, etc.). En 10 minutes, un enfant de 18 mois maitrise complètement l'interface graphique (y compris l'allumage et le déverrouillage) - il est autonome sur n'importe quel jeu (testé et approuvé).

Conclusion

En bref, l'iPad n'est pas cet engin révolutionnaire et indispensable qui vous est décrit par les fanboys ayant fait la queue pour dépenser leurs 500€ (au bas mot et hors frais d'utilisation).

Mais quand on manipule l'engin au quotidien, on réalise à quel point l'informatique "traditionnelle" s'est endormie dans un statu quo frustrant pour les utilisateurs, qui ont pris l'habitude de travailler avec des systèmes contre-intuitifs, lents et difficiles à maintenir, alors que rien ne le justifie vu l'argent injecté chaque année dans l'industrie logicielle.

C'est pourquoi je ne jetterais pas Chrome OS avec l'eau du bain comme le fait Gartner. En repensant les fondements de l'informatique (mais à quoi peut bien servir un BIOS en 2011 ?) et en s'appuyant sur les interfaces graphiques conviviales du Web 2.0, Google a une chance lui aussi de secouer le cocotier avec un produit un peu différent dans l'esprit (ne serait-ce que par son facteur de forme).

Quant aux entreprises, il leur faudra bien renoncer un jour à leurs applications VB6 et IE6, sous peine de se retrouver avec une informatique tellement dépassée que la "cloudification" massive (et tant redoutée) sera le fait des utilisateurs mécontents. Mais ceci est une autre histoire …

Billet rédigé avec Windows Live Writer 2011

---

[1] http://natisbad.org/E4300/
[2] http://natisbad.org/E4300/Dell_Wireless_5530_AT_cmd_ref.html
[3] http://www.nynaeve.net/?p=160