4.1 Description du cas

4.1.1 Profil de l'entreprise

La compagnie étudiée est un leader mondial d'équipements de télécommunication et de services reliés au mobile et un opérateur international de réseaux fixes. Avec plus de 1000 réseaux dans plus de 175 pays, 40% de tous les appels de mobiles sont faits au travers de leurs systèmes. Notre recherche s'est faite au sein de la filiale canadienne deuxième centre de R&D du groupe avec plus de 1600 employés et un investissement sur 10 ans de plus de 2 milliards de dollars.
L'organisation possède son propre modèle de gestion de projet qui a pour objectif de supporter une gestion de projet orientée affaires, efficace et performante dans un environnement multiprojet. Ceci permet un travail plus flexible et une rapidité d'exécution par le renforcement du pouvoir de décision accordé aux membres des équipes projet assurant ainsi un ajustement permanent avec les besoins des clients. C'est la complexité potentielle des projets d'une compagnie d'une telle ampleur et ses capacités d'innovation qui nous ont motivé à en faire notre terrain d'étude.

4.1.2 Nature et origine du projet

Notre recherche porte sur un wiki expérimental ayant servi d'outil de collaboration pour la phase 3 d'un projet que nous appellerons "Alpha". L'objectif premier du projet était le développement d'une infrastructure interne de test logiciel qui fonctionnerait sept jours sur sept et vingt-quatre heures par jour. L'objectif second de la phase 3 était d'utiliser à titre expérimental un wiki.
Cette phase 3 contenait 6 composantes, 4 développées au Canada et 2 développées en Espagne par une quinzaine d'informaticiens. Chaque composante avait un leader et l'ensemble des composantes était géré par un chef architecte (architecture informatique) basé au Canada.
Cette phase 3 venait compléter directement les phases 1 et 2 développées précédemment. Nous n'avons pas étudié ces premières phases si ce n'est de constater leur connexion à la phase 3 à partir des liens présents sur le wiki.

Tableau 4.1: Le projet en chiffres

Budget de la phase 3	1,2M$CAD
Équipe projet canadienne	16 personnes
Membres de la direction impliqués	8
Pays impliqués	3
Durée	5 mois

4.1.3 Chronologie

Une ligne de temps présentée ci-dessous reprend les dates les plus importantes relatives au projet wiki sur le terrain voir figure 4.1.

Figure 4.1: Dates clés

4.1.4 Modélisation des outils en présence

À notre arrivée sur le terrain nous avons procédé à un état des lieux afin de visualiser les différents outils utilisés par l'équipe. Nos observations ont été consignées sur une page wiki appelée "État des lieux".
À partir des informations collectées, auprès des employés et sur l'Intranet de la compagnie, nous avons modélisé ci-dessous une liste non exhaustive des plateformes, applications, base de données et moyens de communication qui ont été utilisés par le panel de participants. Afin de faciliter la rédaction et pour des raisons de confidentialité, nous avons remplacé les noms d'origines des outils par des acronymes fictifs voir figure 4.2.

Figure 4.2: Modélisation des outils utilisés par l'équipe projet

4.1.5 Parties prenantes

La notion de parties prenantes est apparue pour la première fois en 1984 dans un article de R. Edward Freeman. Il définissait alors les parties prenantes comme "Tout groupe ou individu qui peut affecter ou est affecté par la réalisation des objectifs de l'entreprise" (Freedman 1984 p.25).

Pour tenter de modéliser le plus fidèlement possible la complexité des interactions entre les parties en présence, nous avons utilisé l'approche systémique de Bériot au travers de la modélisation synchronique. (Bériot 2006 p.109 à 119). "La modélisation synchronique, consiste à obtenir une photographie, à un instant donné, du poids des acteurs et de leurs relations." (Bériot 2006 p.110). Même s'il est impossible de donner une image parfaite du système observé, on peut s'en approcher le plus possible pour permettre au gestionnaire et de mieux s'orienter et d'atteindre ses objectifs.

Pour Bériot, la modélisation synchronique permet d'atteindre un ou plusieurs buts, un ajustement, une auto-clarification, une décision, une action, une aide pédagogique. Elle représente les acteurs, leur position par rapport à l'objectif n+1, leur pouvoir d'influence et la nature de leurs relations. Aux fins du projet, cette modélisation nous a permis de visualiser les pouvoirs et les intérêts des acteurs, la nature de leurs relations et leur position par rapport à l'objectif, voir figure 4.3.

Figure 4.3: Modélisation synchronique des parties prenantes

4.1.6 Structure du wiki

Une fois l'engin wiki sélectionné et installé sur un serveur de l'organisation, une équipe réduite composée du chef architecte et d'un intégrateur système aussi leader d'une des 6 composantes a défini la structure de départ du wiki. Nous avons participé à cette étape pour définir la trame sur laquelle l'équipe projet allait démarrer. La nature du wiki étant, cette structure demeure très flexible et pourra être modifiée ultérieurement par les membres de l'équipe.

On trouve dans la figure 4.4 les éléments du projet matérialisé par des pages wiki toutes reliées entre elles. Sont ainsi représentés: le projet composé des itérations, de la chronologie, et des réunions; l'équipe et sa base de connaissances et enfin, le produit avec ses cas utilisateurs, ses composants, son design, sa documentation, ses versions et ses bogues. Nous soulignons que les flèches représentent des hyperliens pointant d'une page à une autre et non des flux d'information.

Figure 4.4: Modélisation de la structure de départ du wiki

4.2 Analyse des données

