Modifications simultanées d’une même fiche : la liste de vérification pour les applications auto-hébergées
Une sauvegarde automatique ou un historique ne permet pas, à lui seul, de savoir comment une application gère deux modifications simultanées. Cette liste vous aide à vérifier le comportement de vos fiches et de vos processus.
Pourquoi vérifier les modifications simultanées
Le fait que plusieurs personnes puissent ouvrir une même fiche ne permet pas de savoir ce qui se passe lorsqu’elles la modifient en même temps. Selon l’application et le processus, une modification peut être signalée comme conflictuelle, remplacée par une autre ou traitée autrement. Vérifiez le comportement dans l’application que vous utilisez au lieu de présumer du résultat.
La sauvegarde automatique, l’historique d’une fiche ou une base de données partagée ne prouvent pas, à eux seuls, que des modifications simultanées sont sans risque. Considérez ces éléments comme des fonctionnalités à examiner, pas comme des garanties.
- Commencez par les fiches et les champs où une valeur erronée aurait des conséquences importantes.
- Testez la version, la configuration et les rôles que votre équipe prévoit réellement d’utiliser.
Préparez un test avec deux utilisateurs
Faites le test dans une instance dédiée ou sur une fiche réservée à cet usage, sans modifier de données métier actives. Choisissez deux comptes ordinaires dont les rôles correspondent à ceux utilisés au quotidien. Notez les valeurs initiales et les changements prévus par chacun.
Testez séparément deux cas : les deux utilisateurs modifient le même champ, puis chacun modifie un champ différent. Pour chaque cas, contrôlez l’ordre des sauvegardes, les messages affichés et les valeurs présentes après actualisation des deux sessions.
- Ouvrez la même fiche dans deux sessions distinctes avant de commencer.
- Choisissez des valeurs clairement différentes pour le test du même champ.
- Inversez l’ordre des sauvegardes et consignez ce que voit chaque utilisateur.
- Utilisez des exemples fictifs et évitez les comptes administrateur pour le test principal.
Consultez la documentation et examinez le résultat
Recherchez la documentation officielle correspondant à l’application et à la version concernées. Les termes utiles peuvent inclure verrouillage de fiche, détection des conflits, sauvegarde automatique, historique des révisions et journal d’audit. Vérifiez que les informations portent bien sur le type de fiche et les actions testés.
Après les sauvegardes, actualisez les deux sessions et examinez les valeurs conservées. Notez tout avertissement, verrouillage ou indication qu’une autre personne a modifié la fiche. Si la documentation ne précise pas le comportement, consignez cette incertitude et appuyez-vous sur les résultats de votre test.
- La documentation précise-t-elle si plusieurs personnes peuvent modifier la fiche en même temps ?
- En cas de conflit, quels messages ou choix sont présentés aux utilisateurs ?
- Quelles modifications l’historique ou le journal d’audit indique-t-il, et qui peut les consulter ?
Vérifiez les sessions laissées ouvertes et les connexions
Un test ne couvre pas forcément toutes les situations rencontrées au quotidien. Essayez aussi une session de modification laissée ouverte pendant que l’autre utilisateur enregistre un changement, puis reprenez cette session. Vérifiez si l’utilisateur est averti que la fiche a changé et ce qui se passe lorsqu’il tente d’enregistrer.
Si votre équipe doit travailler avec une connexion lente ou interrompue, testez cette situation dans un environnement sûr, hors production. Observez les indications de sauvegarde et vérifiez le contenu de la fiche après l’avoir rouverte ; une valeur encore affichée dans une page ouverte ne confirme pas qu’elle a été enregistrée.
- Actualisez la fiche après la sauvegarde de l’autre utilisateur.
- Ne simulez une connexion interrompue que dans un environnement où le test ne peut pas affecter des données actives.
- Consignez les messages affichés et les valeurs observées.
Évaluez la récupération et les effets en aval
Vérifiez comment votre équipe pourrait comprendre et corriger une valeur écrasée ou contestée. Si l’application propose un historique ou un journal d’audit, examinez s’il fournit les informations nécessaires pour identifier la modification et déterminer la suite à donner. Ne présumez pas que toutes les applications consignent les mêmes détails.
Si une sauvegarde de fiche déclenche une intégration ou une automatisation, incluez ce processus dans le test. Vérifiez les résultats dans les systèmes concernés après les modifications. Le comportement dépend de l’application et de la configuration : les éléments disponibles ne permettent pas de le généraliser.
- Déterminez si une personne autorisée peut repérer la modification conservée et décider comment corriger la fiche.
- Identifiez les automatisations et intégrations associées à la fiche testée.
- Vérifiez les conséquences pertinentes après une modification corrigée ou répétée.
Définissez vos critères d’acceptation
Avant de vous fier au processus, précisez ce que signifie un résultat acceptable pour les fiches et les champs concernés. Vous pouvez, par exemple, exiger que les utilisateurs puissent détecter un changement concurrent et qu’une méthode de vérification ou de correction soit testée.
Conservez un compte rendu avec l’application et la version, la fiche testée, les rôles, les étapes, les résultats et les questions non résolues. Si le processus ne répond pas aux exigences de votre équipe, modifiez-le ou évaluez une autre solution. Un hébergement géré peut prendre en charge des tâches d’infrastructure, mais les choix relatifs aux données, aux accès et à la gouvernance restent à évaluer.
- Définissez les fiches qui nécessitent une vérification supplémentaire.
- Établissez une méthode testée pour repérer et corriger une valeur involontaire.
- Répétez le test après une modification importante de l’application ou de sa configuration.
Questions fréquentes
La sauvegarde automatique empêche-t-elle la perte de modifications ?
Pas nécessairement. Elle ne suffit pas à établir comment l’application traite des modifications simultanées. Consultez la documentation officielle et vérifiez le résultat avec deux comptes représentatifs.
Les modifications de champs différents sont-elles sans risque ?
Ne le présumez pas. Testez ce cas séparément d’un conflit portant sur le même champ, puis vérifiez les valeurs de la fiche après les sauvegardes.
L’historique suffit-il pour récupérer une valeur remplacée ?
Cela dépend des informations conservées et des personnes autorisées à les consulter. Vérifiez l’historique disponible et testez la méthode de correction prévue par votre équipe.
L’auto-hébergement détermine-t-il le comportement des modifications simultanées ?
Le mode d’hébergement ne permet pas, à lui seul, de connaître le comportement de l’application. Vérifiez la documentation officielle et testez vos processus dans la configuration prévue.
Sources et lectures complémentaires
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group