L‘expertise judiciaire en informatique :

Dossier : L'ExpertiseMagazine N°695 Mai 2014
Par Michel VILLARD (70)

Douze à dix-huit mois de travail

Les expertises ordonnées par un tribunal suite à l’abandon d’un projet de mise en œuvre de système d’information, que ce soit la réalisation d’un développement spécifique ou l’intégration d’un progiciel, représentent de gros enjeux financiers pour les parties, au vu des préjudices consécutifs à l’arrêt du projet, et sont particulièrement complexes du fait de la collaboration étroite ayant existé entre les parties pendant le projet.

Leur durée moyenne se situe entre douze et dix-huit mois.

REPÈRES

Expert inscrit sur la liste de la cour d’appel de Paris depuis 1994, l’auteur a été amené à remplir des missions variées qui peuvent être classées en deux grandes catégories.
Dans l’expertise pénale, suivant la mission définie par le juge d’instruction, l’expert recherche sur des scellés (ordinateur, disque dur, smartphone, carte mémoire, etc.) des preuves ou indices d’actes frauduleux (fichiers illicites, comptabilité falsifiée, données qualifiées de secrets industriels, courriels, chats, SMS, photos, vidéos, etc.).
Quant à l’expertise en procédure civile ou administrative, elle fait suite à un conflit entre le client et le fournisseur, par exemple rejet de fourniture, décision d’arrêt d’un projet, etc., quand une partie demande au tribunal la désignation d’un expert.

Primauté au contrat

Contrairement au domaine du bâtiment, la mise en œuvre d’un système d’information (SI) ne s’appuie pas sur des réglementations ou des normes particulières mais essentiellement sur des dispositions contractuelles au cas par cas suivant la nature de la prestation.

La mise en œuvre d’un SI ne s’appuie pas sur des réglementations ou des normes particulières

Les principaux acteurs du marché sont d’une part les sociétés de services en ingénierie informatique (SSII) et d’autre part les éditeurs qui assurent la conception, le développement et la commercialisation de progiciels et fournissent des prestations d’assistance à la mise en œuvre de leurs progiciels.

Dans le cas d’un projet de logiciel spécifique, le client et le prestataire (SSII) signent un contrat qui définit les conditions dans lesquelles ils vont collaborer pour concevoir, réaliser, mettre en place et démarrer le logiciel dans l’environnement informatique du client.

Dans le cas d’un projet d’intégration de progiciel, un contrat similaire est signé une fois le choix du progiciel effectué par le client, ainsi qu’un contrat séparé entre le client et l’éditeur qui définit les conditions de la concession au client d’un droit d’utilisation du progiciel.

Établir le référentiel contractuel

L’expert de justice désigné par le tribunal reçoit une mission décrite dans la décision. En premier lieu, l’expert doit prendre connaissance du référentiel contractuel et notamment du cahier des charges du client, reflétant l’expression de ses besoins ; de la proposition technique et commerciale du prestataire validée par le client, et du plan qualité projet (PQP) lorsqu’il existe.

Souvent l’expert constate l’incomplétude ou le manque de précision de ce référentiel contractuel.

Reconstruire l’histoire

Le rôle clé du PQP

Le PQP – plan qualité projet – est particulièrement important dans le travail d’expertise. En effet, il définit un découpage du projet en phases et, sur chaque phase, les principales tâches et la répartition des responsabilités par tâches entre le prestataire et le client, ainsi que les modalités de suivi et d’évaluation de la qualité.

En second lieu, l'expert doit reconstruire le scénario du projet : qui a fait quoi et quand ? À cet effet sont notamment à sa disposition les comptes rendus des instances de pilotage du projet : comités stratégiques, comités de pilotage, comités techniques, etc., et les échanges de courriers et de courriels dans lesquels se trouvent souvent des informations importantes pour l'expertise.

Enfin, en troisième lieu, l'expert analyse les griefs exposés par les parties, lesquels sont constitués par des écarts entre ce qui a été fait et ce qui aurait dû être fait, puis les causes de ces écarts et à qui elles sont imputables.

UN EXEMPLE REPRÉSENTATIF DES EXPERTISES

Direction de projet : faire la part des choses

Le prestataire est certes responsable de l'avancement du projet, mais le client est acteur dans la mesure où l'avancement dépend d'une part de ses propres ressources et compétences et d'autre part de certains jalons qui sont de sa responsabilité unique.

Le client est réputé averti de la définition de ses besoins

Les griefs de cette phase sont de quatre natures : retard de telle ou telle tâche du projet; dépassement des ressources affectées à telle ou telle tâche du projet; écarts avec la démarche méthodologique du PQP ; enfin, risques (délais, ressources, coûts) qui auraient dû être identifiés et mentionnés clairement dans le registre des risques du projet.

Chacun des quatre griefs ci-dessus peut être imputable au client ou au prestataire. L'expertise devra faire la part des choses.

Analyse des besoins : lacunes et imprécisions

La phase d'analyse des besoins est souvent à l'origine de difficultés majeures sur les projets. Elle est fondée sur une collaboration étroite entre le prestataire et le client, sous la forme d'ateliers d'analyse par thèmes, donnant lieu à des comptes rendus rédigés par le prestataire et relus et validés par le client.

