Contrôle de version vs contrôle de modification : quelle est la différence
Le contrôle de version permet de savoir quelle révision d'un document est actuelle et ce qui a changé ; Le contrôle des modifications décide si un changement proposé est autorisé ou non et qui doit l'approuver en premier.
Le contrôle de version est le mécanisme qui identifie et mémorise les états successifs d'un document ; le contrôle des modifications est le processus de gouvernance qui décide si une modification est autorisée avant la création d'une nouvelle version.
En bref
- Le contrôle de version suit l'identité et l'historique : de quelle version il s'agit et ce qui l'a précédée.
- Le contrôle des changements est une question de gouvernance : si un changement proposé est autorisé et qui doit l'approuver.
- Le contrôle des modifications s'exécute en premier : la classification et l'approbation entrent dans une nouvelle version, et non l'inverse.
- Une modification mineure et une modification majeure peuvent comporter différents niveaux de contrôle des modifications sans modifier le fonctionnement du contrôle de version.
- La plupart des processus réels ont besoin des deux, en couches : le contrôle des modifications décide, le contrôle des versions se souvient.
Deux questions différentes, un objet partagé
La question de savoir de quelle version il s'agit et celle de savoir si un changement doit être autorisé sont distinctes. La gestion des versions numérote les états successifs d'un document, conserve leur historique et indique qui a modifié quoi et quand. La gestion des changements intervient en amont : elle décide si la modification proposée est justifiée, qui doit l'examiner et quelles conditions doivent être remplies avant qu'une nouvelle version existe.
Le workflow de contrôle des modifications de documents ci-dessous rend la limite visible sous forme de graphique plutôt que de phrase. Les lignes 1 à 8 concernent entièrement le contrôle des modifications : enregistrer la demande, la classer comme mineure ou majeure, acheminer les modifications majeures vers un réviseur qui en évalue l'impact complet et tout classer sur un "**Approuvé ?**" décision. Rien de tout cela ne touche à la version du document. Ce n'est qu'après la porte d'approbation que « Mettre à jour le numéro de version et la liste de distribution » s'exécute, à la ligne 9 : le point exact où commence le contrôle de version.
QueryChart sépare les deux de la même manière. Chaque modification d'un graphique est capturée automatiquement dans un journal des modifications avec des différences par champ, une vue Comparer les versions et une restauration en un clic : c'est-à-dire le contrôle de version, exécuté que quelqu'un le demande ou non, dans /features/version-control. Si une modification donnée a été autorisée en premier lieu et qui l'a signée, la question de gouvernance est-elle répondue par un tableau comme celui ci-dessous. Pour une version plus complète et plus axée sur l'informatique/opérations de ce processus de gouvernance plutôt que celle spécifique au document, voir /fr/guides/comment-creer-un-processus-de-controle-des-changements.
Contrôle des versions et contrôle des modifications en un coup d'œil
| Aspect | Contrôle des versions | Changer le contrôle |
|---|---|---|
| Question centrale | De quelle révision s’agit-il et qu’est-ce qui a changé ? | Le changement proposé devrait-il être autorisé? |
| Quand | Enregistre chaque état enregistré ou émis | Évalue une proposition avant la diffusion contrôlée |
| Décision | Identifie les états actuels et antérieurs | Accepte, rejette ou conditionne la proposition |
| Preuve | Journal de révision et comparaison | Demande, analyse d’impact, approbation et vérification |
Comment cela fonctionne
Séparez les deux questions dans votre propre processus
Avant de dessiner quoi que ce soit, décidez ce qui appartient au contrôle des modifications (demande, classification, révision, approbation) et ce qui appartient au contrôle de version (identifiant, numéro de révision, historique, restauration). Nommer la limite est l’étape de conception que la plupart des organigrammes sautent.
Classer avant d’évaluer
Acheminez chaque demande vers une décision mineure/majeure avant le début de l’évaluation, comme le fait la rangée 4. Une correction de formulation mineure et une modification majeure d'exigence ne devraient pas suivre le même chemin de révision, et décider laquelle est d'emblée empêche chaque modification de recevoir le traitement le plus lourd.
Placez l'étape de contrôle de version là où l'approbation se termine réellement
N'incrémentez le numéro de version, définissez la date d'entrée en vigueur et mettez à jour la liste de distribution qu'après la porte d'approbation, jamais avant. Si votre graphique met à jour la version avant la décision, vous avez décrit un processus par lequel les versions ont rejeté les brouillons.
Donner le contrôle des modifications à son propre réviseur, et non au propriétaire du document
Un examinateur du changement qui évalue l'impact total et l'enregistre par rapport aux documents et formulaires associés, séparément de celui qui a demandé le changement, est ce qui fait que « approuvé » signifie quelque chose. Dans l’exemple, cette étape se situe entre la classification et la décision d’approbation, et n’est intégrée ni à l’une ni à l’autre.
Laissez le contrôle de version s'exécuter tout seul une fois que le contrôle des modifications a été décidé
La publication, la notification des détenteurs de la liste de distribution et le retrait de la copie remplacée sont mécaniques une fois qu'une modification est approuvée : il s'agit de la queue de contrôle de version du graphique, et c'est la moitié de la vue Journal des modifications et comparaison des versions de QueryChart déjà gérée pour vous dans /features/version-control.
Erreurs à éviter
Traiter "nous avons l'historique des versions" comme contrôle des modifications
Un outil qui horodate chaque modification n’est pas un processus de gouvernance : il n’a ni classification, ni réviseur, ni porte d’approbation. L'historique des versions répond à ce qui a changé ; cela ne dit rien sur la question de savoir si le changement aurait dû se produire.
Versionner une modification avant son approbation
Si le numéro de version se déplace avant le message « Approuvé ? » décision, un projet rejeté apparaît toujours comme une nouvelle révision. Conservez l'incrément à la ligne 9, après approbation, comme le fait l'exemple.
Une catégorie pour chaque changement
L'exécution d'une correction de faute de frappe lors de la même révision qu'un changement d'exigence ralentit les modifications triviales ou permet aux modifications substantielles de passer rapidement. La division mineur/majeur à la rangée 4 existe afin que les deux fassent l'objet d'un examen minutieux approprié ; voir /fr/guides/comment-creer-un-processus-de-controle-des-changements pour savoir comment concevoir les catégories elles-mêmes.
Questions fréquentes
Le contrôle de version est-il la même chose que le contrôle des modifications ?
Le contrôle de version est le mécanisme qui identifie et mémorise les états successifs d'un document : un numéro de révision, un historique de qui a modifié quoi et la possibilité de comparer ou de restaurer un numéro antérieur. Le contrôle des changements est le processus de gouvernance qui décide si un changement proposé est autorisé, qui l'examine et ce qui doit être vrai avant qu'il ne soit approuvé. Un document peut avoir un contrôle de version rigoureux et aucun contrôle des modifications : chaque modification est enregistrée, personne ne décide si elle aurait dû être effectuée.
Lequel dois-je construire en premier ?
Contrôle de version, car il est généralement déjà exécuté sous vous : QueryChart conserve automatiquement un journal des modifications avec des différences par champ et une vue Comparer les versions pour chaque graphique, dans /features/version-control. Le contrôle des modifications est la partie que vous devez concevoir délibérément (catégories, un réviseur, une porte d'approbation), c'est pourquoi c'est le processus qui mérite d'être dessiné sous forme d'organigramme, comme celui de cette page.
En quoi cela diffère-t-il du contrôle de révision ?
En pratique, le « contrôle de révision » et le « contrôle de version » sont le même mécanisme sous des noms différents, tous deux concernés par l'identification et le suivi des états successifs d'un document. Le contrôle des modifications est différent : il détermine si une modification est autorisée en premier lieu, se terminant généralement par une nouvelle version une fois approuvée. Voir /fr/guides/controle-de-revision-vs-controle-de-version-quelle-est-la-vraie-difference s'il s'agit spécifiquement de la question de dénomination du contrôle de révision/contrôle de version que vous essayez de résoudre.
Quelle est la place du contrôle des documents par rapport à ces deux éléments ?
Le contrôle des documents est le plus vaste des trois : le cycle de vie complet d'un document contrôlé, depuis la demande jusqu'à la rédaction, la révision, l'approbation, la publication et le retrait ou le retrait éventuel. Le contrôle des modifications et le contrôle des versions en sont tous deux des éléments : le contrôle des modifications régit une seule modification proposée, le contrôle de version suit les identifiants et l'historique produits par la modification. Pour l’ensemble du cycle de vie plutôt que simplement la limite de modification/version, voir /fr/templates/organigramme-du-workflow-de-controle-des-modifications-de-documents ou /fr/guides/comment-creer-un-processus-de-controle-des-documents plus large.