Logiciel De Situation

Qu'est ce que le Logiciel de Situation ?

C'est un logiciel que l'on peut construire de façon à être adapté à son environnement, c’est-à-dire aussi bien les personnes que l'endroit ou le moment dans lequel il est utilisé.

Plus d'informations sur cet article en anglais de Clay Shirky : Situated Sofware

Traduction en cours de l'article en anglais de Clay Shirky : Situated Sofware seul lien de référence.

Première version éditée le 30 mars 2004 sur la liste de diffusion de "Networks, Economics, and Culture".
Abonnez-vous à la liste de diffusion.

J'enseigne au Programme Interactif des Télécommunications de NYU (ITP), là où la population estudiantine est à peu près également divisée entre des technologues qui se soucient de l'esthétique et d’artistes qui n'ont pas peur des machines, ce qui en fait un terrain particulièrement propice pour se projeter dans le futur.

Dans le futur auquel je crois, je vois une mutation dans l'écosystème du logiciel que, pour l'instant, j'appellerai "logiciel de situation". C'est du logiciel conçu dans et pour une situation ou un contexte social particulier. Cette manière de réaliser le logiciel contraste avec ce que j'appellerai "l'École du Web" (le paradigme avec lequel j'ai appris à programmer), où la notion d'échelle, de généralisation et de complétude étaient les vertus principales.

Je vois mes étudiants ignorer gaiement les pratiques de l’École du Web, mais produire cependant du travail intéressant, un fait qui m’a apporté une dissonance cognitive persistante pendant un an, si bien que je souhaite décrire le modèle ici, y compris à son stade primitif, pour voir si d'autres voient la même chose ailleurs.

Des groupes d'une douzaine d'utilisateurs

Il y a toujours eu un fossé entre les pratiques de conception de l’entreprise et la méthode des "petits éléments vaguement joints" de réaliser un logiciel, pour employer l'heureuse expression de David Weinberger. Les avantages de cette dernière méthode sont en partie décrits dans les articles "Le Pire est le Meilleur"#1 et dans " La Cathédrale et le Bazar" #2. Le Logiciel De Situation appartient à la catégorie des "petits éléments", avec la caractéristique additionnelle suivante -- il est conçu pour être utilisé par un groupe social spécifique, plutôt que pour un ensemble générique d’ "utilisateurs".

La plus grande différence créée entre cette catégorie et les applications classiques du web est qu'il devient facile de réaliser des applications pouvant être utilisées par des groupes d'une douzaine d’utilisateurs, une population-cible considérée comme absurde dans les habitudes actuelles de conception de logiciels. La réalisation d’un logiciel sur mesure pour un petit groupe d'utilisateurs a typiquement été l’apanage des banques et des laboratoires de recherches – et, en raison des coûts associés, les applications classiques de l’École du Web se sont concentrées sur l’obtention d’audiences de grande échelle. Et en privilégiant la valeur provenant de l’échelle, les applications de l’École du Web ont mis hors de portée d’autres formes de valeurs, notamment la valeur sociale.

Nous avons depuis si longtemps tué le sens profond des conversations à propos des logiciels en disant "on ne pourra pas les utiliser à grande échelle", et avons oublié que les problèmes d'échelle ne sont pas fatals en soi. Le problème du N au carré est seulement un problème si N est grand, et dans des situations sociales, N est généralement faible. Un groupe de lecteurs travaille mieux à 5 membres que 15 ; un séminaire fonctionne mieux avec 15 personnes que 25, beaucoup moins à 50, et ainsi de suite.

Ceci confère au logiciel sur mesure destiné à un groupe spécifique un certain nombre de caractéristiques séduisantes -- c'est moins cher et plus rapide à construire, cela réduit la problématique d’échelle et permet sans doute une meilleure prise en main par ses utilisateurs. Il présente également quelques inconvénients prévisibles, dont une moindre facilité d'utilisation hors de son contexte originel et une plus grande fragilité s'il est plus tard appelé à adresser des groupes plus importants, et une durée de vie probablement plus courte.