Baccarini définit la complexité de projet comme plusieurs parties diversifiées, inter-reliées et que l'on peut opérationnaliser en terme de différenciation (nombre d'éléments) et d'interdépendances (entre éléments) (Baccarini 1996). Williams ajoute à la différenciation et l'interdépendance regroupées sous le nom de complexité structurelle, l'instabilité des suppositions sur lesquelles les tâches sont basées soit la notion d'incertitude qu'il reprend de Jones (1993) (Williams 1999). Morin résume le tout en disant que la complexité se caractérise par "un tissu de constituants hétérogènes inséparablement associés" (Morin 2005 p. 21). Si nous regardons le tissu de constituants du projet soit: les divers outils utilisés par l'équipe (figure 4.2), les parties prenantes au projet géographiquement dispersées dont les cultures différent (figure 4.3) et leurs rôles respectifs (par exemple, certaines parties prenantes réalisent, d'autres supervisent des tâches, constitutives de diverses itérations, donnant forme à 6 composantes, faisant elles-mêmes partie d'une phase 3, qui en s'intégrant aux phases 1 et 2 constituent le projet qui lui enfin s'intègre dans la stratégie globale de l'organisation), force est de constater que le projet est complexe. D'autant plus que ses constituants hétérogènes" sont "inséparablement associés"'', c'est à dire qu'ils ont des effets rétroactifs et récursifs les uns par rapport aux autres, la nature des interdépendances influençant le niveau de complexité (Thompson, 1967). Celle-ci, transparaît dans la structure de base donnée au wiki au début de la phase 3 (figure 4.4). On y voit notamment les interrelations entre les parties du projet et celles du produit final qui sera livré aux utilisateurs. Enfin, la structure organisationnelle de type matricielle forte (Hobbs et Ménard, 1991) est elle même source de complexité confrontant les intérêts et les pouvoirs provenant de divers départements fonctionnels (ressources humaines, finance, informatique, recherche et développement etc...), à ceux de la branche projet et du siège social.

Les données collectées durant les cinq mois passés sur le terrain, nous ont permis de tirer des constats et de les analyser pour nous permettre de légitimer notre modélisation. Constats et analyses sont présentés ci-dessous à trois instants: avant l'utilisation du wiki, pendant l'utilisation du wiki et en fin de projet de recherche.

4.2.1 Avant l'utilisation du wiki

4.2.1.1 Constats

La disparité des outils entraine une réutilisation de contenu

Nous avons observé à quel point les outils de gestion, diffèrent d'une personne à l'autre, ce qui est d'autant plus surprenant pour des personnes qui travaillent sur un même projet. Dans certains cas, cela s'explique par la nature du travail à effectuer, par exemple un développeur va stocker du code sur une base de données conçue pour recevoir des lignes de codes, alors qu'une responsable administrative va stocker ses documents texte sur une base de données documentaire. Mais parfois ces personnes effectuent des tâches sur différentes plateformes alors qu'une seule pourrait répondre à leurs divers besoins. L'observation sur le terrain (information tirée du journal de bord) montre que plusieurs ne savent pas réellement avec quels outils leurs confrères travaillent. Les liens se font par courriel, messagerie instantanée ou appel téléphonique. Chaque contributeur privilégie les outils en fonction de ses besoins et de ses compétences. Ainsi, une rédactrice de guides utilisateurs, évoquant le logiciel de rédaction documentaire (LRD) nous a dit "quand je reçois les documents des designers, s'ils n'ont pas utilisé cet outil; la plupart le détestent; ils vont m'envoyer des documents Word et l'information que j'amasse, je la transforme" (traduit de l'anglais de l'entrevue n.8). Ceci illustre comment deux personnes manipulent inutilement le même contenu parce qu'elles utilisent des outils différents. Même certaines applications clés dans l'organisation sont parfois boudées. Ainsi, un intégrateur système à qui l'on a demandé s'il utilisait la plateforme de collaboration projets internes (PCPI), a répondu "Non, probablement que ça existe, mais personnellement je ne l'utilise pas" (entrevue n.2). L'organisation elle même, dans une présentation intitulée "Stratégie de collaboration 2007-2012" souligne la nécessaire "intégration entre processus vers l'excellence" et "l'élimination des tâches répétitives dues à une piètre collaboration ou une réutilisation" (Traduit de l'anglais). La disparité des outils avec leurs effets négatifs sur la productivité est donc confirmée par les observations sur le terrain et soutenue par l'organisation.

Des outils officiels d'autres non

Nous avons observé que certains outils sont "officiels", c'est à dire approuvés par l'organisation. D'autres en revanche ne le sont pas car utilisés sans approbation préalable.
Ainsi, un testeur nous a parlé d'un wiki qu'il a utilisé avec son équipe sur un projet en ces termes: "En fait, c'est non officiel, ils nous ont demandé de ne pas l'utiliser parce qu'on a la plateforme de gestion des connaissances (PGC)" (traduit de l'anglais de l'entrevue n.7). Quand nous lui avons demandé où ce wiki non officiel était hébergé, il nous a répondu "Sur le portable de quelqu'un" (traduit de l'anglais de l'entrevue n.7). La PGC a été développé à l'échelle du groupe et a certainement était bien conçue, mais les résultats escomptés n'ont pas été atteints. Les gens ont tout d'abord créé trop de duplicatas entraînant une multitude de réponses pour une simple requête de recherche.
Ainsi, à la question adressée au même testeur, "trouvez vous facilement ce que vous cherchez?" il répond: "Non jamais, mais dans tout le groupe vous ne trouverez rien"(traduit de l'anglais de l'entrevue n.7). Nous avons voulu en savoir d'avantage sur ce wiki qui semblait fonctionner alors que la PGC faisait défaut c'est alors qu'il a ajouté: "C'est pour le bonus de fin d'année, vous devez au minimum publier 4 à 6 fois sur la PGC et vous devez au moins être membre de votre groupe" (traduit de l'anglais de l'entrevue n.7). En conséquence, les publications sur la PGC seraient de piètre qualité nous a t-il dit, l'usager n'ayant qu'un objectif l'obtention du bonus. Ainsi, la base de connaissances s'est détériorée à tel point que, n'y trouvant plus réponse à leurs questions les gens s'en désintéressent et créent des bases locales non officielles. Comme pour le constat n.1 l'organisation est au fait de ce problème. Dans le document "Stratégie de collaboration 2007-2012", sous principes directeurs, est soulignée la nécessaire "intégration avec les processus et les outils existants" se caractérisant par "une collaboration souple entre processus et applications d'affaires" (traduit de l'anglais). En attendant, l'on verra cohabiter des outils officiels et d'autres non.

Personne n'a une vue d'ensemble sur le projet

Nous avons observé qu'en utilisant des outils différents, qui ne communiquent pas bien entre eux, aucun membre de l'équipe n'a de vue complète sur le projet. Chaque personne ne voit que sa partie.À la question "Serait-il bon d'avoir une meilleure vue d'ensemble du projet?" une administratrice projet nous a dit: "Oui on n'a pas ça avec la PCPI" (traduit de l'anglais de l'entrevue n.1). Un intégrateur système a tenu les propos suivants:"Pour naviguer le site cela pourrait être utile" (entrevue n.2. Finalement, un développeur logiciel a ajouté: "Oui, çà serait plus facile de se retrouver. Ça arrive que dans la PCPI on aille à certains endroits et ce n'est pas évident de se retrouver." (traduit de l'anglais de l'entrevue n.3). Ce constat est encore une fois corroboré par le document interne "Stratégie de collaboration 2007-2012" section "Gestionnaires d'affaires" sous le titre révélateur: "Si l'organisation savait ce que l'organisation sait". (avec en lieu et place du mot organisation le nom réel de celle-ci). Sous ce titre sont soulignés que "La croissance dans les services demande une utilisation globale efficiente" et qu'il est nécessaire de pouvoir "trouver les personnes et l'information". L'absence de vue d'ensemble soulignée par trois répondants est reconnue par l'organisation comme une faille du système d'information.

Une culture administrative contrôlante

Le modèle de l'organisation vue comme une machine (Morgan 2006 p.11) ou comme une araignée (O. Brafman et R. A. Beckstrom) où le contrôle s'exerce de façon verticale depuis la tête (la direction) vers le corps et les pattes (exécutants) est encore très présent dans les organisations. Or les projets complexes appellent à un nécessaire changement de culture, où le pouvoir est décentralisé et en réseau (Axelrod et Cohen, 2001 p.67). Concrètement il s'agit de passer d'une structure verticale à une structure horizontale ou circulaire. Nous avons observé que le personnel administratif était très contrôlant, à l'opposé des informaticiens qui n'avaient qu'un besoin faible de contrôler l'information, et qui appréciaient la philosophie constructiviste du wiki (pour ceux qui l'avaient utilisé par le passé). Ainsi, une administratrice projet a répondu aux questions "Serait-il bon que les membres de son équipe puissent parfois éditer la PCPI? Ne serait-ce pas plus simple?", elle répondit "oui çà le serait, mais c'est aussi une forme de contrôle. S'il n'y a qu'une personne, vous savez que c'est vous le point de contact et toutes les demandes viennent vers vous"(traduit de l'anglais de l'entrevue n.1). La même personne lorsque nous parlions de wiki a de suite demandé "Pouvez-vous avoir différents accès selon les rôles?"(traduit de l'anglais de l'entrevue n.1) ce qui s'apparente à un geste de contrôle. Un développeur externe nous a dit en parlant de la PCPI, "c'est un concept wiki, mais moins flexible, vous ne pouvez pas effacer grand chose"(traduit de l'anglais de l'entrevue n.4). Par effacer, on entend que l'utilisateur régulier, n'est pas autorisé à modifier le contenu, opération réservée à l'administratrice projet. Le besoin de contrôle est également traduit par une agente qui nous montrant le programme sur lequel elle travaille nous dit, "ici, le dialogue ne devrait être accessible uniquement par les membres du groupe de gestion des configurations, parce que nous voulons avoir un contrôle sur ce qui est publié sur ces pages" (Traduit de l'anglais de l'entrevue n.5). Parmi les répondants deux seulement étaient des administratifs (entrevue n.1 et 5) qui unanimement ont souligné un besoin de contrôle. Les documents corporatifs à notre disposition ne traitaient toutefois pas directement du contrôle, mais l'arrivée du Web 2.0 présenté à de multiples reprises, tend vers le paradigme de l'utilisateur acteur et aura des conséquences sur une culture administrative aujourd'hui contrôlante.

Des transferts limités voir une perte d'information

Nous avons observé et consigné à de multiples reprises dans notre journal de bord qu'avec les outils en place, les échanges d'information entre projets sont limités voir absents. Les causes pourraient être diverses, on pense entre autres, à la multitude de mots de passe (contrôle) nécessaires pour passer d'un outil à un autre et à la capacité limitée des moteurs de recherche qui génèrent des réponses non pertinentes pour des requêtes lancées au travers des différentes plateformes, bases de données et autres. Avec la PCPI, lorsqu'un projet est clos, l'administratrice projet extrait l'ensemble des données sur un document de format texte, ce qui peut prendre plusieurs heures voir jours selon la taille du projet. Encore une fois, on réutilise inutilement un même contenu. Le document obtenu est ensuite stocké dans une base de données puis le site d'origine est fermé et ne sera plus accessible aux utilisateurs. Dans un souci de gestion des connaissances, nous avons posé la question à la personne intéressée: "Quand le projet est clos, que la PCPI est fermée, comment fait-on pour effectuer une recherche d'information dans le document texte?". La réponse a été "si tu as le numéro de document tu peux chercher" (traduit de l'anglais de l'entrevue n.1). Au numéro s'ajoute certainement d'autres critères de filtrage comme le nom du projet ou celui du gestionnaire. Mais, on peut s'interroger sur la capacité d'un nouvel arrivant à trouver une information se trouvant dans un document dont il ignore l'existence. Nous constatons ici la perte d'une information enrichie de l'historique du projet qui disparaît purement et simplement lorsqu'elle est supprimée de la PCPI ou d'une information disponible sous forme de document texte et dont l'accès est rendu invisible aux non initiés. Dans le même registre les leçons apprises sont consignées en fin de projet dans un rapport stocké dans une base de données où il "prendra la poussière" pour les années à venir. Un développeur nous a d'ailleurs dit en référence aux réunions sur les leçons apprises "En général ça produit un document et c'est tout ce que ça produit" (entrevue n.3). Ce constat n'est pas soutenu directement pas l'organisation mais en soulignant le besoin de revoir les processus d'information dans le document "Stratégie de collaboration 2007-2012", elle l'appuie indirectement. Il est en effet fort probable (même si cela n'a pas été fouillé en détail car dépassant le cadre de notre recherche), que les défaillances du système d'information entraînent des transferts limités et parfois des pertes d'information.

Une connaissance limitée de l'outil wiki

Nous avons observé, que si les informaticiens avaient utilisé le wiki dans des projets antérieurs, ils n'en connaissaient pas les fonctions avancées. Les wikis lancés étant pour la plupart non officiels, les utilisateurs n'ont pas essayé d'en retirer le maximum. Ainsi, un développeur nous a dit "ça fait 5, 6 ans, je ne sais pas si ça a beaucoup changé depuis" (traduit de l'anglais de l'entrevue n.3). D'autres l'utilisent mais font souvent appel à un collègue pour les aider. Une agente nous a dit: "quand un nouveau projet commence, je contacte une personne pour créer pour moi une page wiki qui est un modèle .. on la met à jour avec les informations pertinentes" (traduit de l'anglais de l'entrevue n.5). On voit ici que la simple création d'un hyperlien requiert la participation d'une tierce personne, alors que cette opération basique ne prend pas plus de 5 seconde à réaliser.
Une autre personne nous rapporte: "on a une page wiki, c'est en gros ce que je sais des pages wiki, je n'ai pas beaucoup travaillé avec des pages wikis" (traduit de l'anglais de l'entrevue n.6). Les non informaticiens, tel le personnel administratif, n'ont pour la plupart jamais utilisé de wiki même s'ils en connaissent le principe: "Je n'utilise pas les wikis" (traduit de l'anglais de l'entrevue n.1), "C'est X qui s'occupe des outils, des méthodes et des outils, elle a mis en place, un wiki, qui n'est pas encore au point" (traduit de l'anglais de l'entrevue n.9). L'organisation n'a pas encore déployé beaucoup de wikis de façon officielle, ceci explique pourquoi aujourd'hui les usagers n'en ont qu'une connaissance limitée. Parmi les onze répondants deux seulement semblaient avoir utilisé un wiki de façon intensive.

Vers un wiki par l'utilisateur et pour l'utilisateur

À notre arrivée sur le terrain, nous avons relevé la présence de plusieurs wikis en gestion de projet, un seul était officiel mais limité dans sa portée. Un second engin wiki était en cours de déploiement à l'intérieur de la nouvelle plateforme de collaboration projet interne (NPCPI). Cet engin est en quelque sorte un "mini-wiki" chaque équipe pouvant créer des pages wiki à l'intérieur de son espace de travail, mais celles-ci ne communiquent pas entre elles d'un projet à un autre, réduisant de fait l'effet réseau et les capacités de recherche inter-projets. Ceci dénote une tendance de l'organisation à vouloir donner un peu plus de latitude à l'utilisateur, tout en conservant le contrôle.
Contrôle, manque de flexibilité et difficultés à trouver l'information, ont poussé certains à ouvrir des wikis non officiels souvent fermés ensuite sur demande de l'organisation. C'est souvent avec nostalgie que les utilisateurs en abordent les fermetures forcées. Ainsi, un développeur nous a dit en parlant de la PCPI, "ils gèrent qui a accès, alors que le wiki s'est plus ouvert" et a ajouté en parlant d'un wiki fermé "c'était nous qui le contrôlions" (traduit de l'anglais de l'entrevue n.3). Un autre développeur nous a expliqué, "normalement, on utilise le wiki pour se simplifier la vie" et "le wiki était là pour tout" (traduit de l'anglais de l'entrevue n.4). Propos révélateurs de la complication des outils en place en opposition à la convivialité du wiki. Mais s'il a fait l'objet d'une certaine censure par le passé, le wiki pourrait devenir un outil d'avenir pour le groupe. Il a tout d'abord été fortement mis en avant dans un forum de discussion interne ouvert aux employés du groupe, sorte de boîte à idées virtuelle. Il a, suite à cela été intégré dans la NPCPI. De plus, dans le plan de route du document '"Stratégie de collaboration 2007-2012"'', les wikis sont mis en avant en 2008 au niveau de la collaboration interne et en 2009 et 2010, ils devraient l'être pour la collaboration externe en particulier avec les partenaires d'affaires. Le désir d'augmenter le niveau de collaboration est fort puisque, le groupe se positionne aujourd'hui au niveau 3 du modèle de maturité collaborative de Gartner présenté ci-dessous, mais a pour objectif d'atteindre le niveau 4 en 2009 et le niveau 5 entre 2010 et 2012. Ce désir est motivé par un besoin interne, mais aussi comme le montre une présentation donnée le 28 août 2008 et mise à disposition des employés pour écoute différée, pour ne pas se laisser dépasser par des concurrents qui ont pour la plupart déjà embrassé ses technologies du Web 2.0 dont le wiki est un élément clé.

Tableau 4.2: Modèle de collaboration (Gartner)

Maturité	Description
5. Centré sur le lieu de travail	La visualisation du lieu de travail et la connectivité permanente, étendent les efforts de collaboration pour inclure les dispositifs et le réseautage: les communications unifiées
4. Centré processus	La collaboration vue comme un service intégrée à l'intérieur des processus. La collaboration interne et externe standardisée au travers d'une infrastructure du savoir de notoriété publique. Des composants collaboratifs fournis de façon "contextuelle" pour répondre aux besoins de l'utilisateur.
3. Orienté entreprise	Gouvernance centralisée et standardisation des outils et des environnement de développement. Usage courant des politiques. La collaboration devient partie intégrante des efforts d'architecture d'entreprise. La collaboration externe demeure un goulot d'étranglement.
2. Orienté unité d'affaires	Les décisions sont consistantes à un niveau départemental; utilisation de services externalisés; la collaboration gérée à partir d'une approche "boîte à outil"
1. Groupe de travail	Équipes locales, productivité personnelle, ancrés autour des courriels et des serveurs de fichiers.

Source: "Evaluate Your Collaboration Maturity Business Value", Gartner juillet 2006

Nous pouvons donc avancer que si l'organisation met en pratique sa stratégie de collaboration, elle embrassera le paradigme de l'utilisateur acteur et verra se développer des wikis créés par les utilisateurs qui répondront à leurs besoins spécifiques.

Le wiki perçu comme un carrefour

Nous avons observé que la quasi totalité des personnes interrogées, voient dans le wiki un agrégateur pour stocker et échanger de l'information et des idées, comme le montrent les citations suivantes:
"Si tu as un problème, tu vas dans le wiki pour voir si quelqu'un a déjà eu le même problème. L'information va être là, ou si toi tu trouves une solution a un problème, tu vas y mettre l'information pour qu'un autre puisse en bénéficier." (entrevue n.2)
"Le wiki c'est juste comme une place centrale pour mettre l'information" (entrevue 3)
"On a une place centrale pour l'information et tout le monde peut éditer" (traduit de l'anglais de l'entrevue n.4)
"Vous avez toute l'information à un endroit et vous cliquez. Vous n'avez pas à aller dans une base de données, vous avez un emplacement et de là vous allez partout." (traduit de l'anglais de l'entrevue n.5)
"Ce que j'aime c'est que vous pouvez avoir un site web où vous regroupez tout" (traduit de l'anglais de l'entrevue n.6)
" Se serait bon d'avoir tout centralisée pour évider d'aller à droite et à gauche"(traduit de l'anglais de l'entrevue n.7) ou encore '"Le wiki est un livre de cuisine"'' (ibid)
"Je peux voir la documentation ici (sur une base de données) mais le wiki c'est l'interface" (traduit de l'anglais de l'entrevue n.8) ou encore "Un autre bénéfice du wiki c'est l'échange d'idées, avoir un forum, des questions/réponses et ce genre de choses" (ibid)
"Çà c'était pratique pour moi, parce que ça me donnait une grande source d'information" (entrevue n.9)

Un carrefour se construirait notamment à partir de la capacité du wiki à faire des liens. Ainsi, pour un développeur: "L'aspect le plus intéressant c'est les liens avec le code et les liens avec le système d'enregistrement des bogues" (traduit de l'anglais de l'entrevue n.4). Pour une agente de support "On stocke des documents (dans la base de données) on copie l'hyperlien, et on colle simplement (dans le wiki)"(traduit de l'anglais de l'entrevue n.5). Ces liens permettent au wiki de croître de façon organique "Quand on créait un nouveau projet, on créait une nouvelle page wiki et c'est tout" (traduit de l'anglais de l'entrevue n.4). Cette croissance en accord avec les besoins des utilisateurs est facilitée par la convivialité d'usage du wiki. Un testeur nous a dit à ce propos: "C'est simple à utiliser et les gens y vont pour contribuer et maintenir le wiki." (traduit de l'anglais de l'entrevue n.8). Ce constat est corroboré par l'organisation qui a dit lors de la formation donnée 28 août 2008 sur le Web 2.0 qui avait pour titre "Une façon différente de travailler" (traduit de l'anglais) que le wiki est un agrégateur. On y voit représenté sur une acétate deux figures d'un processus de collaboration. La première est centrée sur des personnes, qui évolue vers une seconde centrée autour du wiki qui devient dès lors un carrefour.

4.2.1.2 Analyse des constats

Un système d'information compliqué donc simplifiable

Un système compliqué se caractérise par une multitude d'éléments interreliés dont il est possible d'anticiper les comportements à l'aide par exemple des mathématiques ou de l'informatique. Or un tel système est simplifiable à l'instar d'une équation mathématique compliquée. Nos deux premiers constats font état de l'utilisation d'une diversité d'outils par l'équipe projet certains officiels, d'autres non. Ces constats se retrouvent tant au niveau des entrevues préliminaires que dans les documents internes de l'organisation, qui semble consciente de la nécessaire intégration des processus et des outils existants. Les outils diffèrent selon que l'utilisateur est administrateur, développeur ou documentaliste. N'existe t-il pas de possibilités de réunir ces outils? Ne pourrait-on pas avoir un seul point d'accès aux différentes bases de données? Faut-il concentrer le pouvoir d'édition dans les mains de quelques personnes rendant les autres dépendantes de leurs disponibilités? Le contrôle administratif est justifié par une volonté de limiter les risques d'erreurs et de s'assurer d'une certaine qualité de contenu (entrevues 1 et 5). Cette tendance est compréhensible dans les gros groupes pour des raisons d'organisation, mais trop souvent cela tourne à l'hyper-bureaucratie. Hyper-bureaucratie que le chercheur a lui-même vécu ne serait-ce que pour obtenir les accès à l'Intranet et aux multiples applications et bases de données utilisées en gestion de projet.

La figure 4.5 ci-joint illustre à partir d'observations de divers acteurs consignées dans le journal de bord, la circulation de l'information destinée à être stockée sur la PCPI ou la NPCPI. La personne au centre contrôle l'information, formant un goulot d'étranglement. Ses collègues n'ont en général qu'un droit de regard sur les plateformes et un pouvoir d'édition limité. La structure représentée est de type verticale.

Figure 4.5: Modélisation du contrôle sur la PCPI et de la NPCPI

Légende:
(1) Base de données
(2) PCPI
(3) NPCPI

Aussi divers que les outils puissent être, aussi diverses que puissent être leurs interrelations; outils et interrelations restent dénombrables. Nous sommes en présence d'un système compliqué dont "on peut néanmoins venir à bout avec du temps et de l'expertise" (Genelot 2001). Autrement dit, on peut simplifier le système d'information. Les utilisateurs voient dans le wiki une possibilité de centralisation de l'information aujourd'hui éparpillée à travers des applications, des bases de données et d'autres outils informatiques. Cette dispersion rend l'information difficile à trouver, voir parfois n'en garde tout simplement pas trace, on pense ici aux discussions téléphoniques, aux courriels etc... Si le wiki parvenait à jouer un rôle centralisateur, en utilisant ses capacités à faire des liens (hyperliens), cela réduirait d'autant la complication du système d'information. Il ne s'agirait pas de remplacer tous les outils par le wiki, bien que cela soit possible pour certains, mais plutôt de les relier entre eux grâce au wiki. Concrètement, le wiki ne sait pas générer un graphique de type GANTT, mais il pourrait stocker tous les liens pointant vers ces graphiques. L'utilisateur au lieu de naviguer d'un outil à l'autre parfois ne sachant pas où trouver ce qu'il cherche irait sur le wiki qui simplifierait un système d'information aujourd'hui compliqué.

Le piège de la simplicité du réel mutile la complexité

Le réel est souvent subjectivement simplifié. On ne voit ou on ne veut voir que la pointe le l'iceberg et non sa totalité, au risque de se faire piéger par celui-ci. Dans notre cas, aucun membre du groupe n'a de vue d'ensemble de l'iceberg autrement dit du projet. Ce constat issu des témoignages est corroboré par les documents internes sous le slogan révélateur "Si l'organisation savait ce que l'organisation sait" (avec en lieu est place du mot organisation le nom de la compagnie). Nos observations sur le terrain renforcent encore ce point. Il a ainsi été fastidieux pour le chercheur de trouver les renseignements sur les outils et de comprendre comment ils s'articulaient. Or s'ils ne s'articulent pas correctement, les relations complexes entre utilisateurs risquent d'être négligées.

Pour Morin, "la simplicité voit soit l’un, soit le multiple, mais ne peut voir que l’Un peut être en même temps Multiple. Le principe de simplicité soit sépare ce qui est lié (disjonction), soit unifie ce qui est divers (réduction)"(Morin IPC 2005 p.79). En reprenant nos constats à la lumière de cette définition, on voit que chaque membre de l'équipe a sa propre vision du projet au travers des outils qu'il utilise. C'est à dire qu'il ne voit que l'Un. Sa perspective est séparée du tout, elle est disjointe.

Williams et Baccarini insistaient sur la nature des interdépendances pour qualifier un système de complexe (Williams, 1999) (Baccarini, 1996). Les interdépendances réciproques (Thomson, 1967) ou récursives (Morin, 2005) étant les plus propices à une accentuation de la complexité. On retrouve ce type d'interdépendances au sein du projet Alpha. Le rédacteur du guide d'utilisation a besoin des développeurs pour construire son guide, et les développeurs ont besoin du rédacteur pour mettre en mots le code qu'ils ont produit. Ils se nourrissent réciproquement. Par mesure de simplification ou de contrôle, leurs outils diffèrent, ou ils n'ont pas d'accès direct aux outils de leurs collègues pour trouver des réponses ou partager leurs observations. Ils devront ainsi pallier à la disjonction au sein du système d'information par des échanges accrus de courriels, d'appels téléphoniques et de discussions informelles pour reconnecter les éléments disjoints et pour prendre en compte les interdépendances réciproques.

Un autre constat met en avant un transfert limité voir une perte d'information. Certaines parties originales du projet sont parfois purement et simplement supprimées de la PCPI et conservées sous forme de clones au format texte. Ceci entraîne une perte de l'historique des versions du projet doublée d'une difficulté de recherche par mots clés (en général le moteur de recherche ne rentre pas dans le document texte). Autrement dit on passe de la possibilité de retracer l'historique depuis t jusqu'à t+n à un document texte qui nous montre uniquement t+n. On réduit par là même, la visibilité des données donc leurs chances d'être réutilisées. Ce système d'information est réductionniste lorsqu'en supprimant l'historique du projet il unifie ce qui est divers (Morin IPC 2005 p.79).

Le système d'information en place tantôt disjoint, tantôt réduit c'est à dire qu'il piège l'utilisateur en le mettant en face d'une réalité simplifiée. Cette simplification du réel a pour conséquence une perte de sens par suppression d'informations vitales pour l'avancement du projet, autrement dit par mutilation de la complexité.

Un système vertical n'offrant pas la variété requise au pilotage du projet

On peut s'interroger sur les capacités d'un système inutilement compliqué et simplificateur à piloter efficacement un projet complexe. Lemoigne disait: "Tout système de pilotage qui soit à la fois le plus réussi (successful) et le plus simple doit être isomorphe du système à piloter."(Le Moigne TSG pdf 1994 - 2006 p.175). Les questions suivantes peuvent se poser: Un système aussi contrôlé est-il isomorphe au système projet à piloter? Ce système dispose t-il de spécifications minimales pour s'adapter au changement et pour muter face à l'incertain? Enfin, ce même système sera t-il en mesure d'apprendre à apprendre? C'est à dire pour reprendre Morgan, à analyser et anticiper le changement dans le milieu, à acquérir la capacité à mettre en doute, à permettre la naissance de la direction stratégique, de devenir expert dans l'art de l'apprentissage en boucle double (Morgan, 2006 p.85-86). Nous ne pensons pas que le système d'information en place soit capable de répondre positivement à l'ensemble de ces questions. Lorsqu'il diversifie les outils sans les relier entre-eux, il disjoint les interrelations entre utilisateurs ou, il est réductionniste, lorsqu'il réduit les informations et l'historique d'un projet à un simple document texte. Ne nous méprenons pas, les outils actuels ne sont pas mauvais, ils ont permis de mener à bien de nombreux projets. Cependant, ils ne disposent pas de la flexibilité, de la souplesse nécessaire pour faire face à l'inconnu, à l'imprévu, de la majorité des projets modernes qui, doivent être abordés comme des systèmes adaptatifs complexes (Harkema 2003). Une culture administrative contrôlante et un transfert limité de l'information nous amènent à croire que le système est structuré tel une araignée. Or l'araignée (O. Brafman et R.A. Beckstrom, 2006), structure verticale par excellence, ne permet pas dans notre cas au système d'information de disposer de la variété requise pour piloter le système projet c'est à dire de disposer d'un nombre suffisant de configurations (variété) pour s'adapter et piloter le système projet.

4.2.2 Pendant l'utilisation du wiki

En partant des données issues du journal de bord, du wiki et du sondage intermédiaire, cette section dresse les constats observés lors de l'utilisation du wiki.
Pour scruter les constats et modéliser le wiki, nous utilisons comme moteur les quatre questions inséparables de la définition SAGACE reprises par le lexique MCXAPC (http://www.mcxapc.org/static.php?file=lexique.htm&menuID=lexique consulté le 29.12.09)
- il fait quoi?
- dans quoi?
- pour quoi?
- devenant quoi?
Finalement, nous faisons l'analyse des constats au travers des trois principes morinniens composants notre cadre conceptuel.

Pour aider le lecteur à visualiser le wiki, nous avons reconstitué ci-dessous la page d'accueil du projet Alpha, en remplaçant le contenu réel par du contenu fictif, voir figure 4.6.

Figure 4.6: Page d'accueil du wiki projet Alpha

4.2.2.1 Constats

Le wiki est devenu le carrefour des intelligences

Alors que nous soulignions en phase d'avant projet que le wiki était vu comme un agrégateur, cette "prédiction" des membres de l'équipe s'est concrétisée. Quatre témoignages sur cinq recueillis par le sondage en ligne, vont dans ce sens: "J'aime que tout soit centralisé, je peux trouver ce dont j'ai besoin pour mon travail quotidien" (Traduit du sondage n.1) ou "on a une place centrale pour accumuler le savoir quotidien" (Traduit du sondage n.3). L'organisation a créé une section appelée "base de connaissances" ou s'accumule les savoirs relatifs au projet. Ce carrefour des connaissances offre un accès rapide à l'information. "Dans mon cas ça m'aide beaucoup à trouver de l'information comme des documents par exemple quand j'en ai besoin c'est facile"(Traduit du sondage n.2) ou encore "je trouve information et documents plus rapidement" (Traduit du sondage n.5).
La figure 4.6 montre bien que la page d'accueil réunie en un même lieu 5 axes à savoir: L'axe "produits" (B) dans lequel on retrouve notamment nos 4 composantes développées au Canada. L'axe "projets" (C) où l'on retrouve les phases 2 et 3 du projet Alpha (la 1 n'étant plus nécessaire à ce stade, elle n'a pas été relié au wiki). L'axe "information" (D) s'adressant à l'équipe projet qui contient un forum de discussions et surtout une base de connaissances. L'axe "cas client" (user stories) et l'axe "Tiki" relatif à l'amélioration de l'outil lui-même.

Après 80 jours d'exploitation soit le 20 novembre 2008, les statistiques du wiki sont représentés dans le tableau 4.3:

Tableau 4.3: Statistiques wiki au 20.11.08

Nombre total de pages wiki	131
Nombre de versions	1736
Nombre moyen de version par page	13,25
Nombre de visite de pages wiki	11428
Nombre d'utilisateurs	20
1ère page la plus visitée (en nb de clics): page d'accueil projet Alpha	1524
2ème page la plus visitée (en nb de clics): page d'accueil du suivi du pilote wiki	785
3ème page la plus visitée (en nb de clics): base de connaissances du projet Alpha	768
4ème page la plus visitée (en nb de clics): page d'accueil de la phase 3	730

La troisième position de la base de connaissances parmi les pages les plus visitées, corrobore l'importance qu'a pris le wiki dans le partage du savoir au sein de l'équipe projet.

Auparavant chaque utilisateur devait se connecter à différents outils nécessaires au projet (Figure 4.2) ce qui était compliqué. Les plateformes de collaboration projet PCPI et PCPE doivent faire office de point central mais n'y parviennent que de façon incomplète leurs accès étant fortement contrôlés (Figure 4.5) (à ce stade nous n'avions pas assez de recul pour évaluer le NPCPI). En se connectant au wiki l'utilisateur trouve l'information et les liens dont il a besoin et peut en ajouter ou en retirer à sa guise. Le wiki est devenu la place centrale qui connecte les personnes et le contenu, comme représenté sur la figure 4.7:

Figure 4.7: Modélisation des interactions groupe/wiki/BD/applications

Le wiki est un lieu commun, accessible et éditable par tous les utilisateurs et qui favorise une culture horizontale.

Il fait quoi? Le wiki agrège l'information et en facilite la diffusion grâce aux hyperliens et à une convivialité d'usage. C'est une plateforme commune qui mobilise les intelligences et les expériences en reliant les outils et les utilisateurs.
Pour quoi? Pour simplifier la complication, mais avant tout pour mobiliser et coordonner les intelligences, les expériences, les savoir-faire, les sagesses et les imaginations des êtres humains (Lévy P. 1997 p.12). En devenant quoi? La mémoire collective de l'organisation projet.

L'absence de règle stricte libère les utilisateurs prémice de leur auto-organisation

Si la culture verticale se traduit par un ensemble de règles et de normes à suivre pour assurer un contrôle strict, la culture horizontale vise à réduire ces dernières. De fait, au démarrage, aucune règle précise n'avait été posée quant à l'utilisation du wiki. Nous nous sommes demandé si cette absence de règle, d'instruction, avait affectée les utilisateurs.
Toutes les réponses obtenues à travers le sondage montrent qu'ils ne s'en préoccupent guère. "Ce qui compte est que l'information soit là, le reste est secondaire"(Traduit du sondage n.1). "Pour le moment cela ne me touche pas"(Traduit du sondage n.2). "J'aime ça ainsi"(Traduit du sondage n.4)."Çà ne me touche pas"(Traduit du sondage n.5). L'un d'eux à toutefois dit: "Parfois l'information est là mais dans une section où l'on ne pensait pas la trouver"(Traduit du sondage n.3). Il ajoute que: "C'est une bonne et flexible façon de partager le savoir en supprimant la lourdeur d'un excès de processus"''" (ibid). On comprend, que si l'information n'est pas toujours à l'emplacement souhaitée (le wiki n'avait qu'un mois), elle est disponible et que le wiki allège des processus souvent lourds avec d'autres outils. Nous avons de plus, observé que la trame de base donnée au wiki a continué à évoluer de façon organique, en fonction des besoins d'utilisateurs libres d'ajouter, d'effacer, et de modifier le contenu et la structure.

Il fait quoi? Il libère l'équipe de certaines lourdeurs procédurales. Pour quoi? Pour poser les bases d'une culture horizontale qui permet aux usagers de s'auto-organiser.

Le wiki mute selon les besoins du projet pour mieux le piloter

Pour être efficace le wiki doit posséder une variété similaire à celle du projet. Par exemple autoriser tous les clients impliqués à consulter les informations pertinentes à l'avancement du projet. Nous avons observé que la liberté de jouer à souhait avec le contenu a ouvert de nouvelles possibilités d'expression individuelle. Si quelqu'un voulait ajouter quelque chose ou créer des pages spécifiques à ses besoins, il n'avait qu'à éditer le wiki, écrire et enregistrer. L'édition est aisée puisqu'il suffit de cliquer sur les icônes montrant une feuille surmontée d'un crayon que l'on voit sur la figure 4.6 précédente pour passer du mode de visualisation au mode d'édition.
Certains utilisateurs ont exprimé cette liberté en ces mots: "Je peux créer mon propre contenu" (Traduit du sondage n.1) ou bien "Chaque leader de composante met à jour ses propres pages avec de l'information pertinente"(Traduit du sondage n.2).
Mi-octobre, le chef architecte en déplacement en Europe a rencontré l'un des clients du projet. Cette personne était gestionnaire de produit technique, elle a demandée à être tenu informée régulièrement sur son cas que nous appellerons "cas Z". En fait, elle s'attendait à recevoir des courriels de suivi. C'est alors que le chef architecte a eu l'idée de lui donner un accès à la page wiki ouverte pour son cas. Le 15 octobre la page est créée et le client et les développeurs sont mis en contact direct. Lorsque l'équipe canadienne commençait sa journée, elle avait déjà les commentaires du client qui avait commencé la sienne 6h plus tôt. Le lendemain matin, c'était le client qui avait l'état des avancements, le tout sans aucun échange de courriel. C'est ainsi que le 20 novembre après un peu plus d'un mois, la page du cas Z totalisée 235 visites et se plaçait au 9ème rang des pages les plus visitées.

Il fait quoi? Le wiki mute selon les besoins de l'équipe. Dans quoi? Dans l'environnement projet composé entre autres de l'ensemble des parties prenantes. Pour quoi? Pour ajuster sa variété à celle du projet et ainsi pouvoir le piloter.

Le wiki modifie les habitudes de travail vers un apprentissage en boucle double

Lorsque l'on implante une application informatique, on la configure d'une certaine façon, on lui donne "forme". En retour elle va "former" Putnam (1993) ses utilisateurs en modifiant leur façon de travailler. Autrement dit, il y a un effet récursif entre l'application et les utilisateurs.
À l'adoption du wiki le 29 août 2008, nous relevions dans le journal de bord, une réticence de certains exécutants du projet. Ces derniers s'inquiétaient de la présence de membres de la direction dans la liste des personnes ayant accès au wiki. Ces inquiétudes nous sont confirmées le 2 septembre par le chef architecte. Suite à ces observations, un point a été fait avec les dirigeants pour leur faire comprendre qu'ils devaient mesurer leurs interventions et ne pas heurter des utilisateurs "mis à nu" dans leur travail quotidien. En effet, écrire dans un wiki est un travail en-cours. Il est nécessaire de prendre du recul et ne pas juger des pages wiki en pleine évolution comme on jugerait un rapport final. Après 10 jours soit le 12 septembre le chef architecte nous explique qu'une partie de son équipe dont un réfractaire de première heure commençait à bien éditer le wiki. Les inquiétudes semblaient diminuer, ce que confirment le 24 septembre des statistiques d'utilisation du wiki en nette augmentation.

Le 16 septembre nous rencontrons le directeur du bureau de projet qui nous fait part de certains items qui pourraient être intégrés au wiki. L'un de cela est la gestion des risques. À ce jour, la majorité des gestionnaires utilisent des fichiers issus de tableurs pour gérer les risques. Les membres de l'équipe envoient par courriel leurs listes de risques avec leurs observations sans savoir ce que d'autres ont envoyé et le gestionnaire se charge de les intégrer dans un tableur puis en extrait un fichier qu'il fait circuler par courriel. Des mises à jour régulières sont apportées au fichier qui à chaque modification re-circule dans les boîtes courriels de toute l'équipe, générant des centaines de courriels sur la durée du projet, avec un risque que certains utilisateurs ne consultent pas la bonne version ou qu'un courriel se perde. Ainsi à partir du tableau d'origine utilisé par l'organisation et extrait du tableur, nous avons développé une grille similaire dans le wiki. Si rien n'a changé dans la composition de la grille, les bénéfices de la construire sur une page wiki sont l'accès universel que le wiki donne à un état des risques toujours à jour et la flexibilité qu'ont tous les utilisateurs d'en modifier aisément le contenu. Durant le projet Alpha, cette option n'a fait l'objet que de tests sans déploiement à toute l'équipe, mais elle fût très prometteuse car réduisant l'échange de courriels à sa plus simple expression, supprimant la redondance des commentaires et libérant le gestionnaire de la tâche de mise à jour et de diffusion.

Le 19 septembre lors d'une discussion avec un leader de composante, ce dernier se plaint de devoir mettre à jour la documentation dans le wiki et sous forme de document texte. En effet, le wiki étant expérimental, il était nécessaire de suivre en parallèles les règles établies et d'enregistrer au format texte la documentation puis de la stocker sur la base de donnée officielle. Ce qui augmentait inutilement la charge de travail. Le groupe a alors cherché un moyen d'exporter directement le contenu du wiki au format texte puis s'est posé la question "pourquoi ne pas uniquement rédiger la documentation sur le wiki en la rendant officielle et ne rien stocker sur la base de donnée?". Une réunion a été provoquée dans ce sens le 29 septembre avec le chef architecte, un rédacteur technique, le gestionnaire cycle de vie produit et le chercheur. Aucune décision immédiate à l'effet que le wiki remplacerait la base de donnée pour la documentation n'a été prise à l'issue de la réunion mais d'intéressants échanges ont eu lieu pour repenser la rédaction documentaire. En effet, le rédacteur technique pourrait prélever directement l'information dont il a besoin du wiki si celui-ci est bien renseigné par les développeurs et rédiger son guide à même le wiki.

Après un peu plus d'un mois d'utilisation, le sondage intermédiaire montre que le wiki modifie déjà la façon de travailler de l'équipe. Ce qui était précédemment stocké sur les ordinateurs individuels, est de plus en plus enregistré sur le wiki. Trois des personnes sondées nous l'ont exprimé en ces mots :
"Avant on devait avoir des favoris, chercher dans de vieux courriels, etc... maintenant on a accès à l'information depuis une place centrale" (Traduit du sondage n.2).
"Auparavant l'information était disponible par courriels, elle pouvait se perdre ou être difficile à retrouver"(Traduit du sondage n.3).
"Au lieu de conserver les documents ou les références sur mon ordinateur, j'ai maintenant tout sur le wiki"(Traduit du sondage n.4)
On voit apparaître une envie de partager, de donner, pour recevoir en retour de la communauté projet. Un administrateur système nous a dit: "Je crois que çà a créé un sens commun de documenter autant que l'on peut dans le wiki pour être capable de retrouver l'information facilement par la suite" (Traduit du sondage n.2). Un développeur nous a dit: "Lorsque quelqu'un a besoin d'information au sujet de quelque chose, la première chose à faire est de l'écrire sur le wiki"(Traduit du sondage n.4). On s'aperçoit que d'une communication au préalable individualiste accès sur le courriel et les discussions informelles, on est passé à une communication centrée sur un outil commun le wiki. L'administrateur système précédemment cité ajoute que cela est bénéfique à l'organisation. "Çà aide à partager et à trouver de l'information pertinente et donc çà rend l'organisation projet meilleure aussi selon moi"(Traduit du sondage n.2). Pour un autre administrateur, le bénéfice est tel qu'il ne veut plus revenir en arrière. "C'est devenu notre télécommande. Maintenant qu'on l'a on ne peut plus s'en passer" (Traduit du sondage n.1).
Aux commentaires du sondage s'ajoutent des propos recueillis dans les corridors et consignés sur le journal de bord. Ainsi, un développeur nous dit que les tâches sont maintenant mieux documentées. Un autre nous a dit que depuis qu'il a le wiki, les mises à jour sont faites à chaque sortie de réunion, lorsque l'information est fraîche dans la tête, ce qui réduit le risque d'oubli ou de perte d'information. Un autre aspect dans le changement d'habitudes et la diminution importante du nombre de courriels échangés. De nombreux témoignages vont dans ce sens et le chiffre de 70% de courriels en moins (non mesuré de façon formelle) a été avancé lors de la réunion de direction qui s'est tenue le 22 novembre. Durant la même réunion l'échange suivant a eu lieu entre le gestionnaire de projet et le chercheur:
Le gestionnaire de projet: "Que se passera t-il avec les données si on ferme le wiki?" (le wiki n'étant qu'un pilote non officiel, rien ne garantissait que l'organisation voudrait le conserver)
Le chercheur: "Puis-je répondre en vous posant une autre question? Où étaient stockées les données dont vous parlez avant la mise en place du wiki?"
Minute de silence
Le gestionnaire de projet: "Hum, elles étaient stockées dans les boîtes courriels ou souvent étaient perdues"
On constate que l'outil non seulement a changé les habitudes, mais qu'il est entré dans le quotidien, au point que l'on ne voit déjà plus comment les choses étaient auparavant.

Les utilisateurs déposent aujourd'hui du contenu sur le wiki qui génère un flux RSS (Really Simple Syndication), voir figure 4.8. C'est à dire un type de format utilisant un langage informatique de balisage générique, permettant la syndication de contenu Web. Lorsqu'il arrive sur sa page d'accueil wiki, l'utilisateur voit la liste de toutes les pages modifiées depuis sa dernière visite. Ceci, lui évite de perdre du temps à naviguer à la recherche de pages ayant été modifiées. De plus, il peut s'abonner à des flux RSS ciblés concernant certaines pages particulières. De prime à bord, on pourrait penser qu'il s'agit là d'un système d'apprentissage en boucle simple, les utilisateurs évoluent dans leur environnement, déposent du contenu sur le wiki et le wiki leurs renvoie des mises à jour, sans remise en question de la pertinence des normes de fonctionnement. Or, on l'a vu pour la rédaction de la documentation ou pour l'ouverture du wiki au client du cas Z, les utilisateurs ne se contentent pas de déposer simplement de l'information. Ils remettent les normes du système en question et ouvrent l'accès au système de pilotage qu'est le wiki à d'autres parties prenantes augmentant sa variété requise quand cela est nécessaire pour mieux piloter le système projet. La figure 4.8 illustre l'apprentissage en boucle double. Les utilisateurs ont accès au wiki qu'ils consultent et ou éditent, le wiki génère de l'information qui se structure en base de connaissances dont les mises à jour sont diffusées au groupe sous forme de flux RSS. À chaque instant toutefois, la structure, les normes de cette base peuvent être modifiées par les utilisateurs.

Figure 4.8: Modélisation des flux d'informations entre les utilisateurs et le wiki en boucle double

"Il fait quoi?" Le wiki modifie profondément les habitudes de travail et favorise la remise en question des normes de fonctionnement "Pour quoi?" Pour poser les bases de l'apprentissage en boucle double"''.

Le wiki représente les parties, le tout et leurs interrelations

Nous vous présentons ici dans un premier temps les commentaires obtenus au travers du sondage. Nous avons ensuite jugé opportun de vous montrer à quoi ressemblaient les différents angles de vues, tels que conçus par les utilisateurs, mais aussi la modélisation automatique, dynamique du tout et des parties par le wiki.

Le sondage intermédiaire du 2 octobre, posait la question suivante: "Pensez-vous que le wiki représente bien les items du projet et leurs interrelations? Pourquoi? Pourquoi pas?" Un administrateur système approuve: "Oui je crois parce que je vois que la majorité des personnes contribuent pour en faire une place idéale où trouver de l'information à jour." (Traduit du sondage n.2) un autre dit avoir une meilleure idée du travail effectué par ses collègues '"Je peux voir ce que les autres membres de l'équipe font" (Traduit du sondage n.1) Mais à la questions "avez vous une meilleure vue d'ensemble du projet grâce au wiki? Pourquoi? Pourquoi pas?" il nous dit que c'est en-cours. Un troisième ajoute qu'une révision ultérieure pourrait être faite: "Peut être que si l'on accumule d'avantage de contenu, on pourra réorganiser un peu"(Traduit du sondage n.3) car pour le moment s'il voit un gain en terme de collaboration, il n'en ai pas encore convaincu pour la vue d'ensemble". C'est plus facile de partager l'information entre les participants au projet. Pas sûr que çà donne une meilleure vue d'ensemble"(ibid). Un intégrateur système est plus négatif répondant à la seconde question: "Non, on a plus d'information disponible. Je pense que si j'avais le temps de naviguer j'en apprendrais d'avantage sur d'autres composantes"''(Traduit du sondage n.5).

Nous avons montré dans la description du cas qu'une structure initiale avait été créée dans le wiki (Figure 4.2). Cette structure avait pour objectif d'interrelier les parties du projet et de permettre une visualisation sous plusieurs angles. Pour comprendre ce que les angles offerts ont apporté aux utilisateurs, nous leur avons demandé "comment avez-vous trouvé les différents angles de vues qu'offrent la structure du wiki (produit, projet, cas client etc...)?". Trois administrateurs systèmes ont apprécié ces angles. "Très pratique" (Traduit du sondage n.1), "J'aime çà, çà rend les choses plus simples pour nous" (Traduit du sondage n.2), '"C'est bon"(Traduit du sondage n.3). Une seule réponse d'un intégrateur système a été mitigé, elle fait référence à l'une des fonctionnalités les "trackers", sorte de mini tableaux Excel éditables par tous intégrés aux pages wiki. "Théoriquement, çà peut être très pratique. Malheureusement, en ce qui me concerne, il ne me semble pas que les trackers aient beaucoup servis"'' (Traduit du sondage n.5). Nous retenons un retour dans l'ensemble positif des utilisateurs suite au sondage, même si des améliorations notamment pour ce qui est de la fonctionnalité "tracker" devaient être apportées.

Explorons maintenant de façon concrète, comment le wiki offre différents angles de vues sur les parties et leurs interrelations. La figure 4.6 montrant la page d'accueil du projet donne un premier aperçu de la structure générale du wiki. Si l'utilisateur clique ensuite sur l'hyperlien "Alpha" se trouvant dans la section "produits", il obtient l'angle de vue suivant:

Figure 4.9: Angle de vue produit - Solutions Alpha

Cette vue regroupe tous les éléments importants relatifs au produit Alpha, on parle aussi de solution parce qu'il s'agit d'un logiciel. Les documents ne sont pas physiquement présents sur la page, ce sont des hyperliens qui pointent vers les bases de données. Les composantes sont aussi des hyperliens ainsi, si l'on poursuit et que de cet angle produit, l'on entre dans une des composantes, on obtient la vue suivante:

Figure 4.10: Angle de vue produit - Solutions Alpha - Composante

On a ici regroupé sur la même page un aperçu de la composante, de quoi s'agit-il? On sait quelles sont les tâches restantes à effectuer et qui en a la charge. Un responsable peut superviser son équipe, un client sait où en est le développement et peut intervenir pour faire rectifier certains aspects enfin, un développeur voit où en est son équipe et quelles sont les tâches qui lui incombent.

Le tableau suivant montre un tracker des tâches ouvertes:

Tableau 4.4: Angle de vue produit - Solutions Alpha - Composante - Tableau des tâches ouvertes

Soulignons que dans ce tableau qui représente de façon classique le suivi des tâches en-cours, les cas clients sont des hyperliens vers des pages wiki. Ces hyperliens sont les mêmes que ceux présents sur la page d'accueil (figure 4.6) dans le tracker "cas client" (K). Ceci démontre comment un lien pointant vers une même information se retrouve à plusieurs endroits différents. Si l'on poursuit en cliquant sur l'un de ces cas client relatif à une tâche, on obtient la vue suivante:

Figure 4.11: Angle de vue produit - Cas client

Ici l'utilisateur a une vue d'ensemble d'un cas client, le tracker des tâches permet à nouveau de filtrer les tâches relatives à ce cas ou de créer de nouvelles tâches si nécessaire à partir d'un formulaire intégré à la page qui envoie directement les informations au tracker. Notons ici qu'il est toujours possible de naviguer par hyperliens depuis cette vue vers la composante ou l'itération projet le (+) dans la figure. Si un utilisateur souhaite ajouter un lien vers une nouvelle source de contenu, il lui suffit d'éditer la page, de créer un lien et d'enregistrer.

Si maintenant du cas client, nous passions au projet Alpha, nous aurions la vue suivante:

Figure 4.12: Angle de vue projet phase 3

Ici l'utilisateur a une vue d'ensemble de la phase 3 du projet. Il peut accéder aux documents relatifs au projet, stockés sur la base de données, aux personnes en charge, aux versions du logiciel avec un accès par hyperliens au code source stocké dans les bases de données spécifiques, aux itérations, aux bogues, aux tâches et il y a même un lien direct au cas Z.

On voit par ces différents angles de vue comment à travers les pages du wiki toutes les parties se connectent entre elles. Tous les grands axes du projet sont connectés entre eux, et de chaque axe on peut accéder aux autres.

Les différents angles de vues offrent une large accessibilité selon les besoins des utilisateurs, qu'ils soient développeurs, gestionnaires de projet, gestionnaires de produit, clients ou autres. Ces utilisateurs sont de plus mis en relation avec les données et les documents stockés sur des bases déjà en place dans l'organisation. Si la multiplication des angles favorise la navigation, elle n'offre qu'une vision limitée du tout.

En revanche, il existe, une façon automatique et dynamique d'avoir une vue d'ensemble du tout et des parties, il s'agit de la carte heuristique dynamique discutée dans notre revue de littérature. Cette fonctionnalité a été utilisée dans notre wiki à titre expérimental. Nous pouvions à tout moment en cliquant sur le lien "carte heuristique" (E) (Figure 4.6) obtenir une carte représentant l'ensemble des hyperliens du site. Si un utilisateur ajoute une page par exemple celle du Cas Z, automatiquement elle est intégrée à la carte.

Pour illustrer le fonctionnement de la carte heuristique dynamique, nous avons recréé partiellement la structure des hyperliens tels qu'ils étaient dans le projet. Ainsi si l'on partait de la page d'accueil du projet Alpha, on obtenait la carte suivante:

Figure 4.13: Carte accueil projet Alpha

Cette vue d'ensemble est similaire à la page d'accueil représentée par la figure 4.6. En cliquant sur les "+" on déploie l'arborescence. Si l'on clique par exemple sur le "+" au niveau de la "Alpha - solution" (W) on obtient la carte suivante:

Figure 4.14: Carte accueil projet Alpha - Alpha - solution déployée

On voit alors se dessiner les liens relatifs à "Alpha - solutions" soit l'angle produit. Si l'on clique ensuite sur l'icône verte de la "composante 1" (X), on va recréer une carte heuristique centrée autour de la dite composante:

Figure 4.15: Carte composante 1 - Accueil projet Alpha déployée

Il est intéressant de souligner qu'étant dans une vue produit on a un lien vers la page d'accueil du projet Alpha. Si l'on déploie cette page, on voit les pages reliées au projet et notamment la phase 3. Si on recentre maintenant en cliquant sur l'icône verte (Y) "Alpha 3", on obtient la carte suivante:

Figure 4.16: Carte Alpha 3

On est à présent passé d'un angle produit la composante 1 à un angle projet avec la phase 3 (Alpha 3). On voit que cette page est notamment connectée aux itérations, au cas Z, à la liste des bogues, mais aussi à la page d'accueil du projet Alpha. Que l'on pourrait à nouveau déployer comme on l'a fait au niveau de la composante 1. On voit ici autant les parties que le tout projet. De chaque partie on peut voir le tout, mais du tout on peut aussi voir chaque partie.

Enfin, l'utilisateur dispose de nombreux outils pour ne pas se perdre et retrouver l'information qui l'intéresse. La page d'accueil du wiki à l'instar des sites Web classiques regroupe les éléments principaux du site pour en faciliter la navigation, mais à la différence d'un site Web cela ne prend que quelques secondes pour en modifier la structure si l'évolution du projet le demande. Le wiki possède un moteur de recherche qui fouille tout le site à la recherche de mots ou d'expressions que l'on pourra filtrer par grandes fonctionnalités (wiki, forum, galerie d'images etc...). Chaque page offre aussi un accès au rétro-lien c'est à dire vers la page parent (Figure 4.6) (J). Des catégories ont également été créées pour structurer d'avantage certains contenus. Si les catégories sont souvent pensées par la direction, les mots clés à l'inverse sont à la discrétion de l'utilisateur qui peut en créer à sa guise. Ainsi, plusieurs pages marquées (taggées) de ces mots se retrouvent dans un nuage de mots (F) (Figure 4.6), pour facilité la recherche. Viennent ensuite les statistiques internes du wiki qui enregistrent toutes les actions et offrent la possibilité de retrouver ce que n'importe quel utilisateur a fait et de savoir exactement ce qu'il a modifié, quand et depuis quel poste. Enfin, la carte heuristique dynamique donne une vision d'ensemble du tout et des interrelations entre les parties.

"Il fait quoi?" Le wiki offre une vue de détail et une vue d'ensemble dynamique de la complexité. "Pour quoi?" Pour permettre aux membres d'une équipe de se situer et de situer le projet (Deladrière 2007 p.3), mais aussi de faire émerger des liens inattendus (ibid).

4.2.2.2 Analyse des constats

Dans cette partie, nous analysons les constats de la période d'utilisation du wiki, à partir de notre tremplin de la complexité c'est à dire en reprenant les trois principes morinniens.

L'épistémologie de la dialogique

La dialogique maintient la dualité au sein de l'unité entre deux logiques à la fois complémentaires et antagonistes (Morin 1991, Cerisy p.291), cela revient à dire que l'on conserve deux logiques, deux points de vue qui s'opposent, plutôt que d'en imposer un seul. Tous les membres de l'équipe ont pu éditer le wiki en termes de contenu mais aussi de structure. Tous ont pu contribuer de la même façon, sans restriction relative à leur position hiérarchique. L'avis de chacun a pu être pris en compte, "toutes les idées ne naissent pas au sommet" (Andrus, 2005). Le wiki est un instrument horizontal par nature, qui aplanit la hiérarchie parce qu'il "rend accessible la composition à des usagers sans connaissance technique" (Leuf et Cunningham, 2001 p.16). Il "encourage une utilisation démocratique du Web" (ibid), de même qu'il a encouragé une utilisation démocratique de la plateforme de collaboration de projet. La confrontation des idées dans un esprit démocratique a été clairement observée, en d'autres mots, la libre expression de vérités contraires. Ceci nous laisse croire que la dialogique est génétique au wiki.
Le mot "partage" ou le verbe "partager" reviennent souvent dans les témoignages. Les membres de l'équipe donnent leurs avis et sont réceptifs aux idées des autres. Un "socle commun de connaissances" (Ayache 2008, p.146) s'est construit favorisant la communication. Tel que l'avait d'écrit Ouni, la collaboration ouverte et la contribution accélérée par le wiki ont facilité l'initialisation et le déroulement de processus divergents (Ouni 2008 - p.61). Des logiques "antagonistes et complémentaires" (Morin 1991, Cerisy p.291) se sont exprimées au quotidien, lorsque le rédacteur technique a fait part de ses contraintes, les développeurs des leurs et l'organisation par la voix de certains supérieurs des siennes? Ces mêmes logiques étaient à l'oeuvre entre clients et développeurs (Cas Z), voir même entre l'organisation locale et son siège quant à l'utilisation du wiki. La dualité entre les logiques a été maintenue retardant parfois les décisions, mais les légitimant par la suite. Le wiki favorise la "créolisation" (Glissant, 2009 p.64) des idées ce qui ne signifie pas pour suivre Glissant, que l'on aille vers une seule vérité commune qui, dans bien des cas serait réductrice, mais plutôt vers la recherche de l'accord entre les idées (ibid). En offrant un espace d'expression aux parties prenantes, contenant des informations et des connaissances à jour, dans un outil facile et libre d'accès on multiplie les chances que chacun puisse s'exprimer. À l'instar des citoyens de Noveck, les parties prenantes ne parlent plus de processus, elles sont le processus (B. S. Noveck, 2009 p.20-21).

"Il fait quoi?" Le wiki aplanit la hiérarchie. "Pour quoi?" Pour favoriser la libre expression de vérités contraires, autrement dit la dialogique.

La culture récursive

"La culture c'est le niveau le plus profond de suppositions et de croyances partagées par les membres d'une organisation, qui opère de façon inconsciente et définit dans le sens 'prendre pour acquis', la perception qu'une organisation a d'elle-même et de son environnement" Traduit de (Schein, 1988) quant à la récursion, c'est ''"un processus où les produits et les effets sont en même temps causes et producteurs de ce qui est produit"" (Morin 2005 p.99 et 100).
À l'image de l'idée forgée par Montesquieu (1689-1755), nous avons constaté que les utilisateurs ont donné forme au wiki qui en retour les a formé (Putnam, 1993). L'équipe projet et les parties prenantes, ont déposé sur le wiki du contenu qui en peu de temps a permis de construire une base de connaissances commune. Ces connaissances en retour influencent l'utilisateur, qui est mieux renseigné et sait ce sur quoi son entourage travaille. L'information à laquelle il accède est à jour et n'est pas dispersée dans des boîtes courriels. Cela semble faciliter et améliorer la prise de décisions, en connaissance des causes, mais souvent aussi des conséquences (Le Moigne 1994-2006 p.37) puisque, tout le monde est en mesure de réagir rapidement à ce qui se dit sur le wiki. Ainsi si le flux d'information n'est pas interrompu, le wiki est en perpétuelle évolution. L'effet récursif se traduit par un changement des habitudes de travail. Nombreux sont les témoignages qui nous montrent à quel point le travail quotidien a été marqué par le wiki. Les mots et expressions employés soulignent ce changement, "avant on devait...", "auparavant", "au lieu de...", "maintenant". Le wiki agit sur la façon dont les utilisateurs travaillent, en regroupant l'information et les connaissances et en rendant les mises à jour et le suivi aisés. Les effets sont non seulement visibles sur un plan qualitatif, l'information est de meilleure qualité mais on le rappelle les changements ont permis entre autre de réduire considérablement la quantité de courriels échangés. L'effet récursif ne se limite pas à l'utilisateur puisque faisant partie d'une organisation celle-ci aussi profite des retombées du wiki. On se souvient de cet administrateur système qui disait que ça rendait l'organisation projet meilleure. Si d'aucuns argueront que tout outil a un effet récursif sur ses utilisateurs, le wiki se démarque par l'aspect dynamique de cet effet. Étant en perpétuelle évolution tant sur le plan du contenu que de sa structure, les retours de la part des utilisateurs en seront influencés.
Le chef architecte résume très bien la culture récursive lorsqu'il dit durant la réunion de direction du 22 novembre: "Ça a changé la mentalité des utilisateurs, ils ont perdu leur peur de partager et sont devenus plus transparents" (traduit de l'anglais). Morin disait que: "Les émergences sont les qualités ou propriétés d'un système qui présentent un caractère de nouveauté par rapport aux qualités ou propriétés des composants considérés isolément ou agencés différemment dans un autre type de système" (Morin, Méthode I, p.106). Si en partageant, les utilisateurs sont devenus plus transparents, le système projet au travers du wiki est lui aussi devenu plus transparent. On est bien en présence d'une qualité nouvelle en comparaison au système projet qui n'utilisait pas le wiki comme système de pilotage. Or, pour qu'il y ait émergence, un certain niveau de complexité est nécessaire qui s'exprime par la non-linéarité (Holland 1999 p.225) en d'autre mot par la récursivité. Ceci signifie aussi que "le tout est plus que la somme des parties", ce qui nous conduit à une structure holographique.

"Il fait quoi" Le wiki modifie la culture organisationnelle en appelant à la transparence. Il permet une remise en cause quasi-perpétuelle du contenu et de la structure. "Pour quoi?" Pour permettre à chacun de s'exprimer sans barrière.

La structure holographique

Par hologramme, on entend que chacune des parties contient le tout et que le tout contient les parties. Son opérationnaliser dans le wiki a été réalisé à partir des cinq principes de Morgan (Morgan, 2006). Des liens forts existent entre ces principes et le wiki qui nous permettent de croire qu'il présente des capacités holographiques. Ainsi, le premier principe de la construction du "tout" dans les "parties" a pris forme au travers des fonctionnalités du wiki que sont: les hyperliens, les trackers, les mots clés, les catégories et la carte heuristique dynamique. Nous avons pu montrer comment depuis les parties ont pouvait voir le "tout" mais aussi comment du "tout" on voyait les parties. La carte heuristique donne une vue de détail et une vue d'ensemble en terme de complexité et aide les utilisateurs à se situer (Deladrière 2007 p.3). L'utilisateur peut voir une large quantité d'information d'un seul coup d'oeil et ainsi faire des liens qui autrement seraient passés inaperçus. Son aspect dynamique garantit une mise à jour en temps réel.
Relativement à la reproduction holographique, il était trop tôt pour exploiter cette possibilité après trois mois d'utilisation. Nous pensons toutefois, que le wiki en a les capacités. Ainsi une fois le projet pilote Alpha clos, si l'organisation choisissait de continuer à utiliser le wiki, on pourrait voir sa structure croître de façon "holographique différenciée" (Morgan 2006). La figure 4.17 nous montre comment la structure du wiki pourrait évoluer dans l'hypothèse du lancement de projets Beta et Gamma. Chaque projet aurait sa propre autonomie, tout en restant relié au tout (l'organisation projet). Les différentes équipes pourraient partager leurs connaissances et puiser dans celles des autres. L'ADN de l'organisation projet devrait ainsi se retrouver dans les parties.

