Bon, j'espère que c'est la bonne cat.
 
Alors, il s'agit d'avoir un genre de wiki sur lequel on peut mettre les infos concernant les processus internes à l'entreprise, mais aussi des documentations techniques.
Il faut que cette solution puisse permettre à tout à chacun et donc AUSSI à Brigitte (Ah non c'est vrai que c'est macho   ) à Robert de la compta de pouvoir créer une page, éditer une page... Bref contribuer.
 
Alors jusqu'à présent dans ma boite, on a fonctionné de la manière suivante :
 
Avant mon arrivée il y a 6 ans :
dossier partagé qui contient un peu tout et n'importe quoi et où tout se perd et où personne ne sait vraiment où sont les choses, à part celles qu'on a soi-même mis dans le dossier (et encore...)
 
2 an après mon arrivée, j'ai installé un wiki : dokuwiki que je pensais être suffisamment simple à utiliser :
 
Bilan : les devs l'utilisent, et aussi les devs et... heu les devs ? Et en plus comme je suis passé CTO entre temps, ben ils vont pas dire grand chose. hé! pas stupides les guêpes.    
 
Bref, c'est un gros fail, c'est évident.    
 
Du coup, j'ai fait bcp de recherches là dessus ces derniers mois.  
 
Vu qu'on est passé sur Teams (on était sur Slack) et que tout le monde a son compte office 365 pardon Microsoft 365, je me suis dit que ce serait bien d'intégrer notre documentation interne à teams. Logique n'est-ce pas ?
Donc, j'ai commencé à me servir de l'App wiki fournies dans Teams...
 
Hélas ! Quelle ne fût pas ma stupéfaction de constater que des fonctions aussi bêtes qu'une recherche n'étaient pas encore présentes...   En parcourant les forums de Microsoft, je me rends compte que la feature est prévue... Depuis 2 ans...    
 
Du coup, je me rabats sur la "next obvious solution", j'ai nommé le célébrissime SharePoint. Avant c'était hors de question, mais maintenant c'est gratuit, c'est dans Microsoft 365 et il y a une app SharePoint dans Teams.
Alléluia, me dis-je.    
 
Après une petite semaine d'utilisation : impossible d'insérer du code dans les pages wiki, seulement dans les pages "normales" , et pas possible d'insérer "simplement" une barre de recherche dans les pages "normales" hein... Oui, parce que c'était pas assez vicieux, voyez... Il y a des solutions qui passent par modifier la master page truc muche pour insérer une librairie javascript pour convertir les <pre>, mais c'est bancal.  
 
Mais surtout : le copy / paste from Word c'est de la merde. Rigolo n'est-ce pas ? Et le système est LOIN, mais alors LOIN d'être user friendly pour Brigitte Robert de la compta.  
Sans compter que la plupart de mes devs sont pas franchement fans de SharePoint à la base, même sans connaître (j'avoues que je ne suis pas parti moi même avec des à priori super positifs sur ce produit)
 
Bref, c'est vraiment, mais alors vraiment pas la solution. J'imagine que c'est fait pour des grosses boites qui ont des mecs dédiés pour la doc.    
 
Alors du coup, me voilà Gros-Jean comme devant.    
 
Après d'âpres recherches de tous les wikis un peu connus, après avoir parcouru des tableaux comparatifs, je finis par trouver LE produit qui semble correspondre.
 
Il s'agit de BookStack. Je n'en avais jamais entendu parler avant il y a une semaine et j'ai du mal à comprendre pourquoi, car il coche toutes les cases :
 
1) Simplissime à utiliser, même pour Robert.
2) copy / paste from word correct en éliminant au passage toute la merde.
3) permet de mettre du code en forme
4) vrai WYSIWYG... Oui hein, parce que le markdown ou autre wiki truc muche, pas mal de gens chez nous ne veulent PAS en entendre parler et si on les force, ils diront rien mais n'utiliseront jamais le produit.
5) recherche très efficace.
 
Et l'organisation sous forme de livres, chapitres et pages qui est un truc VRAIMENT intelligent pour faire comprendre à Robert comment et surtout OÙ mettre les informations et où les chercher.
 
Pourriez-vous me dire ce que VOUS utilisez ? Juste pour voir si je ne serais pas passé à côté d'un autre produit miracle ?
 
