Fiche client modifiée : empêcher une automatisation d’écraser votre travail

Une personne corrige le statut d’un dossier dans le CRM. Pendant ce temps, une automatisation travaille sur une copie plus ancienne de cette fiche. Lorsqu’elle enregistre son résultat, la correction disparaît. Aucune fiche en double, aucune panne apparente : deux modifications se sont simplement croisées.

Ce scénario fictif peut concerner un CRM, un catalogue ou un outil de gestion sur mesure. Voici comment préparer une protection et, surtout, décider quoi faire lorsqu’un conflit apparaît.

1. Repérer les champs que plusieurs acteurs peuvent modifier

Commencez par une fiche représentative et listez ses auteurs possibles : équipe commerciale, formulaire web, synchronisation, assistant IA ou import manuel. Regardez ensuite les champs réellement partagés.

Dans notre exemple fictif, une automatisation propose une catégorie de demande. Le commercial peut corriger cette catégorie et changer le statut du dossier. Si le workflow renvoie toute la fiche à partir de sa copie initiale, il risque de rétablir des valeurs devenues anciennes.

Définissez alors une règle par champ :

• la catégorie proposée par l’IA reste dans un champ de suggestion ;
• la catégorie validée appartient à l’équipe ;
• le statut ne change que selon des transitions prévues ;
• les notes humaines ne sont pas remplacées par un résumé automatique.

Cette séparation réduit les occasions de conflit. Demandez aussi que l’intégration transmette uniquement les champs nécessaires, lorsque l’API le permet. Cela limite la portée d’une écriture, sans protéger à elle seule deux modifications du même champ.

2. Enregistrer seulement si la version l’autorise

La question à poser à votre prestataire est simple : « Pouvez-vous refuser une modification si la fiche a changé depuis sa lecture ? » Ce mécanisme est souvent appelé contrôle de concurrence optimiste.

Certaines API utilisent un ETag, une valeur qui identifie une version, puis l’en-tête If-Match pour conditionner l’écriture. La norme HTTP prévoit ce mécanisme contre l’écrasement de modifications concurrentes. Une précondition non satisfaite peut produire une réponse 412, dite « Precondition Failed ». La comparaison If-Match définie par HTTP utilise des validateurs forts. Source : RFC 9110, section 13.1.1.

Ce vocabulaire ne constitue pas une recette universelle. Microsoft Dataverse documente son propre usage d’ETags avec If-Match pour détecter une fiche modifiée avant une mise à jour. Il précise aussi qu’il ne faut pas interpréter la valeur d’un ETag comme un compteur ordonné. Suivez les règles exactes du service et de la table concernés. Source : opérations conditionnelles de Dataverse.

Pour une application sur mesure, demandez un contrôle de version effectué avec l’écriture, de façon atomique : aucune modification concurrente ne doit pouvoir se glisser entre la vérification et l’enregistrement. Une simple relecture suivie d’une écriture sans condition laisse cet intervalle ouvert.

3. Traiter le conflit comme une décision métier

Si la fiche a changé, réessayer immédiatement avec les mêmes anciennes valeurs ne résout pas le désaccord. Récupérer la nouvelle version puis lui appliquer aveuglément l’ancienne modification peut également effacer la correction que l’on voulait préserver.

Préparez plutôt ce parcours :

1. Suspendre l’écriture concernée sans annoncer que le dossier est traité.
2. Relire l’état actuel de la fiche.
3. Comparer les valeurs utilisées au départ, la modification proposée et les valeurs actuelles.
4. Recalculer la proposition uniquement si une règle explicite le permet ; sinon, demander une vérification humaine.
5. Si une nouvelle écriture est autorisée, la soumettre à nouveau au contrôle de version.

Dans notre exemple, si le commercial a corrigé la catégorie, la suggestion de l’IA reste une suggestion. Si seul un champ indépendant a changé, une nouvelle tentative ciblée peut être acceptable, après vérification des règles métier. Deux champs différents peuvent néanmoins être liés : un statut « annulé » doit, par exemple, empêcher une relance prévue auparavant.

Gardez les emails, notifications clients et autres actions dépendantes après la confirmation de la mise à jour. Un dossier en conflit ne doit pas déclencher une annonce de réussite.

4. Vérifier ce que le connecteur permet réellement

La présence d’une API ne garantit pas que votre connecteur expose ses protections. Demandez une démonstration sur le flux utilisé : où la version est-elle lue, conservée et transmise ? Quel chemin suit la réponse de conflit ?

Les mécanismes varient selon les services. Google Cloud Storage, par exemple, documente des préconditions fondées sur la génération des objets pour éviter qu’une opération s’applique à une version inattendue. C’est un exemple de protection sur des fichiers, pas une garantie concernant votre CRM. Source : préconditions des requêtes Cloud Storage.

Si votre outil ne propose aucun contrôle adapté, réduisez le périmètre : un seul système responsable d’un champ, des suggestions séparées ou une validation manuelle. Exécuter un seul workflow à la fois peut limiter ses propres conflits, mais ne bloque pas les modifications provenant de l’interface du CRM ou d’autres intégrations.

Évitez de présenter cette solution de repli comme une protection complète.

5. Faire un test à deux acteurs avant la mise en service

Utilisez une fiche fictive dans un environnement isolé. Faites lire cette fiche par l’automatisation, puis mettez celle-ci en pause avant l’écriture. Modifiez ensuite la fiche avec un compte de test et laissez le workflow reprendre.

La recette doit vérifier que :

• la modification humaine n’est pas écrasée silencieusement ;
• le conflit apparaît dans une file ou un écran exploitable ;
• aucun message dépendant n’est envoyé prématurément ;
• la reprise suit la règle choisie, sans contourner le contrôle ;
• un second changement pendant la reprise est lui aussi détecté.

Testez le même champ, puis deux champs distincts, puis un changement qui rend l’action inutile, comme l’annulation du dossier. Vérifiez également le cas ordinaire, sans modification concurrente : il doit continuer à fonctionner.

Pour le suivi, conservez un identifiant de fiche, l’étape bloquée et l’issue du traitement. Évitez de recopier tout le dossier client dans les alertes. Désignez la personne qui tranche les conflits et lui donne accès aux seules informations nécessaires.

Le livrable à demander

Avant d’activer les écritures automatiques, demandez une courte fiche de fonctionnement : champs modifiables, responsables, mécanisme de version, règle de résolution et preuve du test à deux acteurs.

Le critère de réussite est concret : une automatisation peut terminer sa tâche ou signaler un conflit, mais elle ne doit pas remplacer discrètement une correction humaine par une ancienne valeur.