Figure 4.17: La reproduction holographique différenciée appliquée au wiki en gestion de projet

Légende:
P1, P2, P3 = Phase 1, 2, 3
C1, C2, C3 = Composante 1, 2, 3
PP = Partie prenante

La combinaison des fonctionnalités du wiki citées précédemment a aussi favorisée le second principe de redondance de l'information. Si l'on adapte les propos d'Ayache (Ayache, 2008), l'hyperlien permet de sauter d'un clic d'une page wiki à une autre, d'un ordinateur à un autre, d'un angle produit à un angle projet et vice et versa, du cerveau d'un client à celui d'un développeur et inversement."L'hypertexte transforme la mémoire de chacun en la mémoire de tous" (De Kerckhove, 2000), de même les hyperliens du wiki ont transformé la mémoire de chacun en une base de connaissances pour tous. Les recherches y sont facilitées et malgré que la page d'accueil soit la page la plus visitée, il n'en demeure pas moins vrai que techniquement le wiki n'a pas de centre. L'intelligence y est distribuée, l'information est enregistrée de façon simultanée à plusieurs endroits: "il n'y a pas de chemin qui mène à Rome, parce qu'il n'y a pas de Rome" (O. Brafman et R. A Beckstrom, 2006 p.53). Ce processus laisse émerger l'ordre sans l'imposer. De plus, la capacité naturelle à faire des liens, qu'offre le wiki à ses utilisateurs, lui permet d'évoluer dans le temps. Il est en continuelle mutation, on se souvient que "la modélisation se construit comme un point de vue pris sur le réel, à partir duquel un travail de mise en ordre, partiel et continuellement remaniable, peut être mis en oeuvre" (Le Moigne et Morin, 2007). Pour illustrer le troisième principe, on a vu que le wiki système de pilotage du projet Alpha a crû de façon organique pour devenir isomorphe du système projet qu'il pilote ajustant régulièrement sa variété (ex. Cas Z). La capacité d'évolution du wiki est favorisée par la convivialité d'utilisation et par l'absence de règle formelle, libérant l'utilisateur du système contrôlant dans lequel il évoluait précédemment. Ce constat renforce le quatrième principe morgannien. En simplifiant la complication du système d'information initiale et en modélisant dynamiquement la complexité du système, le wiki a ouvert une voie vers l'apprentissage en boucle double. Ainsi, il stimulerait l'apprentissage continuel (Morgan, 2006 p.85-86) et l'adaptation à l'environnement en permettant à la communauté de se réinventer dynamiquement (Andrus, 2005).