Je vois cependant mes étudiants opérer certains travaux relatifs à cette mutation, parce que la nature des besoins que l'École du Web était censée combler -- dépenses pour du matériel adapté, rareté des talents en programmation et distribution éparse des utilisateurs potentiels -- ne sont plus les contraintes qu'elles furent jadis.

Teachers On The Run (Les Professeurs dans la Course)

Le premier pressentiment que j’ai eu sur le fait que le raisonnement de l'École du Web pouvait être affaibli, était une application écrite par deux de mes anciens étudiants, Paul Berry et Keren Merimeh. En novembre 2002, lors d'un projet pour une classe à propos du ressenti des espaces en ligne appelés "Social Weather" (NDT Météo Sociale), ils ont créé une application appelée (d’une manière alarmante) "Teachers on the Run".

"Teachers on the Run" était essentiellement ChaudeouNon destinée aux professeurs d'ITP, pour permettre à des étudiants de décrire et de nous évaluer avant l'enregistrement des cours de printemps. Chaque professeur était recensé dans une base de données ; les étudiants pouvaient venir anonymement et soit écrire un commentaire sur un professeur ou proposer un vote à propos de l'accord ou du désaccord d'un commentaire exprimé plus tôt. Les descriptions étaient triées selon l'ordre du total des voix, de sorte qu'une description +5 (5 étudiants de plus que le nombre de désaccords) était affichée plus haut que des +2 ou des -3. Et c'était simplement ça -- une liste de noms, une liste de commentaires, un clic pour voter et un algorithme de tri simple.

Ils l'ont lancée un vendredi. Le samedi soir, un autre étudiant m'a appelé à la maison pour me dire que je ferais bien d'y jeter un oeil. Il y a environ seulement 200 étudiants à l'ITP, mais "Teachers on the Run" avait déjà accumulé des centaines de commentaires, la plupart positifs, certains négatifs, quelques-uns potentiellement calomnieux. Plus important, il y a eu plus de mille voix en 24 heures. Le lundi matin, j'avais des étudiantsqui en train de me dire qu'ils savaient ce qui figurait sur le site, pas parce qu'ils avaient vu le site, mais parce que ça avait était le seul sujet de conversation du week-end.

Ce qui me semblait curieux à propos de "Teachers on the Run" était que cela ait pu fonctionner là où la version de l'École du Web a échoué. Rate My Professors.com était disponible depuis des années, avec un jeu de fonctionnalités qui offrait les possibilités simplistes d'humiliation écriture/lecture/vote de "Teachers on The Run". Pourtant personne à ITP n'avait jamais pris la peine d'utiliser Rate My Professors.com, même si l'orgie du week-end de l'évaluation et du vote était bien la preuve d'une demande inexploitée.

En dépit de l'énergie sociale déchaînée, j'ai raté l'importance de "Teachers on the Run". Je me suis dit que l’application avait réussi pour un certain nombre de raisons vaguement injustes : les utilisateurs connaissaient les programmeurs ; les noms de la database avaient été peuplés (NDT : populated ?) à l'avance ; les programmeurs pouvaient employer la liste interne de diffusion pour lancer l'application plutôt que d'essayer de recueillir l'attention à travers des communiqués de presse et des bannières publicitaires. Et le plus infernal, elle ne pouvait pas grandir, la condition sine qua non des applications web réussies. DOA, QED. (NDT ?)

Ce ne fût qu’après-coup que je découvrais le processus de conception que ma classe la plus récente avait traversée.

La Classe

