Discuter:E- impacts de l'innovation
Un article de Upfing.
La position d’apprenti sorcier est d’une certaine manière inévitable avec les technologies de la communication ; en raison de leur nature même. Cela ne veut pas dire qu’on doit faire n’importe quoi ; il semble exister des voies de développement plus sûres que d’autres, même si aucune ne l’est complètement.
La figure de l’apprenti sorcier est inquiétante car il fait sans vraiment savoir, il ne maîtrise pas les forces qu’il déclenche. On peut l’opposer à celle du moine studieux, qui s’instruit dans les livres et suit la règle, ou si l’on préfère un personnage plus innovant à celle de l’ingénieur qui prévoit, calcule, planifie avant de réaliser. Mais pour les TC, la méthode qui consiste à analyser le besoin, spéifier les fonctionnalités puis développer et tester ne fonctionne que de manière très limitée. L’intérêt des TC réside dans les aspects émergents et la production de valeur par l’usage collectif. Un seul téléphone est sans intérêt, un forum solitaire aussi ; on imagine mal Wikipedia ou Flicker en mono-utilisateur. Ce sont des évidences, mais ce qu’on cherche à monter avec les TC, ce sont des systèmes socio-techniques, pas des systèmes techniques. L’analyse préalable des besoins ne met pas en évidence de besoin clair, les utilisateurs sont incapables de donner des spécifications précises ; il est difficile d’imaginer les effets systémiques à large échelle. Pour voir, « faut essayer », puisque le contenu est créé par les usages, et que de fait, le contenu du service c’est les usages, et la valeur est créée par l’audience potentielle. On voit que dans ce domaine, l’innovateur est condamné à essayer, à faire sans savoir vraiment, à invoquer des forces qui dépassent son contrôle puisque, précisément, il cherche à produire des effets émergents. Le voilà donc dans la posture de l’apprenti sorcier.
Il existe cependant des manières plus ou moins risquées d’avancer par essai-erreur. En ce qui nous concerne, nous travaillons dans une entreprise qui n’a pas droit à l’erreur et porte une attention extrême à la maîtrise des risques au point que celle-ci est devenue une culture qui s’étend même aux processus non techniquement risqués. Nous avons été amenés à développer des techniques d’innovation progressive adaptées à cette culture. Pratiquement, nous pratiquons pour le développement de services à base de TIC (par exemple, la réunion à distance, le travail collaboratif synchrone, l’amélioration des postes de travail numérisés) un paradigme de « réalité expérimentale ». Cette technique a bien fonctionné jusqu’ici dans notre contexte, en produisant des innovations bien intégrées et appréciées par les utilisateurs, mais nous n’avons aucune prétention de généralité ; c’est juste un exemple.
Nous mettons en place des expérimentations en situation réelle, suivies en continu par des équips pluridisciplinaires de chercheurs et de développeurs. Les services et les devices sont améliorés en continu au fur et à mesure des demandes des utilisateurs, et des observations sur les phénomènes émergents. Nous impliquons toutes les parties prenantes (utilisateurs, acteurs de la maintenance, prescripteurs, financeurs, décideurs, management etc.). On commence par des petits groupes d’utilisateurs « amicaux », puis au fur et à mesure que le service devient de plus en plus utilisable nous élargissons le cercle des applications. L’efficacité du système repose sur l’implication active des parties prenantes à tous les stades, et pas seulement à celui d’une évaluation ; mais aussi au fait que nous travaillons en situation réelle. Ce dernier point est assez lourd ; par exemple nous avons construit un bâtiment entier équipé avec les systèmes à tester, habité par de vraies équipes qui y ont leur poste de travail, et qui par maintenu une équipe d’ingénieurs dédiés. Nous avons pour principe absolu d’être au service des utilisateurs, et de faire passer leurs intérêts de manière systématique avant tout le reste. Cela passe en particulier par une vigilance particulière sur les aspects de privacy qui sont contraignants en matière de développement
(plus d’infos sur : LAHLOU, Saadi, JEGOU, François. European Disappearing Computer Privacy Design Guidelines V1 [EDC-PG 2003]. Ambient Agoras IST-DC report D15.4. LDC, EDF. R&D, Oct. 2003. 8p http://media.informatik.rwth-aachen.de/rufae/privacy.html
Le développement de nouveaux outils de réunion à distance s’est basé sur une observation en continu pendant trois ans des expérimentateurs volontaires, et nous continuons d’entretenir une salle expérimentale qui sert à faire évoluer le système pour ensuite diffuser aux autres sites. Cette salle en libre service est utilisée par plus de 250 réunions en visioconférence par an, qui servent à valider sur des cas réels toute amélioration avant de la diffuser plus largement.
(plus de précisions dans : LAHLOU, Saadi, NOSULENKO, Valery, SAMOYLENKO, Elena. Un cadre méthodologique pour le design des environnements augmentés. Social Science Information, Vol 41, N°4, pp-471-530
LAHLOU, Saadi (2005). Cognitive Attractors and Activity-Based Design: Augmented Meeting Rooms. Human Computer Interaction International. 22-27 July . 2005, Las Vegas, NA, USA. Volume 1 - Engineering Psychology, Health and Computer System Design.)
Cette façon d’avancer à tâtons avec précaution, en adoptant une posture d’essai mais dans un environnement limité et contrôlé, peut sembler relativement lente et coûteuse. Elle amène également les développeurs à plus de modestie, et représente incontestablement une certaine perte de liberté (l’utilisateur n’a pas toujours les mêmes valeurs que le développeur, il n’accueille pas toujours les choses qu’on lui propose avec l’enthousiasme qu’elles mériteraient, il pose des problèmes inattendus, et, pire que tout, il a souvent de meilleures idées que nous). Par ailleurs, l’approche de développement graduel est problématique car elle passe mal en mode projet : on a du mal à dire à l’avance quand on atteindra un stade acceptable, et à quel coût. L’approche est donc difficile à « vendre » à des financeurs dépourvus de vision de long terme.
C’est lourd au début, mais c’est payant, et une fois que l’on a commencé à travailler de cette façon il est difficile de revenir en arrière, tant les bénéfices sont importants, sur le plan technique comme sur le plan économique.
En fait, au total cette approche permet d’économiser des frais lors du déploiement et des correction ultérieures d’effets pervers. Elle revient donc à reporter sur la phase amont du projet une partie des coûts de la phase « aval », et parallèlement à limiter les frais de déploiement et de maintenance. Dans le cas de grandes entreprise qui sont amenées à considérer dans un même budget global les dépenses de projet et celles de déploiement et maintenance, une telle politique est à la fois saine et vendable aux parties prenantes. Et même là, ce n’est pas toujours simple. Par contre, dans la nature, on voit fréquemment que ce sont des entités distinctes qui payent les projets et les déploiements. L’intérêt myope de celui qui ne paye que le développement est évidemment de minimiser ses coûts et de reporter sur l’aval les coûts. C’est ainsi que souvent c’est l’utilisateur final qui dépense des efforts indus pour suppléer aux insuffisances des systèmes qui lui sont fournis. En milieu industriel, on voit donc souvent des développements trop rapides qui engendrent des coûts cachés chez les utilisateurs.
Cela pose des problèmes économiques simples à comprendre mais durs à résoudre: les techniques de communication engendrent des externalités, certaines positives, résultant du « travail » des autres utilisateurs, d’autres négatives, résultant des nuisances des autres utilisateurs ou de la collision avec des processus existants. Les modèles d’affaires cherchent à capter les externalités positives, mais personne en particulier n’est responsable des externalités négatives. Notre approche, qui consiste à impliquer les parties prenantes dès l’amont du processus, crée en pratique une boucle de retour courte, et surtout « à temps » entre les porteurs de l’innovation et les parties prenantes qui vont en connaître les effets. Le tâtonnement consiste à modifier les caractéristiques du système au fur et à mesure qu’apparaissent les effets pour maximiser les bons et éliminer les mauvais ; sous contrôle étroit et continu des parties prenantes. Celles-ci voient émerger les effets et signalent immédiatement aux développeurs quand « ça ne va pas ».
Les principaux obstacles à cette approche sont les modes de financement et de prise de décision dans la culture actuelle de gestion de projets qui produisent parfois des effets de tunnel, où il est trop tard ou trop coûteux de modifier le système quand on voit apparaître des effets pervers. On peut espérer que la mise en place progressive d’exemples de réussite de telles approches, et d’une perspective « durable » dans la conception, qui habitue les innovateurs à intégrer étroitement les parties prenantes dès l’amont et en continu, pousseront dans le sens de cette approche de tâtonnement progressif et attentif aux effets émergents.
saadi lahlou
