Contrôle de version d'organigramme : comment cela fonctionne réellement

En bref

• Un nom de fichier tel que "v3_FINAL_reviewed(2)" est une supposition, pas un historique des versions.
• L'exportation PDF ou PNG conserve une image de l'organigramme, et non sa structure modifiable.
• La gestion des versions des fichiers du stockage cloud suit le fichier, et non les boîtes et les connecteurs qu'il contient.
• Le contrôle de version réel de l'organigramme différencie les modifications de la boîte, du connecteur et de l'étiquette entre deux états enregistrés.
• Le journal des modifications et la comparaison des versions de QueryChart le font automatiquement sur chaque graphique, gratuitement : voir /features/version-control.

Un nom de fichier n'est pas un historique de révision

Quelque part sur un lecteur partagé se trouve actuellement Process_Map_v3_FINAL_reviewed(2).vsdx, à côté de Process_Map_v3_FINAL_reviewed.vsdx et d'un Process_Map_v2.pdf qu'une partie prenante a toujours joint à un ancien fil de discussion. Entre les trois, il n'y a aucune trace de quelle boîte a été déplacée, quelle branche de décision a été réétiquetée, qui a effectué la modification ou si quelqu'un l'a réellement signé : seul un nom de fichier faisant le travail qu'un historique des versions est censé faire.

L'exportation d'un organigramme vers une image ou un PDF pour l'archivage capture à quoi il ressemblait, mais cela supprime la seule chose dont un lecteur ultérieur a besoin : la structure modifiable en dessous. Un PNG ne peut pas être comparé à un autre PNG pour montrer qu'une boîte de décision a gagné une troisième branche : une personne doit regarder deux images et deviner. Le propre « historique des versions » d'un lecteur cloud ne résout pas ce problème non plus : il versionne le fichier, pas le diagramme qu'il contient. Il peut restituer le .vsdx ou .pptx d'hier, mais il n'a aucune idée qu'une boîte spécifique a déplacé des voies ou que l'étiquette d'un connecteur est passée de « Escalader » à « Approuver automatiquement » entre deux instantanés.

Un outil de création de diagrammes avec un véritable contrôle de version fait trois choses qu'un nom de fichier et un lecteur partagé ne peuvent pas : il vous permet de parcourir chaque révision passée du diagramme lui-même, il montre exactement quelle boîte, connecteur ou étiquette a changé entre deux d'entre eux, et il restaure un ancien état sans perdre le travail effectué depuis. QueryChart le fait sur chaque graphique, en direct, automatiquement et gratuitement : le journal des modifications enregistre chaque modification avec qui l'a effectuée et quel champ elle a touché, et comparer les versions met côte à côte deux versions enregistrées. Le mécanisme complet se trouve dans /features/version-control.

Cette distinction est importante car un organigramme n'est pas le même objet que le document de processus dans lequel il peut être intégré. Cette page concerne le contrôle de version de la propre structure du diagramme (boîtes, voies, connecteurs) à l'intérieur d'un outil conçu pour suivre cette structure. Si vous gérez plutôt les révisions d'un document de processus plus long qui contient un diagramme, la version indépendante des outils de ce problème est abordée dans /fr/guides/controle-de-version-pour-la-documentation-des-processus-et-les-cartes-de-processus.

Comment cela fonctionne

1. Arrêtez de nommer les versions dans le fichier

   Supprimez complètement la convention "v3_FINAL_reviewed(2)" : une décimale ou une couleur saisie dans un nom de fichier est une étiquette ajoutée par quelqu'un, pas un enregistrement de ce qui a changé. Modélisez l'organigramme dans un outil qui conserve son propre historique de révision et laissez le nom de fichier redevenir un simple nom de fichier.

2. Attribuez à chaque soumission d'avis une version nommée

   Dans QueryChart, la soumission d'un graphique pour révision enregistre automatiquement une version nommée et rien n'est jamais écrasé. Cette seule habitude remplace toute la piste "Enregistrer sous" des fichiers en double, car l'état antérieur est préservé, que quelqu'un se souvienne ou non de renommer quoi que ce soit.

3. Ouvrez le journal des modifications avant de demander ce qui a changé

   Le journal des modifications répertorie toutes les modifications apportées au graphique, qui les a effectuées et quel champ elles ont touché. Ainsi, « ce qui a changé depuis mardi » est un défilement dans une liste, et non un exercice de mémoire ou un regard côte à côte sur deux images exportées.