Dans une classe appelée Social Software, dans laquelle j'ai enseigné l'automne dernier, les étudiants travaillaient en petits groupes pour concevoir et lancer du logiciel destiné à maintenir quelque forme d'interaction de groupe. Pour ancrer la classe, j'ai exigé que quel que soit le projet qu'ils montaient, ce projet puisse être aussi employé par d'autres étudiants de l’ITP. Les premiers avantages de cette stratégie étaient simples : les concepteurs étaient issus de la même population que les utilisateurs et pouvaient de ce fait faire confiance à leur instinct pour valider ; les bêta-testeurs pouvaient être recrutés en marchant dans le hall ; et cela évitait aux personnes de faire des tentatives grandioses de "bouilloire océanique".

Ce que je n'avais pas anticipé étaient les avantages de deuxième ordre. Le temps et à nouveau les groupes venaient à bout des problèmes qu'ils résolvaient en partie en tirant profit de l'infrastructure sociale ou de l'information sensible au contexte qui n'auraient pas été disponibles pour les membres de l'École du Web. Deux stratégies particulières émergent.

Le premier avait à voir avec les systèmes de réputation. Un projet, "The Orderer" (conçu par Vena Chitturi, Fa-yi Chou, Rachel Fishman et Cindy Yang) était conçu pour coordonner des commandes de restaurant, chose commune lors des sessions de travail en fin de soirée. L'autre, We Be (Brandon Brown, Yoonjung Kim, Olivier Massot, Megan Phalines) était un outil pour coordonner des achats groupés de choses comme des puces ou des moteurs. Puisqu'il y avait de l'argent, une approche École du Web exigeait une certaine manière de régler la menace du non-paiement, en utilisant des choses comme le pré-paiement ou les systèmes formels de réputation.

Au lieu de cela, les étudiants ont décidé dans les deux projets que puisque tous les utilisateurs faisaient partie de la communauté d'ITP, ils faciliteraient simplement le traçage des "alertes de mort", avec la menace de diffusion publique de leurs noms. La possibilité d'être humilié devant la communauté est devenue une composante de la conception d'application, même si la communauté et l'humiliation putative restaient en dehors du cadre de l'application elle-même.

Attention Communale

L'autre stratégie devait composer avec l’attention communale. Deux autres projets, Scout (Karen Bonna, Christine Brumback, Dennis Crowley, Alex Rainert) et Co Deck (Mark Argo, Dan Melinger, Shawn Van Every, Ahmi Wolf) se sont terminés en se retrouvant situés dans la communauté d'une façon plus littérale. Le Scout indique la présence physique, en permettant à des étudiants de s'enregistrer comme étant présents quelque part sur le plancher d'ITP et en affichant cette information. Co Deck est un serveur vidéo fondé sur la communauté, serveur conçu pour permettre aux artistes vidéo de partager et commenter le travail de chacun.

Les deux groupes ont rencontré le problème classique de la notification -- obliger un utilisateur à se mettre d'accord exige d'interrompre l'activité en cours, pas forcément quelque chose du goût des utilisateurs. Des milliards ont été dépensés sur des applications de l’École du Web sur le pré-supposé que les utilisateurs mettraient un signet pour une future visite ou accepteraient avec joie des alertes par email, mais malgré quelques succès bien-médiatisés comme Schwab.com et eBay, les utilisateurs ont la plupart du temps refusé de "revenir souvent en arrière pour jeter un coup d'oeil."

Scout et Co Deck ont tous deux opté pour la même solution : ôtez la plupart de l'interface hors de l'écran du PC et migrez-la à l'intérieur d'un objet physique dans le salon, la salle de réunion/la salle à manger/"foosball emporium" (NDT) dans le centre d’ITP. Scout et Co Deck ont chacun construit des kiosques dans le salon avec des interfaces physiques au lieu d’interactions clavier/souris. Le Scout utilisait un lecteur de code à barres pour la saisie à la volée ; Co Deck a étripé un châssis de Beta Max du milieu des années 70 et y a mis une machine Linux à l'intérieur, puis a utilisé les boutons de Beta Max pour laisser l'utilisateur commander le flux vidéo. Scout et Co Deck ont tous deux des sites web où les utilisateurs peuvent saisir ou rechercher des données, mais le noyau de chacun est l'endroit dans l'espace physique qui pose l'application dans un contexte social.

