06.10.2026 · Signal Titans Editorial

Le mot « wiki » vient d’une navette d’aéroport. Ward Cunningham en a fait une nouvelle façon d’écrire.

Ward Cunningham à côté du Wiki Wiki Shuttle et d’une représentation d’une page WikiWikiWeb modifiable.

Le mot « wiki » est entré dans l’informatique parce que Ward Cunningham a un jour pris une navette à l’aéroport d’Honolulu.

Le bus s’appelait Wiki Wiki Shuttle.

« Wiki » signifiait rapide.

Le mot resta dans la tête de Cunningham.

Des années plus tard, lorsqu’il construisit un nouveau type de site collaboratif, il aurait pu l’appeler quelque chose de douloureusement littéral comme QuickWeb.

À la place, il l’appela WikiWikiWeb.

Un mot étrange entendu dans un aéroport finit par donner son nom à toute une manière d’écrire ensemble sur Internet.

Le Web était devenu plus facile à lire qu’à écrire

La vision initiale du Web était collaborative.

Les utilisateurs ne devaient pas seulement lire des documents.

Ils devaient aussi les créer, les relier et les améliorer.

Mais à mesure que les navigateurs se répandaient, publier une page restait beaucoup plus difficile que la lire.

Il fallait des fichiers.

Du HTML.

Un accès au serveur.

Une certaine compréhension de l’organisation du site.

Cunningham travaillait avec des communautés de programmeurs qui voulaient partager des software design patterns — des descriptions pratiques de problèmes récurrents et de leurs solutions.

Le savoir était collectif.

Le processus de publication ne l’était pas.

Il voulait que l’édition devienne presque réflexe

Cunningham avait déjà expérimenté des systèmes d’information reliée avant le Web, notamment avec HyperCard.

Au milieu des années 1990, il gérait le Portland Pattern Repository, un lieu où les programmeurs partageaient des idées sur les patterns, projets et personnes.

Sa question était simple :

Et si les visiteurs pouvaient modifier la page eux-mêmes ?

Pas de workflow de publication séparé.

Pas besoin d’envoyer une correction à un administrateur.

Pas besoin d’attendre quelqu’un d’autre.

Ouvrir la page.

Modifier.

Enregistrer.

La frontière entre lecteur et auteur devenait presque invisible.

Le 25 mars 1995, WikiWikiWeb est mis en ligne

Le premier WikiWikiWeb fut lancé sur c2.com dans le cadre du Portland Pattern Repository.

Son design était volontairement simple.

Les pages pouvaient être modifiées dans le navigateur.

De nouvelles pages pouvaient être créées rapidement.

Certains noms de page pouvaient automatiquement devenir des liens.

Recent Changes permettait de voir ce que la communauté venait de modifier.

Le système n’avait pas besoin d’une hiérarchie complexe conçue entièrement à l’avance.

La structure pouvait émerger pendant que les gens écrivaient et reliaient des idées.

C’était le changement essentiel.

Le site n’était plus seulement une publication terminée.

Il devenait un espace de travail partagé.

Le nom parlait de vitesse, pas de connaissance

Cunningham apprit le mot « wiki » lors d’un voyage à Hawaï.

À l’aéroport d’Honolulu, on lui indiqua le Wiki Wiki Shuttle.

L’expression lui resta en mémoire parce qu’elle était inhabituelle et qu’elle capturait exactement le sentiment qu’il voulait donner à son logiciel.

Rapide.

Immédiat.

Avec peu de friction.

Il aimait aussi l’allitération de WikiWikiWeb avec World Wide Web.

Le script Unix lui-même s’appelait simplement wiki.

Avec le temps, le nom court devint le terme générique.

Aujourd’hui, des millions de personnes connaissent le mot sans connaître le bus qui l’a fait entrer dans l’informatique.

La vraie invention était de réduire le coût de la contribution

Un système de publication classique pose une question importante :

Qui a le droit de modifier cette page ?

Un wiki pose une autre question :

À quelle vitesse une amélioration utile peut-elle devenir partie intégrante de la page ?

Cela ne signifie pas que tous les wikis doivent être totalement ouverts ou anonymes.

Les systèmes modernes ajoutent permissions, modération, historique et review selon les besoins.

Mais Cunningham a changé l’hypothèse par défaut.

Éditer n’était plus un événement administratif spécial.

Éditer devenait une extension naturelle de la lecture.

C’est pourquoi les wikis ont changé bien plus que les encyclopédies

Wikipedia devint plus tard l’usage le plus célèbre de l’idée.

Mais les wikis se répandirent dans les équipes logiciel, les organisations d’ingénierie, la documentation, les bases de connaissance internes, les communautés de fans et les groupes de projet.

Le modèle est particulièrement fort là où le savoir change continuellement.

Un document statique commence à vieillir dès qu’il est publié.

Une page partagée et modifiable peut évoluer avec le travail.

Un wiki ressemble alors moins à un livre qu’à une mémoire collective.

La collaboration échoue souvent parce que contribuer coûte trop cher

Les organisations disent souvent vouloir partager la connaissance.

Puis elles ajoutent cinq étapes entre le moment où quelqu’un repère un problème et celui où la documentation est corrigée.

Ouvrir un ticket.

Trouver le propriétaire du document.

Demander l’accès.

Attendre la review.

Attendre la publication.

À ce moment-là, la personne qui avait vu le problème est déjà passée à autre chose.

Le wiki de Cunningham faisait un pari différent :

Si la bonne personne est déjà au contact de la connaissance, laissez-la l’améliorer tant qu’elle s’en soucie encore.

Le même principe vit toujours dans les produits modernes

Les bons outils collaboratifs raccourcissent la distance entre remarquer quelque chose et contribuer.

GitHub peut transformer une correction documentaire en pull request.

Google Docs a normalisé commentaires et édition en direct.

Notion et des outils similaires permettent aux équipes de remodeler leur savoir sans appeler un webmaster.

L’interface change.

Le principe reste très proche de WikiWikiWeb :

Rendez la contribution assez peu coûteuse pour que les gens la fassent réellement.

Parfois, la fonction n’est pas le contenu. C’est la permission de le modifier.

Ward Cunningham n’a pas inventé la connaissance collaborative.

Les humains la construisent ensemble depuis des millénaires.

Ce qu’il a changé, c’est la friction de cette collaboration sur le Web.

Un lecteur pouvait devenir auteur en quelques secondes.

Une page pouvait donner naissance à une autre par un lien.

Une communauté pouvait construire sa structure pendant l’usage au lieu de tout concevoir à l’avance.

Et un mot étrange retenu d’une navette d’aéroport devint le label de tout ce modèle.

Où, dans votre produit, les utilisateurs sont-ils déjà assez proches du problème pour le corriger eux-mêmes, mais le workflow les oblige-t-il encore à attendre quelqu’un d’autre ?