Heu, avant de vous précipiter pour répondre à mon topic passionnant   , veuillez noter que seuls les produits open-source et réellement gratuits m'intéressent. j'ai une préférence nette pour les produits open-source.  

Bide du siècle.

Drap.

Joomla en non-officiel dans ma cogip (mais peu utilisé alors que ça fait le taf) et SharePoint en officiel (mais c'est une vraie merde, et je reste poli)

Je vais regarder ton bookstack

 
Merci pour ta participation. Je vais modifier le "open-source" requirement pour faire un peu vivre ce topic.  

Joomla est open source (c'est un cms concurrent de WordPress)

C'est un cms à tout faire. Pas spécialement orienté documentation (même si c'est comme ça qu'on l'utilise)
C'est moi qui l'ai installé, pour une équipe d'une dizaine de personnes (qui sont supposés le maintenir, c'est à dire écrire des articles), et une audience de quelques centaines (milliers ?) de lecteurs.

Mais au final, je suis plus ou moins le seul à le maintenir.

 
En fait, je ne parlais pas pour toi et je connais Joomla, qui effectivement comme tout CMS peut aussi servir pour cela.
 
Dans notre boite, seuls les devs et une ou deux autres personnes remplissent le Wiki, mais c’est laborieux. Quant aux autres, on a parfois du "j’ai oublié l’URL du wiki", ou encore "Comment je fais pour créer une page". Clairement, c’est bien trop dur pour eux, même si la première page du wiki explique comment faire.
 
D’après les retours qu’on a, c’est parce que, je cite : "c’est pas comme word” ou encore, je sais pas comment mettre un fichier ou une image etc...
D’où ma recherche d’un outil VRAIMENT simple sur ces plans précis.

dokuwikiMediawiki (le truc de Wikipedia) tout le monde connaît le front-end justement grâce à Wikipedia mais de mémoire pour la rédaction c'est une syntaxe particulière (ni html ni markdown ni bbcode, etc) et du coup c'est pas simple à prendre en mains.
Mais ça te garantie un truc un peu uniforme, alors qu'avec un éditeur Wysiwyg tu finis inévitablement avec des machins rouges sur fond jaune qui piquent les yeux.

Je sais pas ce qu'il est possible de faire avec un office online genre only office. Mais peut être qu'il existe un équivalent de SharePoint où tu peux écrire des documents avec un office-like mais avec un front-end web mieux (et plus ouvert ?) que SharePoint.

J'avais regardé un peu next cloud (qui peut intégrer only office en natif je crois). Mais c'est un peu lourd, et pas le but premier du truc.

Mon expérience sur le sujet, c'est que rien ne vaut le bon vieux répertoire partagé qui contient des fichiers word bien rangés (mais c'est pas simple de bien ranger et garder rangé).
Ensuite une indexation windows ou autre pour retrouver ses docs. Tant que l'indexation est capable d'indexer du word/ppt/pdf etc.
En terme d'interface c'est 0; mais c'est simple, facile à implémenter, à maintenir (par ex, une sauvegarde c'est une copie d'un folder...). ça peut gérer les versions si Windows le gère, les acl avec ntfs etc. Mais pour livrer au "public" (c'est à dire beaucoup de gens, mais pas nécessairement internet) c'est pas possible (à moins d'ouvrir large mais c'est pas top niveau sécu, même sur un intranet).

Enfin, tu as des usines à gaz genre alfresco mais on sort de l'open source, et pas sûr que ça soit plus simple que docuwiki ou autres...

Je suis en train de bosser sur le sujet. J'ai aussi testé pas mal de choses.
 
Le Sharepoint avec des blogs, c'est joli, ca permet de classer les infos avec des tags et une barre de navigation à gauche.
Mais cela prend trop de temps à gérer et trop de doc ne sont pas maj.
 
Le Sharepoint avec des sites/libraires, c'est ce qui est utilisé pour le moment, c'est basic mais ca fonctionne.
 