Ces projets ont tous pris la devise originale du cours -- l'application doit être utile à la communauté -- et ont commencé à fonctionner avec leur corollaire -- la communauté doit être utile à l'application.

Capacités du Groupe

Nous nous appuyons constamment sur les capacités cognitives des individus dans la conception logiciel -- nous supposons qu'un utilisateur peut associer la souris avec le curseur, ou que les icônes seront instructives. Cependant, nous faisons rarement confiance aux capacités cognitives des groupes, bien que nous faisions tout le temps confiance en de telles capacités dans le vrai monde.

Durant les sessions de brainstorming, un groupe peut non seulement produire plus d'idées mais encore plus de genres d'idées que les mêmes individus travaillant isolément, et un consensus de groupe est souvent plus pertinent que l'intuition de l'individu le mieux informé dans le groupe. Les groupes en connaissent également beaucoup sur eux-mêmes. Les personnes dans les groupes de travail savent vers qui aller pour un conseil sur le design, ou qui n'est pas de confiance en cas de besoin, sans qu’il ne puisse exister quelque désignation formelle de ces rôles. Les membres des groupes sociaux savent avec à qui c'est amusant d'aller boire ou à qui vous ne devriez pas prêter d'argent (souvent la même personne) sans que cette connaissance n'ait besoin d'être définie dans une FAQ.

Le logiciel de l’École du Web ignore ce genre de savoir, parce qu'il est difficile de le rendre explicite. Sur la plupart des grandes listes de diffusion, par exemple, seule une poignée de contributions démarrent des discussions, alors que la plupart des billets ne sont simplement que des relances ; et à un niveau plus élevé, seul un petit nombre de membres postent, tandis qu'une majorité se contente de simplement reluquer. Nous avons connu ces modèles pendant des décennies, mais le logiciel de liste de diffusion n'offre toujours aucune fonctionnalité spécifique pour un démarrage comparé aux fils de discussions continus, pas plus qu'il ne traite différemment les gros contributeurs des simples reluqueurs.

Il existe cependant une autre stratégie analogue à celle de demander à l'utilisateur de reconnaître des icônes ; le concepteur peut simplement supposer que le groupe a certaines possibilités, sans devoir les récapituler dans le code. Si vous avez un dû de paiement dans un pool d’achats groupés, le logiciel peut expédier un message qui indique "Alerte de Mise à mort. Traiter l'affaire." Un vrai groupe dans le monde aura une certaine manière de prendre en main le problème, habituellement par la persuasion morale ou la menace de perdre un capital réputation, voire un ostracisme dans les cas extrêmes.

Ce n'est pas différent de ce qui se produit au quotidien dans les groupes hors-ligne, mais la solution semble erronée, selon les termes de l’École du Web, parce que ces applications web ne peuvent pas supposer qu'il existe un système tacite de réputation. En s'apppuyant sur le tissu social existant, le logiciel de situation est sûr de ne pas fonctionner à la dimension des applications de l’École du Web, mais pour la même raison, il peut fonctionner sur des voies que le logiciel de l’École du Web ne sait pas faire.

Regards Extérieurs

J'ai finalement commencé à considérer le logiciel de situation comme une stratégie pratique de développement, plutôt que comme un cas dégénéré de "véritable" développement d'applications, au moment où j'ai invité des critiques extérieures dans la classe Social Software pour une critique de mi-parcours. Toutes des personnes travaillant avec le logiciel social et la session de critiques fût vraiment valable. Cependant, deux des recommandations faites par les critiques m'ont vraiment amusé.

