Migration de données ratée : jusqu'où va votre responsabilité d'intégrateur ?

Vendredi soir, vous lancez la bascule des 180 000 fiches clients de l'ancien CRM vers le nouvel ERP. Lundi matin, l'équipe commerciale du client constate que 4 200 fiches ont perdu leur historique de commandes, et que plusieurs centaines de codes postaux ont été tronqués. Le directeur des systèmes d'information vous appelle, furieux : selon lui, vous avez "détruit" une partie de son patrimoine de données.

Avant de paniquer, posez la bonne question : une perte de données vous rend-elle automatiquement responsable ? La réponse, contre toute intuition, est non. Le droit français ne fait pas de l'intégrateur un assureur du résultat. Encore faut-il comprendre la mécanique exacte de la responsabilité, parce que c'est elle qui détermine qui sortira le chéquier.

Tout part de la nature de votre engagement. Le prestataire de services informatiques est, par principe, tenu d'une obligation de moyens : vous vous engagez à mettre en œuvre les diligences et les compétences attendues d'un professionnel normalement avisé, pas à garantir un résultat parfait quelles que soient les circonstances.

Concrètement, cela change tout sur le plan de la preuve :

• En obligation de moyens, c'est au client de démontrer que vous avez commis une faute (un manquement à ce qu'un intégrateur compétent aurait fait).
• En obligation de résultat, la seule constatation que le résultat promis n'est pas atteint suffit à vous présumer fautif ; à vous de prouver une cause étrangère.

Attention : la frontière n'est pas figée. Si votre contrat ou votre devis promet explicitement une "migration sans perte" ou "100 % des données reprises", un juge peut requalifier votre engagement en obligation de résultat sur ce point précis. La rédaction de vos documents commerciaux est donc un acte de gestion du risque à part entière.

Si une perte de données n'est pas en soi une faute, certains manquements le sont sans ambiguïté. Les contentieux d'intégration tournent presque toujours autour des mêmes points :

1. L'absence de sauvegarde avant bascule. Lancer une migration irréversible sans backup complet et vérifié de la source est la faute la plus lourde. C'est l'équivalent du chirurgien qui n'a pas vérifié le groupe sanguin. Un juge y voit un manquement caractérisé aux règles de l'art.
2. Le script de transformation non testé. Migrer directement en production une règle de mapping ("le champ A devient le champ B") sans l'avoir validée sur un jeu de test représentatif engage votre responsabilité si elle corrompt les données.
3. Le défaut de conseil et d'alerte. Si vous saviez que les données sources étaient de mauvaise qualité (doublons, champs vides, encodage incohérent) et que vous n'avez pas alerté le client par écrit, votre devoir de conseil renforcé peut être retenu contre vous.

La jurisprudence est constante : le prestataire informatique, professionnel, est débiteur d'un devoir de conseil renforcé vis-à-vis d'un client profane. Le silence se paie.

Le réflexe du client est de vous désigner comme unique coupable. La réalité juridique est beaucoup plus nuancée. Le juge module les responsabilités en fonction de la contribution de chacun au dommage :

Dans la pratique, beaucoup de sinistres d'intégration aboutissent à un partage : 40 % pour vous, 30 % pour le client qui a fourni des données ingérables, 30 % pour l'éditeur dont le connecteur a silencieusement tronqué les champs longs. D'où l'importance vitale de documenter ce que vous avez reçu et ce que vous avez alerté.

Toutes les migrations ne se valent pas au regard du risque. Une reprise de données en double écriture, où l'ancien système reste actif en parallèle pendant une période de coexistence, vous laisse une marge de manœuvre : vous pouvez comparer, corriger, rejouer. Une migration big bang, où l'ancien système est éteint le soir et le nouveau allumé le lendemain, ne pardonne rien. C'est dans ce second scénario que se concentrent les sinistres les plus lourds.

Pour une bascule irréversible, le standard de diligence attendu d'un intégrateur compétent s'élève mécaniquement. Trois précautions deviennent des obligations de fait :

• Un test de migration à blanc sur une copie complète de la production, avec rapprochement des volumes avant validation du jour J.
• Un plan de retour arrière documenté : que fait-on si, à 2 h du matin, le rapprochement révèle un écart de 5 % ? La réponse doit être écrite avant, pas improvisée pendant.
• Une fenêtre de vérification post-bascule avant la remise en service utilisateur, pour intercepter l'anomalie avant qu'elle ne contamine les saisies du lundi matin.

Documenter que vous avez proposé ces précautions — et, le cas échéant, que le client les a refusées pour gagner du temps ou de l'argent — déplace très nettement le curseur de la responsabilité.

En cas de litige, gagne celui qui prouve. Quatre réflexes vous protègent mieux que n'importe quelle clause :

• Le PV de sauvegarde. Un horodatage, un volume, un emplacement, et idéalement une vérification de restauration sur un échantillon. C'est la pièce reine.
• Le journal de migration. Logs des lignes traitées, rejetées, transformées. Un écart entre le nombre de lignes source et cible doit être expliqué et signalé au client.
• Les alertes écrites. Un simple e-mail "nous avons constaté 4 200 fiches sans historique exploitable en source, merci de confirmer le périmètre repris" déplace la responsabilité.
• Le PV de recette. Une validation signée par le client clôt le débat sur ce qui a été vérifié et accepté.

Ces documents transforment une accusation floue ("vous avez tout cassé") en un débat technique factuel où votre position est défendable.

Même irréprochable, vous pouvez être assigné. Un client mécontent attaque, et la seule défense peut coûter plusieurs milliers d'euros d'expertise et d'avocat avant même qu'un tribunal ne tranche. C'est là qu'intervient votre contrat.

L'assurance RC Pro couvre les dommages immatériels causés au client par une faute professionnelle : reconstitution de données, surcoûts de reprise, préjudice d'exploitation imputable à votre erreur. Elle finance surtout votre défense, y compris quand la mise en cause est infondée — un poste souvent sous-estimé.

Si le sinistre touche votre propre infrastructure (vos serveurs, vos accès, une intrusion qui exfiltre les données client que vous hébergez temporairement), c'est l'assurance cyber qui prend le relais. Pour calibrer une couverture adaptée à votre volume de missions, retrouvez les garanties détaillées sur la page dédiée au conseil en systèmes et logiciels.