Le dernier diplôme que j’ai obtenu, le Doctorate in Business Administration (DBA) du Conservatoire National des Arts & Métiers (CNAM), a nécessité à la fois un travail de recherche et de capitalisation professionnelle afin d’aboutir à la rédaction d’un essai.
Sur trois ans, il a fallu m’organiser avec méthode pour, parallèlement à mon activité professionnelle, avancer à un rythme régulier sur mon livrable, et pouvoir reprendre rapidement le fil de ma pensée lors d’une pause de plusieurs jours.
Cet article a comme objet de présenter la méthodologie que j’ai employée durant ces années.
Le DBA m’a fait mettre un pied dans le monde de la recherche et j’ai pu découvrir des sources de documentation diverses, qu’il était possible de recenser au sein d’un outil nommé Zotero.org. C’est un des outils dont je me suis abondamment servi au cours de ces trois ans.
Recenser est une chose, mais pour assurer un cheminement intellectuel cohérent il faut également pouvoir lier les idées entre elles, la carte heuristique (également appelée “mind map” par les férus d’anglicismes) est la manière la plus confortable pour agencer ses idées. L’outil que je conseille dans ce domaine est Draw.io, qui permet de concevoir toutes sortes de diagrammes, notamment des diagrammes UML qui peuvent être utiles pour présenter des éléments de réflexion sous forme graphique, mais aussi une carte heuristique assez élaborée.
Voici pour la réflexion, mais il faut coucher celles-ci dans des écrits. Il est possible d’opter pour un traitement de texte classique de type LibreOffice ou Microsoft Word. Entre ces deux mon cœur de libriste opterait naturellement pour LibreOffice, mais il existe une alternative qui se prête mieux à l’exercice, à savoir le langage de programmation Latex. Se servir d’un langage de programmation pour rédiger un document peut paraître étrange, et cela peut rebuter ceux qui n’ont jamais codé de leur vie, mais c’est pour moi la manière idéale de rédiger un document, en particulier scientifique, quelle que soit la science. L’éditeur Latex que je préfère est TeXstudio.
Maintenant que nous savons organiser nos idées et les consigner dans un document, il est intéressant de versionner nos avancées. C’est là que l’outil de référence en matière de programmation vient à la rescousse: git. Ce gestionnaire de version permet de sauvegarder les différents états d’avancée des travaux. Il est ainsi possible de versionner son livrable, mais également sa carte heuristique et sa bibliographie. Il devient alors impossible de perdre quoi que ce soit. Mieux encore, il est possible d’avancer “par bouts”, en sauvegardant ses avancées partie par partie pour les fusionner ensemble plus tard. Cette possibilité est facultative mais ô combien intéressante.
Le corollaire d’une utilisation de git est l’utilisation d’une interface graphique pour gérer les versions de son travail, car utiliser des lignes de code pour ça peut être assez fastidieux pour un néophyte. Il existe deux possibilités: Gitlab ou Redmine (il y a également la possibilité de GitHub mais je préconise toujours des outils en source ouverte pour lesquels l’utilisateur peut être souverain en utilisant une instance qu’il maîtrise). Il n’existe pas de service en ligne Redmine: c’est un outil que vous devez installer sur un serveur. Si vous ne savez pas comment faire, préférez alors Gitlab, qui permet d’héberger des “dépôts” gratuitement. Ma préconisation est d’avoir un serveur Gitlab auto-hébergé, même si Redmine convient tout à fait pour cet usage.
Enfin, il est important de gérer les tâches à réaliser. Fort heureusement, Gitlab ou Redmine embarquent cette fonctionnalité.
De quel matériel je me suis servi au cours de ces trois ans ? Logiquement, d’un ordinateur, principalement, mais également de mon ordiphone (“smartphone”), qui me permettait d’avoir accès à mon Zotero, mon Gitlab et à des notes de mon reMarkable, outil qui a remplacé mon utilisation du papier.
C’est sans doute le seul produit dont je fais la promotion pour le travail (de manière bénévole!) car il est d’une praticité impressionnante: je peux écrire avec un stylet avec le même confort qu’un stylo sur du papier, taper au clavier si le besoin s’en fait ressentir et lire des documents grâce au mode “liseuse” qui permet d’écrire des annotations dans les PDF. Ce mode liseuse est bien utile lors des différents trajets en train ou réunion qui peuvent s’éterniser et qui constituent ainsi un bon créneau pour avancer dans le travail.
S’il s’agit d’un logiciel avec lequel il est très facile de réaliser des graphiques que vous pouvez intégrer dans votre document, c’est aussi l’outil que je préconise lorsqu’il s’agit de dessiner une carte heuristique, car il est libre, maintenu en condition par une équipe de développeurs solide et il permet de sauvegarder ses documents sous un format compatible avec le suivi des évolutions. Vous avez plusieurs types de cartes heuristiques à votre disposition:
La carte heuristique est vivante tout au long du projet, et il est utile de convenir d’un code couleur. Par exemple, lorsqu’une idée a été exploitée, il est possible de l’indiquer en l’encadrant en vert, comme ceci:
La carte heuristique est vraiment liée au cheminement intellectuel de votre réflexion, et son organisation doit être idéologique, par forcément liée aux différentes parties de votre document, car une idée peut se voir déclinée dans plusieurs parties. La répartition entre parties est plutôt du domaine de la bibliographie, gérée par Zotero.
Il faut se rendre sur Zotero.org et créer un compte, car ce qui est intéressant est non seulement de gérer ses lectures, mais également de pouvoir y accéder sur de multiples plateformes. Ainsi, si vous enregistrez une source sur un périphérique, il doit être possible d’y accéder à partir d’un autre périphérique.
À quoi en particulier sert Zotero ? Il permet d’enregistrer dans une liste les références d’un document (date de publication, titre, auteur(s), etc.). J’encourage vivement, lorsque cela est possible, d’enregistrer le PDF du document en question. C’est de votre liste Zotero que vous pourrez extraire automatiquement une bibliographie que vous pourrez intégrer sans difficulté dans votre production.
Lorsque vous enregistrez un document, il convient de le placer dans une arborescence organisée afin de pouvoir le retrouver. En effet, même si au début de vos travaux il y aura peu de sources à lire, au bout de plusieurs semaines ou plusieurs mois il deviendra compliqué de s’y retrouver. Voici donc la méthode que j’ai employée:
Créer dans “Ma bibliothèque” un dossier lié à votre projet; par exemple, dans le cas de mon DBA, j’ai nommé ce dossier “DBA”, sans grande originalité. J’ai placé dans ce dossier racine trois sous-dossiers:
Chacun de ces dossiers peut également être divisé en sous-dossiers. Pour “À lire” j’avais organisé ces sous-dossiers selon les thématiques. Pour les “Retenus” les sous-dossiers représentaient les parties et sous-parties de mon essai.
Voici des captures d’écran de Zotero dans l’utilisation que je préconise:
Il y a plusieurs manières de créer un document dans Zotero: soit vous le faites “à la main”, soit vous utilisez l’extension Firefox Zotero qui vous permet, lorsque vous êtes sur une page, de sauvegarder les metadonnées du document d’un seul clic sur l’icône “Zotero” en haut à droite de votre fenêtre. Vous pourrez sélectionner le dossier dans lequel le document sera placé. Je choisissais la plupart du temps “À lire”.
Puisque Zotero est utilisé pour gérer sa bibliographie, il serait dommage de se priver de la génération automatique de celle-ci: rien de plus simple, un clic droit sur le dossier “Retenus” puis “Exporter la collection” en choisissant le format “BibLatex” génère un fichier “.bib” qui sera intégrable directement dans votre document Latex.
Bien que développeur et habitué à utiliser des éditeurs de code tel que VSCode, pour la rédaction de mon document Latex j’ai opté pour TeXstudio, qui offre un confort de rédaction incomparable. En effet, vous pouvez obtenir le résultat de votre code immédiatement dans la même fenêtre et une table des matières sur la partie gauche pour une meilleure navigation:
Il ne faut pas que la partie du milieu vous rebute. En effet, sur cette capture d’écran il s’agit de la toute première partie du document, qui est une sorte de “phase d’initialisation”. On y intègre toutes les règles qui seront utilisées dans le document. Les parties textuelles sont infiniment plus simples.
L’objectif ici n’est pas de me substituer aux excellents cours de Latex mais de donner quelques pistes que j’ai moi-même utilisées. Par exemple, pour la bibliographie, voici ce que j’ai écrit en début de document Latex:
% DÉBUT BIBLIOGRAPHIE
\usepackage[style=authoryear-icomp,autolang=hyphen]{biblatex}
\addbibresource{essai.bib}
\DeclareCiteCommand{\citehyperref}
{\usebibmacro{prenote}}
{\usebibmacro{citeindex}%
\bibhyperref{\usebibmacro{title} \printtext[parens]{\printfield{year}}}}
{\multicitedelim}
{\usebibmacro{postnote}}
\DeclareFieldFormat[article,book,inbook,incollection,inproceedings,patent,thesis,unpublished,misc]{title}{\printnames[last-first]{author}\addcolon\space\textit{#1}\isdot}
% FIN BIBLIOGRAPHIE
Le fichier essai.bib
est celui qui était généré par Zotero.
La commande \citehyperref
me permettait d’intégrer une référence à un document sous le format que je souhaitais, avec un hyperlien pour la version PDF: ainsi, \footnote{\citehyperref{crozier_phenomene_1971}}
donne:
Pour la bibliographie, voici comment je l’intègre en fin de document:
\clearpage\begingroup\pagestyle{plain}\cleardoublepage\endgroup
\DeclareFieldFormat*[article,book,inbook,incollection,inproceedings,patent,thesis,unpublished]{title}{#1}
\chaptermark{Bibliographie}
\addcontentsline{toc}{chapter}{Bibliographie}
\printbibliography
\newpage
Un paquet que j’aime bien utiliser est celui des citations. Dans beaucoup de productions on voit fleurir des citations en début de chapitre. Mon essai n’a pas échappé à cette règle et c’est ainsi que j’ai déclaré en début de document:
% DÉBUT CITATION
\usepackage{epigraph}
\setlength{\epigraphwidth}{0.6\textwidth}
% FIN CITATION
Ainsi, le code suivant donnera:
\subsection{"Une force humaine"!}
\subsubsection{Replacer l'Homme au centre}
\epigraph{\textit{"La grandeur ne prend pas racine dans les cœurs secs.\footnotemark"}}{Sébastien Delmer, \emph{Le reste est facile}
}
\footnotetext{\citehyperref{delmer_reste_2021}}
Lors de la rédaction d’un document, les idées fourmillent et il faut noter tout ce qu’il ne faut pas oublier de faire: aborder une idée, acheter un livre, préparer un entretien, alimenter un schéma, écrire quelques lignes d’une sous-partie, etc. Tous ces exemples sont des tâches, qu’il faut consigner quelque part. Redmine et Gitlab se prêtent tout à fait à l’exercice. Redmine rebutera le moins tous ceux qui n’ont jamais eu à gérer de code car la gestion de tickets est le cœur de métier de cet outil, contrairement à Gitlab qui est destiné initialement à la gestion de code.
Encore une fois, l’utilisation de git fait l’objet de cours complets. L’objectif ici est de comprendre pourquoi un tel outil est pertinent dans le cadre de la rédaction d’un document. Je vais donner un exemple précis: vous avez ajouté une tâche qui était de lire et d’exploiter un document. Quand vous vous attelez à cette tâche, vous cherchez le document en ligne, vous l’enregistrez sur Zotero dans “À lire”, vous prenez des notes et récupérez des citations. Vous finissez par intégrer ce document dans les “Retenus”, générez donc une nouvelle version de votre bibliographie et faites évoluer votre livrable en ajoutant ce qui correspond à votre réflexion, après avoir agrémenté votre carte heuristique. Il y a donc trois éléments qui ont évolué. Vous allez donc sauvegarder ces évolutions en les liant à la tâche initiale, avec un commentaire qui précise les évolutions, comme par exemple “alimentation THÉMATIQUE XXX suite lecture LIVRE YYY”.
Pour aller plus loin, pour ceux qui ont envie de se lancer dans une utilisation experte de git, vous pouvez même utiliser le système de branches, qui permet de n’intégrer à la branche “master” uniquement ce que vous aurez validé de votre branche “LIVRE YYY”, par exemple.
Ainsi, vous aurez un historique complet de votre travail, en étant capable de repérer quelles parties ont été modifiées quand, comment et pourquoi. Vous pourrez revenir à un état particulier de votre document, de votre carte heuristique ou de votre bibliographie.
Si les explications ci-dessus sont encore un peu nébuleuses, il est temps de présenter l’intérêt des outils de gestion de code, qui permettent visuellement d’avoir un aperçu de l’évolution de vos documents.
Voilà par exemple sur Redmine un exemple de suivi:
On voit que le projet a été initialisé et qu’il y a eu des modifications suite à une lecture. On peut voir la différence entre deux versions, dans ce cas là il n’y a que deux versions au total donc c’est assez basique:
Je n’ai pas montré tout l’écran mais la carte heuristique (fichier *.drawio
), le livrable (fichier *.tex
) et la bibliographie (fichier *.bib
) ont été modifés.
À noter qu’il convient de ne garder que les éléments qui méritent réellement d’être suivis: ainsi, on ne versionne pas un PDF. On ne versionne pas non plus les fichiers techniques générés lors de la compilation de votre fichier Latex. Pour ce faire, il faut indiquer dans un fichier “.gitignore” l’ensemble des fichiers qu’on souhaite ne pas suivre. Voici une base, à laquelle vous pouvez ajouter ce que vous voulez:
*.acn
*.aux
*.bbl
*.bcf
*.blg
*.glg
*.glo
*.gls
*.ist
*.log
*.out
*.pdf
*.run.xml
*.synctex.gz
*.toc
*.bkp