La première était la suggestion, faite au groupe de Co Deck, qu'ils devraient produire toutes les fonctionnalités de leur outil vidéo sur le web -- téléversement, téléchargement, commentaires et ainsi de suite. La deuxième recommandation était une exhortation au groupe de We Be à devoir regarder des sites d'achats groupés de l'École du Web comme Mercata et Mob Shop en tant que lignes de conduite pour leurs propres travaux.

C'était pour moi le moment où la dissonance cognitive est finalement devenue insupportable. Chacune de ces commentaires était a) exactement ce que j'aurais dit, avais-je été une critique extérieure dans le cours de quelqu'un d'autre, et b) évidemment faux, compte tenu du problème que les groupes respectifs attaquaient.

La suggestion concernant l'accessibilité générale web pour l'interface de Co Deck est venue sous forme de question rhétorique -- "pourquoi ne pas la rendre aussi largement accessible que possible ?" A l'École du Web, naturellement, la réponse est "Pas de raison", puisque plus d'utilisateurs est toujours synonyme d’Une Bonne Chose, mais pour Co Deck il y avait plusieurs bonnes raisons de ne pas simplement transformer leur projet en application vidéo web.

Tout d'abord, la matérialisation de l'interface, utilisant la plate-forme étripée de Beta Max, fournit un affordance communale impossible à répliquer sur le web. En second lieu, puisque Co Deck sert une communauté très soudée, la densité de communication parmi les producteurs vidéo d'ITP serait diluée par l'accessibilité générale. Troisièmement, disposer de la plate-forme vidéo dans le salon l’auto-régule ; la cohésion de la communauté la maintient en grande partie exempte d'abus, alors qu'un site web vidéo accessible à tous et sans mot de passe deviendrait un cloaque de vices porno durant des heures. En conclusion, servir une communauté locale maximise l'utilisation de la bande passante disponible sur le réseau local, permettant des fonctionnalités qui mettraient en selle un système public avec des coûts figés.

We Be Petit

De même, la recommandation que We Be devait regarder Mercata et Mob Shop sous-tendait la prétention d'un objectif futur de fonctionnement à plus grande échelle. Cependant, Mercata et Mob Shop ont échoué parce qu'ils ont été construits pour croître sur une grande échelle.

Ces deux sites exigeaient un cercle vertueux, où plus d'utilisateurs signifiait plus d'économies qui signifiaient plus d'utilisateurs. De ce fait, la pensée que quelque part, quelqu'un d'autre économisait sur un lot de Tupperware n'était jamais suffisante pour attirer des utilisateurs, et sans masse critique, le cercle vertueux devenait vicieux. Comme pour Rate My Professors.com, la simple existence d'une application de l'École du Web ne suffisait pas, et le fait d'avoir été construite pour des dizaines de milliers d'utilisateurs, ce ne pouvait pas fonctionner pour des douzaines ou même des centaines.

We Be, d'autre part, était en train de copier un modèle de conception pour une petite échelle, modèle observé la première fois au moment où un étudiant collègue, Scott Fitzgerald, a orchestré un achat groupé discount de 30 licences de Max, le logiciel multimédia d'édition. Il a utilisé la liste de diffusion d'ITP pour recruter des acheteurs et a ensuite flâné aux alentours tordant des bras et rassemblant des chèques. Ceci exigeait un vrai tissu social pour fonctionner -- tout le monde connaissait et faisait confiance à Scott.

En tant qu'instigateur, Scott a également tiré profit d'un bon karma -- quiconque participait économisait beaucoup d'argent, augmentant sa réputation. À la différence du capital réel, il est plus facile d'accumuler du capital réputation dans des systèmes sociaux plus petits et plus fermés. L'idée pour We Be a germé en partie parce que Scott disait que son achat, bien que réussi, avait exigé trop de travail. Quelle qu'ait pu être l’action du groupe We Be pour faciliter des achats de groupe d'ITP, ils n'ont pas eu besoin d'établir des systèmes d'identité ou de réputation. Parce que le logiciel était situé dans une communauté particulière (et particulièrement soudée), ils ont disposé gratuitement de ces systèmes.