"Il fait quoi?" Le wiki concrétise la structure holographique et construit le tout dans la partie et la partie dans le tout. "Pour quoi?" Pour stimuler l'apprentissage en boucle double. "Devenant quoi?" Il devient un instrument de pilotage pour la gestion de projet.

4.2.3 À l'issu du projet de recherche

Le chercheur a quitté le terrain le 8 décembre 2008, la phase 3 du projet Alpha était alors en-cours d'achèvement. Nous avons peu de données depuis, mais avons tout de même trouvé intéressant de vous présenter ce qui suit.

En date du 8 décembre 2008, soit notre dernière journée passée sur le terrain, les statistiques du wiki étaient les suivantes:

Tableau 4.5: Statistiques wiki au 08.12.08

Nombre total de pages wiki	140
Nombre de versions	1990
Nombre moyen de version par page	14.21
Nombre de visite de pages wiki	12868
Nombre d'utilisateurs	20
1ère page la plus visitée (en nb de clics): page d'accueil projet Alpha	1805
2ème page la plus visitée (en nb de clics): base de connaissances du projet Alpha	914
3ème page la plus visitée (en nb de clics): page d'accueil de la phase 3	838
4ème page la plus visitée (en nb de clics): page d'accueil du suivi du pilote wiki	802

On voit que les chiffres continuent à augmenter par rapport aux statistiques du 20 novembre mais surtout que la base de connaissance a progressé à la 3ème place avec 914 visites. Ce qui renforce le constat que le wiki est devenu la base de connaissance du projet.