Cas d’école

Dans l’exemple présenté ici, les griefs concernent plusieurs phases du projet – analyse des besoins, conception et paramétrage (cas d’un progiciel) ou conception et développement (cas d’un logiciel spécifique), reprise des données, recettes. Ils concernent aussi, et en premier lieu, la direction de projet, qui se déroule en parallèle avec toutes les autres phases.

Le client est réputé averti de la définition de ses besoins, avoir la connaissance de ses besoins. Un dossier d'analyse validé par le client constitue le nouveau référentiel de l'expression des besoins, qui complète le cahier des charges contractuel.

En général, au cours de la phase d'analyse, on découvre que l'expression des besoins initiale est incomplète ou imprécise et doit être détaillée sur de nombreux points, voire corrigée. De nouveaux écarts (besoins non couverts) sont donc identifiés.

Les griefs retenus dans notre exemple sont de quatre natures : des écarts n'ont pas été identifiés pendant la phase d'analyse; des écarts identifiés ne pouvaient être détectés à la lecture du cahier des charges initial ; le besoin n'est pas resté stable entre le cahier des charges et le dossier d'analyse; la démarche de résolution des écarts n’a pas été correctement appliquée (recherche de solution de paramétrage ou de conduite de changement avant d’engager un développement spécifique)

Conception et paramétrage ou développement

Solutions correctrices

Trois types de remèdes sont envisageables pour corriger les écarts dans les projets de mise en œuvre de progiciel : la réalisation de paramétrages complémentaires lorsque celle-ci est possible; l’acceptation par le client d’adapter ses processus métier et son organisation en fonction des règles de gestion du progiciel [démarche de « conduite de changement organisationnel » (CCO) ou en anglais organisationnal change management (OCM)]; enfin, la réalisation de développements spécifiques.
Dans les projets de logiciels spécifiques, seules les deux dernières solutions sont possibles.

Le prestataire est clairement le responsable de cette phase. Tout manquement (erreur technique, indisponibilité de ressource, défaut de compétence, retard d’exécution, etc.) lui est donc imputable sauf cas particulier, comme, par exemple, un jalon de validation non respecté par le client.

La reprise de données, source de difficultés

La phase de reprise de données est souvent à l’origine de difficultés majeures sur les projets. Elle est de la responsabilité du client, mais requiert une collaboration étroite entre prestataire et client. En effet, le client est responsable du nettoyage des données existantes, de l’extraction des données, de la validation des données converties (avant chargement) et de la recette de l’intégration des données (après chargement).

Le prestataire est responsable des spécifications de reprise, de la conversion des données extraites (avant chargement), des programmes d’injection et du chargement des données.

Recette : la responsabilité du client

Le client est globalement responsable de la recette. Le prestataire a principalement en charge les livraisons du progiciel ou logiciel pour recette et les corrections des anomalies.

Multiples griefs

Dans notre exemple, les principaux griefs de la phase reprise de données concernaient à la fois les spécifications de reprises qui ne reprenaient pas les mises à jour des dossiers d’analyses, les défauts dans les données extraites (doublons, valeurs erronées, incohérences, etc.), et les bogues dans les programmes de conversions et de chargements.

Dans notre exemple, l’analyse des griefs de la phase recette porte sur les questions suivantes : les scénarios de tests sont-ils conformes aux dossiers d’analyses ? Les retards ont-ils pour cause le délai de déroulement des tests (responsabilité du client) ou le délai de correction des anomalies identifiées par le client (responsabilité du prestataire)?

Les anomalies non corrigées en fin de recette sont-elles acceptables en regard des conditions d’acceptation de recette définies au PQP, lequel distingue les anomalies bloquantes, majeures et mineures?

Accord amiable

J’ai présenté un cas représentatif des expertises ordonnées par un tribunal, à la demande d’une partie, suite à l’abandon d’un projet de mise en œuvre de système d’information, que ce soit la réalisation d’un développement spécifique ou l’intégration d’un progiciel.

Une expertise bien conduite permet de rétablir un dialogue entre les parties

Ces expertises sont particulièrement complexes du fait de la collaboration étroite ayant existé entre les parties pendant le projet et de l’absence de réglementations ou de normes particulières. L’expert commence par une prise de connaissance du référentiel contractuel et une reconstitution de l’historique du projet.

Ensuite, pour chaque phase du projet, l’expert analyse les griefs exposés par les parties, lesquels sont constitués par des écarts entre ce qui a été fait et ce qui aurait dû être fait, puis les causes de ces écarts et à qui elles sont imputables. Certes, l’expert ne reçoit pas pour mission de concilier les parties.

Néanmoins, une expertise bien conduite permet de rétablir un dialogue entre les parties et de donner à chacune une vision claire de ses forces et faiblesses. C’est pourquoi, dans la grande majorité des cas, l’expertise aboutit à un accord amiable qui met fin au litige, et cela en cours d’expertise ou après le dépôt du rapport de l’expert.

Poster un commentaire