Les Vieilles Pénuries Se Fanent Au Loin

Là où l'École du Web fonctionne bien, elle fonctionne parce que c'est le bon type de réponse à une certaine forme de pénurie. Il y a une pénurie de fonds : les serveurs sont chers, pour ne pas mentionner les routeurs équilibrés en charge, les sauvegardes sur bande et autres équipements pour un fonctionnement sérieux. Il y a pénurie de talents : il est difficile de trouver de bons programmeurs ; les grands programmeurs sont rares comme le sont les dents de la poule. Et il y a pénurie d'utilisation : les utilisateurs sont occupés, ils sont des créatures de l’habitude et il y a une concurrence significative pour leur tirer une part d'attention.

Cependant, le fait d'aborder ces pénuries peut donner à l'École du Web une forme de qualité du manège. Vous avez besoin de dimensionner parce que construire une application web utile est si cher, mais la plus grande partie des dépenses provient des exigences d’échelle de dimensionnement. En outre, ces pénuries en amplifient une autre : vous avez besoin d'un gros budget de matériels pour construire une application qui puisse croître, mais vous avez besoin de bons programmeurs et d'administrateurs systèmes pour tenir la charge, dont les salaires exigent un budget croissant de marketing, afin d'attirer suffisamment d'utilisateurs pour payer l'ensemble.

Ce que je pense est que je vois en ce moment mes étudiants sortir de ce tour. Ils peuvent faire ainsi parce qu'aucune des pénuries abordées par l'École du Web n'est aussi significative qu'elles ne l'étaient auparavant. Tout d'abord, la loi de Moore et son équivalent pour le stockage, couplée à l'amélioration progressive des systèmes d'exploitation, signifie qu'une machine de bureau à $800 peut également se montrer comme un très bon serveur dès la sortie de sa boîte.

En second lieu, l'attention de l'utilisateur était rare en partie parce qu'il y avait trop peu d'utilisateurs. Dans les années 90, le lancement d'une application sur le Web signifiait renoncer à tout raccordement en direct avec une vraie communauté dans le monde réel, parce que les utilisateurs d’internet étaient essaimés et en dehors des industries des TI, la plupart des groupes dans la vraie vie disposait seulement d'un sous-ensemble de membres en ligne.

Ces jours se terminent, et à certains endroits c'est désormais terminé. Aux USA aujourd'hui, si vous avez moins de 35 ans ou gagnez plus de 35.000 dollars par an, vous êtes probablement en ligne, et si ces deux choses sont vraies, alors la majeure partie des personnes que vous connaissez sont toutes aussi probablement en ligne. Vous pouvez maintenant lancer une application destinée à un vrai groupe dans la vraie vie, en étant confiant sur le fait que tous auront accès à l'Internet.

La Nature de la Programmation, et le Cas Curieux de MySQL

En conclusion, la pratique de la programmation est en train de changer. Gartner a récemment provoqué une agitation en disant qu'il y aurait moins de 235.000 programmeurs aux USA d'ici dix ans. C'aurait été comme prédire dans les années 80 qu'il y aurait moins de dactylos aux USA d'ici 2004. Une telle prévision serait vraie dans un sens -- le pool dactylographique a disparu, et beaucoup de travail de saisie de données s'est externalisé outre-mer. Mais la dactylographie réelle, des doigts frappant le clavier, n'a pas disparu, elle s'est épanchée partout.

Il en est de même avec la programmation ; bien que toute l'attention aille vers l'externalisation, il y a également beaucoup de "downsourcing", le mouvement de la programmation allant de la description de poste jusqu'à une compétence plus largement pratiquée. Si par programmeur nous entendons les "personnes qui écrivent le code" au lieu de dire des "personnes qui sont payées pour écrire le code", d'ici 2015 le nombre de programmeurs va grimper, bien que beaucoup de gens qui utilisent Perl, Javascript et Flash ne se considèrent pas eux-mêmes comme programmeurs.