Nous avons aussi remarqué au moment de notre départ une intention de l'organisation de tirer les leçons apprises et les bonnes pratiques de ce pilote pour d'éventuelles futures applications. Un rapport final interne a été soumis à l'organisation à cet effet.

Le wiki est toujours actif à ce jour alors que la phase 3 a été clôturée depuis près d'un an. On peut en déduire que d'autres projets ont été gérés à l'aide du wiki, peut être par reproduction holographique. Ce que nous savons toutefois de l'un des collaborateurs c'est que si le wiki a été un succès en temps que pilote, il demeure un outil horizontal, dans une organisation de culture verticale. Ainsi ce premier succès n'a pas suffit à légitimer son déploiement à d'autres unités. Le wiki se heurte à une structure et surtout à une culture bureaucratique qui n'est pas encore prête à utiliser à grande échelle un outil favorisant une culture horizontale.

"Il fait quoi?" Le wiki engendre un changement de culture où la perspective horizontale interpelle la réalité verticale.

4.3 Synthèse

En agrégeant l'information le wiki réduit la complication du système d'information, c'est son premier fruit toutefois, ce n'est pas ce qui le distingue le plus. En effet, ses bénéfices les plus porteurs de valeur résident dans sa capacité à créer de l'intelligence collective par sa convivialité, sa capacité à faire des liens, soutenus par des barrières à l'entrée minimale de par sa structure horizontale, qui favorisent le partage, la redondance et les échanges d'idées fussent-elles antagonistes ou contraires. Le wiki "mobilise et coordonne les intelligences, les expériences, les savoir-faire, les sagesses et les imaginations" (Lévy P. 1997 p.12) de l'équipe projet.