4. Différez deux versions au lieu de regarder deux exportations

   Utilisez Comparer les versions pour sélectionner deux versions enregistrées et voir la différence champ par champ : les modifications de boîte, de connecteur et d'étiquette sont signalées individuellement lorsqu'elles sont ajoutées, supprimées ou modifiées, plutôt que laissées au lecteur pour les repérer sur deux PDF aplatis.

5. Restaurer au lieu de reconstruire à partir de la mémoire

   Si une révision s'avère erronée, restaurez la version antérieure plutôt que de la redessiner manuellement à partir d'une ancienne exportation. La restauration elle-même devient une nouvelle entrée dans l'histoire, donc rien sur l'origine du projet actuel n'est perdu.

6. Conserver le diagramme comme maître, pas son exportation

   Traitez le PDF ou le PNG que vous diffusez comme un instantané pour les lecteurs, jamais comme l'enregistrement à partir duquel vous reconstruisez : le graphique modifiable avec son historique de versions est la seule copie qui peut répondre "à quoi cela ressemblait-il en mars", et l'exportation ne le peut pas.

Erreurs à éviter

• Le (2) dans le nom du fichier est le tell

  Un numéro entre parenthèses ajouté à un nom de fichier déjà versionné signifie que deux personnes ont édité la même « dernière » copie en même temps sans aucun moyen de les fusionner. Le correctif n'est pas une meilleure convention de dénomination, il supprime le besoin d'en avoir une : un graphique, un historique, aucune copie à entrer en collision.

• Un PDF exporté survit au graphique dont il provient

  Un PDF épinglé sur un mur ou joint à un ancien e-mail continue de circuler longtemps après que le graphique à partir duquel il a été exporté ait disparu, et rien dans le PDF lui-même ne le laisse entendre. Traitez chaque exportation comme datée au moment de sa création et créez un lien vers le graphique en direct plutôt que de repartager le fichier.

• Confondre la gestion des versions de fichiers avec la gestion des versions de diagrammes

  OneDrive, Google Drive et Dropbox peuvent restituer le fichier d'hier, mais aucun d'entre eux ne peut vous indiquer qu'une boîte de décision a gagné une branche ou que l'étiquette d'un connecteur a changé : ils versionnent le conteneur, pas son contenu. L’historique d’un outil de création de diagrammes est le seul endroit où la différence existe.

• Restauration silencieuse plutôt que enregistrée

  Le fait de recoller le contenu d'une ancienne exportation dans le fichier actuel efface le fait qu'une restauration ait eu lieu. Une restauration qui crée sa propre nouvelle entrée datée (comme le fait QueryChart) garde la raison de la restauration visible pour le lecteur suivant au lieu de donner l'impression que le graphique a toujours été ainsi.

Questions fréquentes

Le contrôle de version des diagrammes est-il différent du contrôle de version des documents ?

Pas en principe : les deux signifient conserver chaque état passé de quelque chose afin que vous puissiez voir ce qui a changé et y revenir, mais le « modifié » d'un organigramme est structurel : quelle boîte a été déplacée, quel connecteur a été ajouté, quelle étiquette a été reformulée. Un processus de contrôle de version de document construit autour de la prose et des numéros de page ne différera pas une branche de décision. Voir /fr/guides/controle-de-version-pour-la-documentation-des-processus-et-les-cartes-de-processus pour la version de ce problème limitée à un document de processus complet plutôt qu'à un seul diagramme.

L’exportation d’un organigramme au format PDF compte-t-elle comme un contrôle de version ?

Non : c'est un instantané, pas un historique. Un PDF capture un instant mais ne peut pas être comparé automatiquement à un autre PDF pour montrer ce qui a changé, ne peut pas être modifié et ne contient aucune trace de qui a effectué la modification précédente ni pourquoi. C'est utile pour partager une copie corrigée avec un lecteur ; cela ne remplace pas l'historique des versions du diagramme.

Quelle est la différence entre le journal des modifications et la comparaison des versions dans QueryChart ?

Le journal des modifications est la chronologie : chaque modification, qui l'a effectuée et à peu près quand, lue de haut en bas. Comparer les versions répond à une question plus précise : choisissez deux versions enregistrées et voyez la différence champ par champ entre elles, case par case et connecteur par connecteur, au lieu de faire défiler l'intégralité du journal pour le reconstruire vous-même.

Puis-je restaurer une ancienne version d’un organigramme sans perdre le travail en cours ?

Oui : restaurer une version antérieure dans QueryChart crée une nouvelle version plutôt que de supprimer celles qui l'ont suivie, de sorte que le travail effectué depuis reste dans l'historique même s'il n'est plus l'état actif. Rien dans une restauration n’est destructeur.