Une variété de technologies amène ceci -- Perl, PHP, Action Script?, DHTML -- avec beaucoup de mixages et d'assortiments et pas un outil central, avec une exception curieuse. Chaque application de ce modèle de conception que j'ai vue a utilisé une base de données de MySQL.

Il y a une analogie ici avec le logiciel de serveur web. Au milieu des années 90, faire tourner un serveur web représentait un tel effort que c'était déjà en soi un objectif. Puis Apache est arrivé et a ainsi simplifié le processus de telle manière que le serveur web est devenu un module simple de construction pour faire de plus grandes choses.

MySQL fait cela pour des bases de données. Ceci concerne le développement des applications de groupe, parce que la capacité de trier est un bien public. Si "Teachers On The Run" avait simplement été une liste de professeurs avec des commentaires joints, ç'aurait été une application en lecture-seule, comme ces formulaires de commentaires sans valeur "Dites-nous ce que vous pensez !" disposés au bas des articles de nouvelles. Une des choses critiques que n'importe quel groupe veut savoir est "Que pensent les Autres ?", tout particulièrement s'il y a raison de croire que le groupe en agrégat en connaît plus que l'individu. Le fait d'ajouter le système 'd'évaluation des commentaires utilisateurs' et d'extraire les données par l'évaluation au lieu du temps, a rendu ce système valable.

Vous pouvez naturellement construire ces types de fonctionnalités de bien d'autres manières, mais MySQL a vraiment facilité la tâche, en fait tellement facilité qu'après MySQL, ce devient une forme différente de tâche. Il y a des arguments techniques compliqués pour et contre l'usage de MySQL vs d'autres bases de données, mais désormais aucun de ces arguments n'importe plus désormais. Quelle que soit la raison, MySQL semble être un outil de noyau pour cette collecte particulière des nouvelles applications.

Logiciel pour votre Maman

Le logiciel de situation n'est pas plus une stratégie technologique qu'une attitude à propos de la proximité d'ajustement du logiciel à son groupe d'utilisateurs, et c'est un refus de faire face au dimensionnement, à la généralité ou à la perfection en tant que vertus sans réserves. Vue sous cet angle, la hantise avec la personnalisation de l'École du Web est une apologie de la vérité évidente -- la plupart des applications web sont impersonnelles par leur design, parce qu'elles sont construites pour un utilisateur générique. Permettre à l'utilisateur d'adapter l'interface d'un site Web pourrait le rendre plus utile, mais cela ne le rend pas plus personnel que le distributeur de billets affichant votre nom sur l'écran au moment de cracher votre argent.

Le logiciel de situation, en revanche, n'a pas besoin d'être personnalisé -- il est personnel dès son commencement. "Teachers On The Run" a fonctionné de cette façon. Tout le monde savait que Paul et Keren l'avaient construit. Vous pouviez seulement évaluer Clay, Marianne et Tom ainsi que les autres professeurs d'ITP. Vous ne saviez même pas qu'il avait existé à moins que vous n'ayez été inscrit sur la liste de diffusion d'ITP. Tant le manque de généralité ou de perfection de l'application, en d'autres termes, avoir communiqué quelque chose du type -- "nous avons construit ceci pour vous" -- que la façade impersonnelle de Rate My Professors.com n'a pas et ne peut pas simuler.

Un des mes étudiants mentionnait avoir construit une application web pour sa mère, une professeur d'école, pour conserver une trace de sa classe. Si vous vous retrouvez à travailler seul, non payé, et sur votre temps personnel, il n'y a pas moyen pour que vous puissiez construire une application qui puisse satisfaire les besoins généraux et exhaustifs des professeurs partout dans le monde. Vous pouvez néanmoins en produire une pour votre mère.