En modifiant profondément les habitudes de travail le wiki met en évidence le phénomène de récursion. En éditant son contenu et sa structure, les utilisateurs le forme en retour. En somme si l'on paraphrase Morin, les utilisateurs produisent le wiki, lequel produit les utilisateurs (Morin 2005 p.100). Pour illustrer l'aspect perpétuel du phénomène récursif au sein du wiki, nous retenons la métaphore du tourbillon (ibid p.99). Ainsi, les flux d'information venant des utilisateurs circulent en boucle dans le wiki, l'information y est stockée, modifiée, enrichie, reliée, cette boucle est auto-productive, se produisant elle-même à partir du flux d'information. Mais cette boucle n'est pas fermée, car même si elle revient sur elle-même, du temps s'est écoulé, apportant son lot de changements, de nouveautés. C'est le même wiki, mais dans une nouvelle version, ce sont les mêmes utilisateurs mais enrichis de nouveaux savoirs, finalement, c'est la même organisation toutefois sa capacité à composer avec la complexité a augmentée. La boucle se boucle mais à un nouvel endroit et en attente du prochain.

En mémorisant dynamiquement le tout et les parties de différents points de vue, le wiki concrétise l'intelligence réseau en donnant aux utilisateurs acteurs un système d'information évolutif qui regroupe les intelligences au sein d'un collectif accessible à tous. Accessibilité, convivialité et flexibilité, servent une structure en continuelle mutation face à l'incertain et encourage une reproduction holographique différenciée (Morgan, 2006 p.104) où les parties cultivent leurs différences dans le tout et où le tout se retrouve dans les parties. Ces capacités d'adaptation permettent à la structure du wiki de s'ajuster à l'environnement projet et ainsi de disposer de la variété requise (Ashby, 1956) pour piloter le système projet. Des spécifications minimales, libèrent l'équipe des lourdeurs procédurales et favorisent l'auto-organisation. Celle-ci ouvre les portes à l'apprentissage en boucle double où l'utilisateur acteur remet en question les normes de fonctionnement, soutenue par l'épistémologie dialogique et la culture récursive.

Enfin, si nous tentions de résumer les interrelations constitutives du système wiki à partir des quatre questions de la modélisation systémique, nous pourrions répondre:
"Il fait quoi?": Le wiki "horizontalise" la culture organisationnelle
"Dans quoi?": Dans l'environnement projet
"Pour quoi?": Pour composer avec la complexité en gestion de projet
"Devenant quoi?": La mémoire collective de l'organisation projet