Il y a teams où les utilisateurs commencent à partager des infos.
Mais c'est rapidement le bordel, par exemple une personne vient de partir, son compte et supprimé.
Et on apprend ensuite que le service utilisait une conversation teams pour accèder au fichier de travail.
Et ce fichier fut supprimé avec la suppression du compte (ce fichier n'était pas partagé dans une équipe).
 
Il faut essayer de mettre fin aux fichiers words, car si on fait plein de petits fichiers, ce n'est pas mis à jour.
Si on fait un gros fichier, ce n'est pas forcément l'accès le plus simple à l'info.
 
Je teste en ce moment IT Glue, c'est pas open source, ca risquer de douiller.
C'est dans le cloud, comforme RGPD, pas de version on premise.
 

 
Il est composé de briques fixes (asset core) : Société, contact...
Et en dessous de briques personnalisables (fexible asset): AD, logiciels métiers, SQL...
 
Dans les flexibles assets, on peut utiliser les menus par défaut ou les personnalisés avec des champs que l'on peut pré-remplir.
 
On crée le document avec des blocs que l'on déplacer.
 
Le logiciel peut communiquer avec d'autres logiciels pour un inventaire des postes.
Il fait aussi gestionnaire de mot de passe, pour permettre de se connecter directement à un serveur.
Tout les accès et visualisation de mot de passe sont enregistrés.
Le logiciel à l'air très complet, orienté pour gérer les infras, mais on peut faire toute sorte de procédure et classement avec.
 
Sinon il y a Confluence et PassPortal de Solarwind à tester

Dokuwiki, c'est pas wikipedia. C'est Mediawiki
 
Perso, depuis quelques années, j'ai mis en place un wiki là où je bosse. Au fil du temps, j'ai appris pas mal de choses dans la gestion de la connaissance, notamment que le principal frein aux contributions n'est pas l'aspect technique mais que la plupart des gens pensent qu'ils n'ont pas le temps d'écrire des articles (même courts) et que s'ils filent des infos, ils vont perdre leur "pouvoir" (qu'on pourra se passer d'eux).
 
Bien sûr que si l'outil est vraiment pourri, ça va pas donner envie. Mais si l'outil rend vraiment service, apprendre 2-3 syntaxes de base wiki ne sera pas le frein.
 
J'ai mis en place Mediawiki avec plusieurs extensions vraiment nécessaires :
- faciliter de créer des redirections ou des nouveaux articles
- meilleur moteur de recherche que celui fourni de base (j'étais sur une v1.11, la v1.26 et les suivantes ont corrigé le pb)
- pouvoir insérer des google map interactives
- ajout de syntaxes complémentaires pour étendre les fonctions de base (ex : pouvoir faire des liens sur des fichiers du réseau)
- mais la plus importante est celle permettant de faire de la taxonomie. Ca permet de mettre des clés/valeurs sur chaque article et de pouvoir ensuite créer des articles listant dynamiquement des articles en fonctions de critères de recherche (un peu à la SQL). J'ai d'ailleurs beaucoup améliorer les possibilités de cette extension. Elle permet maintenant de pouvoir faire afficher la signification d'un acronyme un info-bulle du lien menant à l'article sans devoir cliquer pour voir la signification. Ca permet aussi, dans des aplpis métiers connectées à ce wiki, d'enrichir la description d'un ticket en ajoutant des liens vers les articles du wiki quand ils existes et de mettre aussi en info-bulle la signification d'acronyme (très pratique pour intégrer des nouveaux dans un service)
 
Important aussi : dès le départ, donner une structure au wiki et que le mode d'emploi des fonctions et de la syntaxe soit directement intégré dans le wiki. Et quand des articles d'un même type émergent, les standardiser, en faire des templates que l'utilisateur pourra précharger afin de le guider dans la rédaction.
 
Aujourd'hui, j'ai plus de 3800 articles.
 
Si ça t'intéresse, j'ai fait un PPT sur la façon de mettre en oeuvre une gestion de la connaissance et les pièges à éviter. Je me suis basé sur mon retour d'expé (9 ans) et sur un bouquin sur les wikis en entreprises qui disait "Personne ne sait tout, chacun sait quelques chose". A noter que la puissance d'un wiki est égal au carré du nb de ses contributeurs.
 
Edit : ah oui, pour que la gestion de connaissances ne soit pas reléguée à la fin de tout, mettre une ligne d'imputation dans le CRA de chaque collaborateur si vous faites des imputations de temps. Ca permet d'être valorisé. Et pour l'accessibilité, elle doit être transverse à tout : outils et processus. Ca commence donc par une intégration du moteur de recherche dans le navigateur web (notre SI a intégré mon wiki en tant que moteur de recherche de Firefox au même titre que Google ou Wikipedia). Ainsi, personne peut dire : c'est quoi l'url du wiki ? Il tape sa recherche dans le navigateur et il y va.

J'ai testé Confluence et Sharepoint. Aucun des 2 ne permet la souplesse de ce que je peux faire avec Mediawiki et les extensions ajoutées et surtout, ils ne permettent pas de faire de taxonomie qui est la pierre angulaire (avec un bon moteur de recherche) d'une gestion de connaissances efficace en entreprise.
 
Edit : et dokuwiki est bien trop limité. Je l'utilise à titre perso et je vois le gouffre avec Mediawiki.

 
Ton témoignage est intéressant et je vais regarder ton PPT.
 
Je pense que chaque boite est différente. Le problème qu’on a chez nous, c’est qu’on a une équipe technique qui jouera n’importe quel jeu que je proposerais, mais pour le reste de la boite, c’est au bon vouloir des autres managers qui eux en plus n’ont vraiment pas d’autorité sur leurs troupes.
On a vraiment cette fois-ci pris le temps de demander à tout le monde le pourquoi du fait qu’ils n’utilisent pas le wiki, et les réponses sont extrêmement claires :
- On ne sait pas où est le wiki, on finit par oublier etc... (Solution : l’intégrer dans teams qui est constamment ouvert sur leur bureau)
- Quand on veut ajouter quelque chose, on a peur de tout casser. Il faudrait que ce soit comme Word, on ne veut pas apprendre quoi que ce soit de différent, on a pas le temps etc...
 
Ce sont clairement ces deux grands axes sur lesquels on travaille. On sait qu’on arrivera pas à imposer un wiki avec une syntaxe wiki ou autre markdown même si l’apprentissage requis nous semble ridicule. Comme je l’ai dit, si on persiste dans cette voie, on aura comme maintenant une partie seulement de la boite qui participera. Le principe même du wiki est trop compliqué et on a aussi des réactions un peu “épidermiques” au point qu’en fait, le mot même “wiki” est rejeté par certaines personnes (Des personnes non “techies”)  
Je pense que cela explique largement le succès de “confluence” dans énormément de boites. J’ai testé et je pense voir le problème.
 
C’est pour cela que je fonde de grands espoirs dans BookStack qu’on va tester avec les personnes les plus réfractaires en premier. On ne va pas présenter cela comme un wiki. Ils se loggeront en SSO office, et pour éditer une page, c’est litéralement comme word. Ils cliquent sur edit et ils éditent le document. Il n’y a AUCUNE courbe d’apprentissage. Du coup, on verra les réactions.

Je suis preneur du ppt ausso

Drap

Là où j'ai mis en place ma BD de connaissances (Mediawiki), c'est un environnement plutôt technique. Du coup, la syntaxe de base du wiki n'est clairement pas le frein à la contribution.
Comme dans ton cas, y'a peu de possibilité d'imposer une solution ou de faire contribuer les gens (administration, plus de 1000 personnes, bref le management, c'est pas facile). Du coup, j'ai fait du bottom-up. Y'avait (et il y a toujours) un réel besoin de partager des infos. Mais peu de volonté de trouver une solution et de la mettre en place. La gestion de la connaissance est vue comme un centre de coût et non comme du gain de temps car c'est assez difficile à mesurer.
Du coup, j'ai peu de contributeurs mais ceux qui ont compris l'intérêt s'y sont mis et sont devenu des contributeurs réguliers.
 
Encore une fois, même si je suis d'accord sur le fait que l'outil doit être le plus simple pour permettre à tous de contribuer et que chaque boîte a sa culture, sa logique de fonctionnement, l'aspect technique n'est clairement pas la vraie raison de pourquoi on contribue pas même si c'est souvent l'excuse qui est donnée.
 
Comme expliqué, je me suis mis à la gestion de connaissances il y a 9-10 ans et en discutant avec pas mal de monde là où je bosse mais aussi ailleurs (caisse de retraite, CNES...), j'ai pu constater des similitudes de comportements et compris que les freins étaient avant tout psychologiques et organisationnels. Les gens ont tellement la tête sous l'eau que lorsque tu leur demande d'écrire un petit article de quelques lignes sur un sujets, ils te diront un truc du genre :
- là, j'ai pas le temps, mais quand j'en aurais, je le ferai. ---> sera jamais fait car la personne pense ne pas avoir le temps pour ça
 
- pourquoi je vais écrire là-dessus, je connais déjà ces infos --> difficile d'écrire pour les autres, sentiment de faire ça pour rien. Mais ne comprend pas que si chacun écrit pour les autres, alors on va avoir plein de contenu, d'où la formule du N² (N = nb de contributeurs).
 
Une autre raison jamais dite ouvertement, c'est la peur de perdre du pouvoir en partageant des infos car la personne croit qu'on pourra se passer d'elle si elle transmet ce qu'elle sait.
 
Le livre en question qui m'a pas mal aidé : https://www.eyrolles.com/Informatiq [...] 952051446/
 
Autre piège : mettre en place un outil mais avec quasi aucun contenu en pensant que les gens vont l'alimenter. Les gens vont contribuer que dans un outil qui paraît actif donc avec du contenu. Sinon, ils penseront créer du contenu pour des prunes. Au début, il faut donc 1 à 3 personnes qui vont mettre quelques centaines d'articles. Ca peut être juste la signification d'acronymes. Ca prend 30 secondes par article.
 
Par rapport à "tout casser", il faut rassurer les gens en disant qu'ils se concentrent sur le fond, pas la forme afin de ne pas perdre trop de temps. Charge d'avoir un "jardinier" : c'est une personne qui voit passer les articles et vérifie qu'ils respectent la charte (pas de trucs confidentiels, pas de propos désobligeants, ...) et remet en forme si besoin est pour homogénéiser la présentation et vérifie que l'article ne fait pas doublon avec un autre. C'est très important ce poste car sinon, en quelques semaines ou mois, ton wiki va partir en sucette, ça sera le bazar.
 
Et rappeler que si l'article est trop mis en vrac, pas de souci, il suffit de restaurer la dernière version correcte puisque dans un wiki, tout est historisé. C'est d'ailleurs très pratique pour faire des DIFF entre 2 versions et voir ce qui a changé, chose impossible à faire entre 2 docs word.
 
Enfin, demander aux nouveaux arrivants de faire part de leurs remarques sur le wiki qui leur aura servi en partie à se former pour l'améliorer en contribuant (ex : écrire un article qui manquait, corriger un article qui n'était pas à jour, genre un lien cassé...).
 
Pour le PPT, faut que j'anonymise certaine choses et je vous le mettrai à disposition. J'ai pas la prétention de tout savoir mais je pense que ce que j'explique et propose est assez généralisable.

 
ça, c'est une ÉNORME différence entre ton cas et le mien. Dans notre cas, on doit absolument faire en sorte que tous les départements contribuent, y compris les moins techniques d'entre eux et la boite est trop petite pour avoir un ou plusieurs référents par département.
Mais il est clair que ton exp m'intéresse et je vais voir le libre que tu indiques etc...

C'est la misère pour faire contribuer les gens.
Et le nombre de fois où ils se plaignent de ne pas trouver la doc.
 
Quelque soit l'outil, je pense que le probleme sera toujours là.
Quand tu fais de la doc, tu bosses pour les autres.
La plupart des gens préfèrent ne bosser que pour eux.

 
En fait c'est ce que j'ai pensé pendant longtemps. Mais c'est la solution de facilité de penser cela.
 
Déjà, le fait qu'on utilise maintenant Teams et que tout le monde est forcé de l'utiliser vu qu'on est maintenant tous en remote, change un peu la donne, car tu peux rajouter des tabs aux channels en incluant des sites webs. Du coup, ils ne peuvent plus se plaindre de ne pas trouver la doc, parce qu'elle est incluse dans Teams. On a fait l'expérience avec dokuwiki qu'on a inclu dans teams, et on a eu des employés qui ont été surpris de "redécouvrir" qu'en fait, on a une doc. (Oui, des baffes se perdent.   )
S'en est suivi rapidement un "ouin, ouin, mon password, mes credentials, ouin ouin..." (alors qu'il est écrit: Forgotten your password? Get a new one: Set new password, et qu'il suffit de cliquer dessus.   )
Maintenant avec BookStack, ils n'auront plus cette excuse ces bâtards, car on va mettre en place le SSO avec leur office account.    
 
Donc la mauvaise foi n'aura plus qu'un ultime argument : "ouin, ouin, c'est pas comme word   "...  
 
Sauf que... Si c'est comme Word.    
Donc si tu contribues pas, c'est que tu le veux pas... Du coup, on va pouvoir tranquillement mettre des sanctions en place (déjà discuté entre nous, les managers   )

Tout à fait, les gens ont du mal à comprendre que bosser pour les autres, c'est bosser pour eux aussi puisqu'ils vont bénéficier du travail des autres.
Mettons que tu as 4 contributeurs. Si chacun écrit 2 articles (pour les autres), il en récupères 6. C'est donc très avantageux et, au final, ils gagnent plus que ce qu'ils donnent. Mais beaucoup ont du mal à le comprendre.

 
Des sanctions à base de bonus moins bons sont une excellente manière de leur faire comprendre... Mais avec les autres managers et le boss, on a décidé qu'on voulait être sûr qu'ils n'aient plus aucune excuse.

Je trouve cela bien la fonctionnalité pour voir les gens qui prennent du temps pour documenter.
Comme cela quand des gens viennent te voir et te disent pourquoi y a pas de documentation là dessus ?
Tu peux lui montrer qu'il n'a pas du tout participé.
Même si je sais déjà la réponse que je vais recevoir : oui, mais j'ai pas le temps, j'ai trop de boulot.
Si on faisait le test entre prendre un peu de temps pour documenter et chercher une info pendant des heures, le choix est vite fait.
 

Oui, c'est bien de faciliter au maximum la prise en main et l'utilisation d'un outil de gestion de la connaissance. Mais je te fais le pari que ceux qui ne contribueront pas te diront que c'est pas qu'ils veulent pas mais que c'est parce qu'ils n'ont pas le temps. Certains seront de bonne foi, c'est juste qu'ils ont du mal à voir que le temps qu'ils ont passé à trouver une info (mettons 15 min), ils peuvent le faire gagner à d'autres qui la chercherons peut-être aussi. S'il prend 5min pour écrire vite-fait un petit article, il aura "perdu" 5 min mais aura fait gagner 15 min x nb de personnes qui cherchent l'info. Du coup, pour ça représente un gros gain de temps.
 
Par contre, je ne de recommande pas d'aller sur la voie de la contrainte et des sanctions sous peine d'avoir une grosse levée de boucliers ou de contributions bidons (ah ok, on nous oblige à créer 5 articles par semaine, je le fais mais c'est des articles bidons qui ne servent à rien). Les réfractaires, faut les isoler et laisser les autres s'approprier l'outil et que l'outil prouve son efficacité, qu'il fasse tâche d'huile. Le mieux c'est de trouver dans chaque service au moins une personne qui est motivée. Tu la forme et l'aide au maximum. Ensuite, par sa simple expérience, elle convaincra les autres de son service. Mais t'auras jamais 100%.
 
La gestion de la connaissance, ça doit être bienveillant et valorisée. Ex : dans son compte-rendu d'activité, mettre une ligne d'imputation dédiée pour permettre à chacun de montrer le temps passé à cette activité. En effet, sans cette ligne, le temps passé ne sera pas visible. Donc, ça laisse penser qu'on attend de la personne de continuer à faire son taf habituel et en plus, cette nouvelle activité de gestion de la connaissance dans le même volume horaire. Les gens refuserons.

Oui, tout à fait, dans mon wiki, j'ai mis aussi une stat sur les contributeurs. Ca peut être motivant. Toutefois, certains sont timides. Alors avoir des comptes génériques, ça peut être pas mal aussi pour avoir une certaine anonymisation des contributions. Là, ce choix dépend du management et si y'a des incitations à contribuer.
 
Et surtout pas de circuit de validation/approbation du contenu. C'est le meilleur moyen de couper l'envie aux contributeurs. Une contribution (par ex, corriger une petite erreur), ça doit pouvoir se faire en moins d'1 min.
Et à ceux qui me sortent l'argument de la validité de l'info, un circuit de validation/approbation n'a jamais empêcher d'avoir des erreurs (même monstrueuses) dans un document validé. Par contre, sans circuit, même s'il y a des erreurs, si le nb de contributeurs est important, l'article va rapidement converger vers une version sans erreurs, bien plus vite qu'avec un circuit en tout cas. En plus, ces personnes chargées de faire les validations seront un goulet d'étranglement. Les articles mettront du temps à être disponibles, ça frustra les auteurs.

 
C'est une excuse qui ne sera certainement pas recevable, car ça fait partie de leur rôle officiellement, c'est absolument pas "en option". Le boss a été très clair là dessus.
 

 
J'étais pas trop "pour" les sanctions. En fait, je suis dans le camp de ceux qui veulent vraiment être sûrs que toutes les conditions sont réunies pour que les employés sans aucun bagage technique puisse contribuer. Mon boss était d'avis de prendre des sanctions en laissant dokuwiki. Moi et deux autres managers, on l'a convaincu qu'on devait d'abord pouvoir prouver que la non-participation relève exclusivement de la mauvaise foi.  
 

 
Elle est déjà valorisée sur nos PMOs (Project Management Objective). Elle fait partie intégrante de l'évaluation individuelle des employés et de l'équipe. Donc ça c'est déjà en place. Le problème, c'est qu'on a des personnes qui se retranchent derrière le fait que "c'est trop compliqué". Personne n'invoque le manque de temps, parce que la documentation des processes fait partie des attributions officielles à la signature du contrat.

Petite question : comment vous gérez la maintenance ? Ou plutôt : le cycle de vie de vos docs ?
Dans mon cas, on a plein de docs qui sont obsolètes (soit les infos dedans sont devenues partiellement correctes, soit la doc n'est plus nécessaire du tout car un truc a été décommissionné).

Pour l'instant j'ai 2 (mauvaises) solutions :
- attendre que les utilisateurs soulignent le fait qu'un truc est faux (et ils ne le font pas tous)
- corriger au petit bonheur quand par hasard on tombe sur un truc faux.

On a tenté il y a quelques années de revenir systématiquement sur toutes les docs tous les 6 mois. On l'a fait une fois... Puis le chef a changé, et les outils de doc aussi.

Vous faites comment vous ?

Bon, j'ai anonymisé ma présentation en prenant un template de base de Powerpoint, en supprimant certaines références : http://chjav.free.fr/data/V1R0-PPT_Wiki.pdf
L'important, c'est le contenu, pas la forme.

Effectivement, c'est pas simple d'autant que dans certains cas, conserver une doc obsolète peut malgré tout être utile (par ex, pour comparer avec celle existant qui pourrait poser pb alors que pas l'ancienne version). Dans ce genre de cas, dans le wiki, j'ai créé un template "obsolète" que tu mets en début d'article pour avertir l'utilisateur.
Dans le cas d'un wiki, si t'as pas mal d'utilisateurs, ça peut être détecté rapidement et cet avertissement d'obsolète peut être mis par un utilisateur.
 
Si conserver le document n'a pas d'intérêt, soit l'archiver soit le supprimer. Là, c'est au responsable projet de faire le nécessaire je pense.
 
Si la durée de validité est connue à l'avance et si l'outil le permet, mettre une date d'expiration ou de rappel automatique pour aller faire la vérif le moment venu.

Si le processus de gestion de la connaissance est déjà un processus identifié, mis en place de manière transversale aux autres processus et est valorisé car faisant partie intégrante de vos activités, bravo, vous êtes une boîte bien avancée. J'ai vu peu de boîtes où c'était le cas
Moi, ça fait des années que j'essaye de le faire comprendre autour de moi dans ma boîte avec peu de succès Tout le monde est d'accord avec moi sur le principe mais ça bouge pas beaucoup...
Après, chez mon client, vu que je suis prestataire, difficile de les obliger à contribuer. Déjà que certains sont pas fans de mon wiki car en étant seul, j'ai pu proposer une solution qui coûte quasi rien et qui fonctionne en répondant aux principaux besoins alors qu'eux avaient mis en place des trucs chers qui marchaient pas . Me manque plus que de la volonté politique pour augmenter le nb de contributeurs.
 
PMO : pour moi, c'est project management office.

le cycle de vie des docs ? ben y en a pas.
Quand je vois que c'est plus utile je dégage à la main.
Et la doc sur office 365, c'est horrible à faire, ils changent tellement souvent les choses.
Je suis sûr d'avoir plein de docs à supprimer.
 
Mais la doc ca n’intéresse pas beaucoup les responsables.
Je suis commissionné sur le temps que je facture au client.
Dés que je fais de la doc qui prend du temps, je sais que je n'atteindrai pas les objectifs.
Et je ne vais pas faire passer cela sur le compte du client.

Heu, la doc fait partie d'une prestation, non ?
Ex : tu développes un logiciel, ben la spec, dossier de conception, manuel d'exploitation et manuel utilisateur au minium doivent être fournis avec le logiciel. Un cahier de recette n'est pas inintéressant non plus
 
Si c'est plus de la prestation intellectuel, y'a au moins un CR ou un rapport qui doit être fourni.
 
J'ai du mal à imaginer une prestation à un client qui nécessiterait de rédiger une doc mais qui ne serait pas prévue au contrat

C'est des docs prévues pour un usage interne.
ce n'est pas dans le cadre d'une prestation spécifique.

 
C'est une excellente question.
 
Une solution est de mettre un reminder une fois tous les 6 fois individuellement sur les docs qui s'applique sur celui ou celle qui a rédigé l'article. Si la personne n'est plus là, il faut penser à avoir un process de ré-attribution des docs écrites par la personne qui part vers la personne qui arrive.
 
C'est une chose que je compte mettre en place avec BookStack, car c'est une solution opensource basée sur symfony.

D'ailleurs, à ce sujet, je vois que Rufo parle de doc "en général" y compris pour un usage public. Moi je parle depuis le départ effectivement de doc INTERNES donc, typiquement de type "confluence".
 
Mais on peut très bien étendre le topic à tous les types de documentation.

Moi, je ne fais pas de distinction de doc client, public, interne. A mon sens, le process doit rester le même, c'est juste les destinataires qui changent et sans doute le lieu de stockage des docs.

Pour moi je sépare bien les 2.
La doc interne peut contenir des informations confidentielles à ne pas transmettre au client.
On y retrouve les procédure, les modèles de fichier.

 
Nous aussi. La grosse différence dans notre cas, c'est surtout que les doc publiques sont liées à notre système de support pour les customers alors que les docs internes, non bien sûr.

Je ne dis pas le contraire puisque j'ai indiqué dans mon post que les destinataires des docs étant différents, leurs emplacement de stockage l'était probablement Je dis juste qu'au niveau process, notamment concernant la gestion de l'obsolescence, y'avait pas de raison de faire la distinction. Y'a juste à prendre en compte qui a accès à quoi. Mais ça, pour moi, c'est l'outil de GED qui s'en charge, pas l'outil de gestion de la connaissance.

Quelle est la différence ?

Une GED est un outil permettant de stocker des documents, de gérer les droits d'accès et le workflow de diffusion ainsi qu'éventuellement le processus d'archivage.
 
Il existe aussi des outils de communication internes ou externes à l'entreprise (ex : des blogs). Ca, c'est le processus de communication.
 
Le processus de la gestion de la connaissance gère le patrimoine intellectuel, les connaissances explicites de l'entreprise (les connaissances implicites et le tour de main ne pouvant être stockées dans un outil). Bien entendu, de nombreuses connaissances se trouvent dans la GED et parfois, sur les supports de communication.
Tout l'intérêt d'un outil de gestion de la connaissance est de capter et organiser l'accès aux données de la GED, des supports de com et d'autres sources (certaines connaissances qui sont "tracées" nul part ailleurs que dans la tête des employés, par ex).

Euh... Ok. Si je comprends bien, le stockage des documents d'un côté, et la mise à disposition de l'autre.

Pour moi tout ça devrait être le même outil (idéalement)

Peut-être que BookStack permet de faire du multi-entreprise.
Comme cela on peut gérer l'interne et les clients depuis la même console.