Les petites applications construites sur demande ont toujours existé, bien sûr -- apprendre le Basic était un rite de passage pour les propriétaires de PC, et les institutions croqueuses de données comme les banques d'investissement et laboratoires de recherche écrivent des logiciels pour des petits groupes d'utilisateurs. Maintenant, la combinaison de bons outils, des utilisateurs talentueux et l'internet comme étape sociale simplifient la construction de tels logiciels, améliorent la qualité du résultat, et la livraison aux utilisateurs est aussi simple que de cliquer sur un lien. Le centre de conception d'une douzaine d'utilisateurs, si difficile à servir dans le passé, peut devenir une pratique normale.

Et Après ?

Aussi que se passe t'il ensuite ? Si ce que je vois n'est pas transitoire ou limité à un jeu étroit de situations, alors nous verrons une émergence de ces petites applications-formulaires sur mesure. Ceci aura des revers évidents, y compris le fait de souder les développeurs de telles applications vers des rôles de support de communautés et réduisant la durée de vie utile des logiciels construits de cette façon.

Même si les espérances de longévité sont la version temporelle de l’échelle -- nous supposons que les applications devraient fonctionner pendant de longues périodes en partie parce que cela coûte tellement de les créer. Une fois qu’il est devenu bon marché et facile d’assembler une application, le raisonnement faiblit. Les entreprises demandent par habitude à des équipes de personnes bien payées de mettre des centaines d'heures de travail pour créer une plate-forme simple de bureau Power Point qui sera regardée dans une simple réunion. L'idée que le logiciel devrait être construit par beaucoup d'utilisateurs, ou dure pendant beaucoup d’années, est une prétention culturelle non exigée par le logiciel lui-même.

En effet, la conséquence est que la plupart des logiciels construits pour un grand nombre d'utilisateurs ou conçus pour durer échouent indéfiniment sur ces deux buts. Le logiciel de situation est une manière de dire "La plupart des logiciels obtiennent seulement quelques utilisateurs durant une courte période ; pourquoi ne pas tirer profit de concevoir en gardant cela en tête ?"

Étrangement, ceci est une forme de progrès, pas parce que le logiciel de situation remplacera d'autres types d'applications, mais parce qu’il ne le fera pas la plupart du temps. De toute la valeur que nous extrayons de l'écosystème courant du logiciel, n’est pas comprise le fait d’obtenir une application construite pour une poignée d'utilisateurs à utiliser pendant quelques mois. Bien que je pense désormais que nous commençons à voir une nouvelle niche de logiciel, niche où les communautés obtiennent des outils-formulaires et adaptés afin de servir des besoins très particuliers, des outils qui échouent à la plupart des précédents essais de qualité ou succès de conception, mais qui néanmoins fonctionnent bien, parce qu'ils sont si bien situés dans la communauté qui les utilise.

Merci à Shawn Van Every pour les commentaires de valeur inestimable de cette première ébauche d’article.

Notes de bas de page:

1 Regarder s'il existe un lien officiel vers une version francophone de "Worse is Better" ?

2 Lien vers vers une version francophone de "La Cathédrale Et Le Bazar" ?

Contexte

Ludovic Dubost a été le premier à définir le Logiciel De Situation ci-dessus et à positionner Wiki Comme Un Logiciel De Situation. L'autorisation de publication de l'article mentionné est en cours et a été effectuée par Olivier Seres. La Traduction Collaborative Sur Crao Wiki avancera ici au fil de l'eau pour un mode "vérification/relecture/récriture" : tous les relecteurs/traducteurs sont les bienvenus pour finir cette Traduction En Cours.

Deux discussion ont migré :

Traduction En Cours Category Traduction Collaborative

Dernière modification le dimanche 14 novembre 2004 23:44:18

Éditer HistoriqueDeLaPage Diff  InfosSurLaPage