L’âge du péta-octet…

Mon fils de bientôt cinq ans, qui, comme beaucoup de ses semblables, n’est pas chiche d’hyperboles, m’a demandé pendant l’été ce qu’il y a après « méga » (parce que mieux que superbien, c’est mégabien), puis ce qu’il y a après « giga »… Lorsque, quelques jours plus tard, il m’a demandé ce qu’il y a après « téra », je dois avouer que j’ai séché et ce n’est qu’après une recherche sur le web que j’ai pu lui répondre « péta » (mais en tant que parent responsable, j’ai néanmoins pris la peine de lui expliquer que le terme « pétabien » risquait de ne pas être intelligible pour tous).

Aussi ai-je particulièrement prêté l’oreille (devrais-je dire l’oeil ?) quand j’ai découvert, par l’intermédiaire d’Olivier Ertzscheid, l’article de Chris Anderson traitant de l’impact de l’Age du Pétaoctet sur la méthode scientifique. Depuis, Hubert Guillaud a écrit un article de synthèse très intéressant sur la fin de la science, dans lequel il évoque cet article : Est-ce que le déluge de données va rendre la méthode scientifique obsolète ?. Mais ce n’est pas de cet impact sur la science que je veux parler ici ; cet article m’a inspiré quelques réflexions, qui rencontrent des préoccupations que j’ai depuis longtemps.

D’abord cette idée d’un déluge de données dans lequel des logiciels pourraient trouver un sens automatiquement (l’exemple le plus saisissant est celui de la traduction : « à corpus de données égal, Google peut traduire du klingon en persan aussi facilement qu’il peut traduire du français en allemand », dit Anderson) me semble mettre en évidence une tendance importante et durable de l’internet actuel : la domination d’un système fonctionnant avec des données peu structurées, au détriment d’un système plus rigoureux et plus structuré. En somme, il s’agit d’une victoire du web 2.0 (ou 3.0, je ne compte plus) sur le web sémantique. C’est ce principe qui s’applique pour le moteur de recherche de Google ou les sites de signets collaboratifs comme del.icio.us : on ne demande pas au fournisseur de contenu (pages web ou liens dans ces exemples) de faire une description exhaustive de son contenu ; à la rigueur, on lui demande quelques mots clés (tags), mais cela ne va guère au-delà. Il me semble que cette tendance se confirme d’une façon très nette et que la mise en place d’un formalisme imposant de taxinomies et d’ontologies qu’on nous promet parfois n’aura pas lieu, en tout cas pas dans les dix ans qui viennent. A la place, le web continuera à être une sorte de vrac dans lequel les ordinateurs devront se débrouiller pour trouver un sens (quel qu’il soit), et non un objet bien propre spécialement fabriqué pour qu’ils le comprennent.

A cet égard, le billet de Jean Véronis sur la nouvelle fonctionnalité de Google de détection de pièce jointes oubliées, dans lequel il explique la méthode qu’il utiliserait pour implémenter cette fonction est un témoignage éloquent. Cette méthode donne véritablement le vertige : il s’agit d’ « extraire à l’aide d’outils statistiques les n-grammes qui apparaissent fréquemment dans les mails avec attachement et pas dans les mails sans attachement », puis « pour chaque nouveau mail, regarder si un de ces n-grammes magiques est présent dans le texte, et si oui déclencher une alerte ».

D’ailleurs, je crois que l’époque est au refus d’un formalisme excessif. Le succès d’une méthode comme GTD n’est sans doute pas étranger à ce refus : un projet, tel que le décrit David Allen, n’est pas un ensemble complexe de systèmes et de sous-systèmes, qui peut être représenté de diverses façons (diagramme de Gantt, de PERT…) ; c’est plutôt un ensemble d’actions qui peut être consigné sur le dos d’une enveloppe et dont la représentation essentielle est la Next action, c’est-à-dire « Et maintenant qu’est-ce qu’on fait ? »

En somme, le principe directeur, connu depuis toujours, est que « le Mieux est l’ennemi du Bien » et plutôt que d’avoir un modèle qui prévoit tout, il vaut mieux avoir un modèle facile à adapter quand on aura besoin de lui faire faire quelque chose d’imprévu… Les méthodes de programmation dites « agiles » ne reposent pas sur autre chose.

Mais aussi cette situation a un impact sur l’informatique en général : d’abord parce qu’elle peut contribuer à populariser l’idée qu’un ordinateur doit travailler à la place d’un humain et non lui donner du travail… Truisme… mais qui ne paraît pas si évident pour tous nos semblables : l’ami qui m’a dit il y a quelques années « Pourquoi as-tu 2 (ou 3 ou 6…) ordinateurs, tu ne peux pas être assis devant tous en même temps ? », sans savoir qu’un bon ordinateur est précisément celui que j’utilise sans être assis devant lui, ou bien ceux qui ne veulent pas utiliser l’informatique parce qu’ils n’ont pas le temps…

Je crois que cette tendance a aussi une conséquence sur le métier d’informaticien. En effet, de nos jours, il est possible de programmer facilement, sans avoir de compétences théoriques importantes. C’est un raisonnement que je me fais depuis longtemps à mon propre sujet : je passe une partie importante de mon temps de travail à écrire du code et pourtant, je n’ai jamais étudié l’informatique et je n’ai pas de connaissances approfondies en algorithmique. Un exemple parmi beaucoup d’autres : tout ce que j’ai pu apprendre sur les algorithmes de tri (que je n’ai appris que par curiosité et jamais par besoin) ne m’a jamais été directement utile, parce que toutes les fois où j’ai eu à trier des données, il était plus simple et plus efficace d’utiliser une fonction native ou fournie par une bibliothèque du langage que j’utilisais (le plus souvent python).

J’ai longtemps pensé que cette approche était caractéristique d’un autodidacte de la programmation, professeur de lettres de formation, mais j’ai constaté au contact de ‘vrais’ informaticiens, ou de stagiaires qui finissaient des études (de type BTS ou DUT) en programmation que beaucoup n’ont pas de notions théoriques plus approfondies et que ces connaissances ne sont guère utiles dans la pratique quotidienne de beaucoup de programmeurs.

Or l’âge du péta-octet exige une vraie réflexion sur les algorithmes : le volume gigantesque de données nécessite des traitements optimisés pour être réalisables dans des conditions acceptables, les opérations à mettre en oeuvre impliquent des notions sur les statistiques que tous ne possèdent pas. La conséquence de cela va être l’élargissement du fossé entre l’élite des programmeurs, très compétents, détenteurs de connaissances très pointues dans des disciplines scientifiques, et la piétaille des scripteurs, qui sera de moins en moins distincte des power users, de plus en plus nombreuse. Bien sûr, cette fracture existe déjà, mais il y a fort à parier qu’elle va aller en s’accentuant.