Temps de lecture : 5 minutes

Communication technique : rester flexible

Pour un projet de communication technique, les ressources et intervenants sont multiples. Du rédacteur à l’origine des contenus au développeur chargé de les traiter, il y a souvent différents services, et différentes priorités.

Les priorités de chacun

Un chef de projet R&D mettra naturellement l’aboutissement de son prototype bien avant la préparation d’une formation. Pourtant, sans formation, pas d’utilisation correcte ou de montage adapté. Un compromis doit être trouvé.

Il est rare dans la communication technique que des objectifs clairs soient transmis. C’est le plus souvent à vous de les définir strictement. La communication technique couvre plusieurs secteurs d’activités et compétences, une vue d’ensemble se dégage difficilement avant que vous ne preniez le projet entièrement en main.

Les vieux dossiers

Quoi qu’il en soit, avant de commencer à rédiger, illustrer ou coder, inventoriez tout ce qui peut être réutilisé. Les fichiers CAD, les notes relatives à un développement, et faites le point sur ce qui a déjà été mis en place ou tenté de l’être.

Vous serez à même de savoir si un tel projet a déjà été lancé et peut-être abandonné ou si d’autres départements utilisent déjà leur propre système. C’est souvent le cas pour des WIKIS, des routines Excel et tous les petits outils mis en place pour se simplifier la vie et parfois par manque de budget.

Posez des questions et confirmez une compréhension mutuelle de ce qui doit être fait. Évitez de froisser ceux qui ont déjà œuvré avec ce dont ils disposaient. Pour ne pas retomber dans d’anciens travers et pour vous assurer de la bonne collaboration de chacun.

Expertise et expérience

communication technique - codeBasez-vous autant que faire se peut sur un projet de communication technique similaire pour les estimations de temps. Un logiciel, un manuel ou encore une plate-forme de formation, les similitudes ne manquent jamais, même si l’objectif n’est pas le même. Identifier ce qui a déjà bloqué votre avancement et prenez cela en compte : intervenant ou collaborateur soudainement absent, état d’avancement d’un autre secteur sur évalué …

Ne sous-estimez jamais votre optimisme ou l’optimisme des membres du projet : rien n’est jamais vite fait ou facile dès que l’on rencontre un imprévu ou que les priorités changent.

Ces points bloquants qui retardent tout le projet

Un diagramme de Gantt offre une excellente visibilité. Quel point est bloquant ? Si cette information ou validation n’est pas faite, le projet prend-il du retard ? Quelle autre tâche peut par contre être effectuée en parallèle?

Cet outil précieux permet entre autres de définir le chemin critique. La succession des points bloquants. Déplacer un point bloquant augmentera la durée de votre chemin critique.

Deux cas concrets :

  1. La validation du service réglementaire qui ne laisse pas passer des aspects juridiques qui ne peuvent pas vous venir à l’esprit.
  2. Une difficulté technique à surmonter sans connaître le temps que cela prendra : une portion de logiciel jamais réalisée comme un générateur de PDF sur une base de données non structurée, une extraction de contenu multilingue dont le balisage change soudain dans un très ancien document.

Collaboration

Même en y mettant toute votre bonne volonté – ce que vous ne manquerez pas de faire, votre travail dépend des efforts des autres. Motivez, orientez et donnez un retour d’informations aux personnes qui travaillent avec vous. Dans un projet de communication technique, c’est un défi. Des personnes ayant différents niveaux d’autorité, de compétences et provenant de différents horizons doivent collaborer en poursuivant leurs propres objectifs.

Vos meilleurs alliés en matière d’autorité en tant que responsable de la communication technique (d’un projet tout du moins) sont vos « commanditaires » et un cahier des charges bien établi. Mais également un tact certain et une bonne dose de la diplomatie.

Testez !

Un contrôle régulier des tâches déjà réalisées s’impose en continu. N’hésitez pas à faire un crash test. Vous vous mettez dans la position de l’utilisateur final, et vous tentez de comprendre et de faire « fonctionner » une portion de projet validée. Concrètement, on vous certifie que les informations sont faciles à retrouver et correctement référencées. Faites « l’idiot ». Posez des questions triviales à vos collaborateurs « comment retrouver ceci ou cela, on m’avait dit que ça devait faire ceci ». Vous serez parfois surpris des réponses qui vous sont faites. Une des plus courantes est « Ah ça ? Ce n’est rien, je sais que ce contenu est ici et ici. ». Et comme ni vous, ni l’utilisateur final de dispose d’un accès direct au cerveau de votre collaborateur…

Résumons

Naturellement, pour gérer un projet de communication technique, il faut que délais et le budget soient tenus. Ensuite, il faut que les attentes du client soient atteintes dans un contexte souvent sujet à interprétation :

  • Clarifiez, éliminez tout risque d’interprétation de l’objectif.
  • Planifiez et identifiez les points bloquants qui pourraient retarder l’ensemble
  • Laissez une bonne marge de manœuvre, vos estimations sont en général 20% trop optimistes
  • Réfléchissez attentivement aux solutions à mettre en œuvre avant de commencer votre travail
  • Changez votre fusil d’épaule si un point bloquant l’est trop longtemps : solution alternative, contournement pour permettre d’avancer en parallèle
  • Faites l’utilisateur : mettez-vous à la place de votre client – attentes d’une formation, clarté d’un processus, utilisation d’un logiciel.

À intervalles réguliers, « faites » ce à quoi l’utilisateur final s’attend selon le cahier des charges et votre compréhension (suivre une procédure, rechercher un contenu, assembler un document, reproduire une vidéo). Si vous ne le pouvez pas, il ne le pourra pas et c’est le moment de re cadrer.

Génie logiciel et communication technique

Durant les cours de génie logiciel ou de conduite de projet, on vous apprend à planifier. 70% de votre temps consacré au projet devrait consister à analyser et dialoguer. La planification faite, on s’y tient et le projet est sur des rails.

Cependant, il n’est pas rare de vous retrouver face à des besoins changeants ou nécessitant une adaptation de votre propre interprétation, de vos outils. La communication technique est multiple, un choix fait hier peut être remis en question demain pour diverses raisons techniques ou structurelles. C’est pourquoi l’extrême programming (XP) est à bien des égards une meilleure approche. Un point régulier, tous les jours avec les collaborateurs, toutes les semaines avec le client et un morcellement du projet en taches pouvant s’imbriquer et s’interconnecter évitent de repartir de très loin.

Dernier exemple concret

Vous avez choisi de segmenter vos documents en sujets (topics) très segmentés. Vous avez choisi comme outil un éditeur visuel permettant de publier dans différents formats.

Vos collègues ont repris 10% de contenu et vous générez une première interface web de test. Vous vous rendez compte que l’éditeur est incapable de produire un document web cohérent, car les contenus sont trop segmentés. Chaque page est un tout petit contenu difficile à mettre en rapport avec son prédécesseur sans changer de page.

Quel est le pivot qui permet de passer de petits morceaux de contenus bien structurés à des contenus regroupant 2, 3 ou 4 topics tout en conservant une flexibilité maximale ?

Changez de générateur et concevez des « tables des matières » intermédiaires. Reproduisez le fonctionnement d’une « BOM » et développez un générateur capable de sélectionner différents niveaux de BOM.

Comment cela vous ferait gagner du temps par rapport à une refonte du contenu ? Simplement parce qu’un contenu propre et identifié se manipule facilement. Un développement de 20 heures vous fera gagner des semaines à l’avenir.

En un exemple, nous sommes passés de la rédaction à la programmation, c’est tout l’intérêt d’un projet de communication technique, sa pluralité.