L‘expertise judiciaire en informatique :

Douze à dix-huit mois de travail

Les exper­tis­es ordon­nées par un tri­bunal suite à l’abandon d’un pro­jet de mise en œuvre de sys­tème d’information, que ce soit la réal­i­sa­tion d’un développe­ment spé­ci­fique ou l’intégration d’un progi­ciel, représen­tent de gros enjeux financiers pour les par­ties, au vu des préju­dices con­sé­cu­tifs à l’arrêt du pro­jet, et sont par­ti­c­ulière­ment com­plex­es du fait de la col­lab­o­ra­tion étroite ayant existé entre les par­ties pen­dant le projet.

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

Primauté au contrat

Con­traire­ment au domaine du bâti­ment, la mise en œuvre d’un sys­tème d’information (SI) ne s’appuie pas sur des régle­men­ta­tions ou des normes par­ti­c­ulières mais essen­tielle­ment sur des dis­po­si­tions con­tractuelles au cas par cas suiv­ant 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 prin­ci­paux acteurs du marché sont d’une part les sociétés de ser­vices en ingénierie infor­ma­tique (SSII) et d’autre part les édi­teurs qui assurent la con­cep­tion, le développe­ment et la com­mer­cial­i­sa­tion de progi­ciels et four­nissent des presta­tions d’assistance à la mise en œuvre de leurs progiciels.

Dans le cas d’un pro­jet de logi­ciel spé­ci­fique, le client et le prestataire (SSII) sig­nent un con­trat qui définit les con­di­tions dans lesquelles ils vont col­la­bor­er pour con­cevoir, réalis­er, met­tre en place et démar­rer le logi­ciel dans l’environnement infor­ma­tique du client.

Dans le cas d’un pro­jet d’intégration de progi­ciel, un con­trat sim­i­laire est signé une fois le choix du progi­ciel effec­tué par le client, ain­si qu’un con­trat séparé entre le client et l’éditeur qui définit les con­di­tions de la con­ces­sion au client d’un droit d’utilisation du progiciel.

Établir le référentiel contractuel

L’expert de jus­tice désigné par le tri­bunal reçoit une mis­sion décrite dans la déci­sion. En pre­mier lieu, l’expert doit pren­dre con­nais­sance du référen­tiel con­tractuel et notam­ment du cahi­er des charges du client, reflé­tant l’expression de ses besoins ; de la propo­si­tion tech­nique et com­mer­ciale du prestataire validée par le client, et du plan qual­ité pro­jet (PQP) lorsqu’il existe.

Sou­vent l’expert con­state l’incomplétude ou le manque de pré­ci­sion de ce référen­tiel contractuel.

Reconstruire l’histoire

En sec­ond lieu, l’ex­pert doit recon­stru­ire le scé­nario du pro­jet : qui a fait quoi et quand ? À cet effet sont notam­ment à sa dis­po­si­tion les comptes ren­dus des instances de pilotage du pro­jet : comités stratégiques, comités de pilotage, comités tech­niques, etc., et les échanges de cour­ri­ers et de cour­riels dans lesquels se trou­vent sou­vent des infor­ma­tions impor­tantes pour l’expertise.

Enfin, en troisième lieu, l’ex­pert analyse les griefs exposés par les par­ties, lesquels sont con­sti­tués par des écarts entre ce qui a été fait et ce qui aurait dû être fait, puis les caus­es 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 respon­s­able de l’a­vance­ment du pro­jet, mais le client est acteur dans la mesure où l’a­vance­ment dépend d’une part de ses pro­pres ressources et com­pé­tences et d’autre part de cer­tains jalons qui sont de sa respon­s­abil­ité unique.

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

Les griefs de cette phase sont de qua­tre natures : retard de telle ou telle tâche du pro­jet ; dépasse­ment des ressources affec­tées à telle ou telle tâche du pro­jet ; écarts avec la démarche méthodologique du PQP ; enfin, risques (délais, ressources, coûts) qui auraient dû être iden­ti­fiés et men­tion­nés claire­ment dans le reg­istre des risques du projet.

Cha­cun des qua­tre griefs ci-dessus peut être imputable au client ou au prestataire. L’ex­per­tise devra faire la part des choses.

Analyse des besoins : lacunes et imprécisions

La phase d’analyse des besoins est sou­vent à l’o­rig­ine de dif­fi­cultés majeures sur les pro­jets. Elle est fondée sur une col­lab­o­ra­tion étroite entre le prestataire et le client, sous la forme d’ate­liers d’analyse par thèmes, don­nant lieu à des comptes ren­dus rédigés par le prestataire et relus et validés par le client.

Le client est réputé aver­ti de la déf­i­ni­tion de ses besoins, avoir la con­nais­sance de ses besoins. Un dossier d’analyse validé par le client con­stitue le nou­veau référen­tiel de l’ex­pres­sion des besoins, qui com­plète le cahi­er des charges contractuel.

En général, au cours de la phase d’analyse, on décou­vre que l’ex­pres­sion des besoins ini­tiale est incom­plète ou impré­cise et doit être détail­lée sur de nom­breux points, voire cor­rigée. De nou­veaux écarts (besoins non cou­verts) sont donc identifiés.

Les griefs retenus dans notre exem­ple sont de qua­tre natures : des écarts n’ont pas été iden­ti­fiés pen­dant la phase d’analyse ; des écarts iden­ti­fiés ne pou­vaient être détec­tés à la lec­ture du cahi­er des charges ini­tial ; le besoin n’est pas resté sta­ble entre le cahi­er des charges et le dossier d’analyse ; la démarche de réso­lu­tion des écarts n’a pas été cor­recte­ment appliquée (recherche de solu­tion de paramé­trage ou de con­duite de change­ment avant d’engager un développe­ment spécifique)

Conception et paramétrage ou développement

Le prestataire est claire­ment le respon­s­able de cette phase. Tout man­que­ment (erreur tech­nique, indisponi­bil­ité de ressource, défaut de com­pé­tence, retard d’exécution, etc.) lui est donc imputable sauf cas par­ti­c­uli­er, comme, par exem­ple, un jalon de val­i­da­tion non respec­té par le client.

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

La phase de reprise de don­nées est sou­vent à l’origine de dif­fi­cultés majeures sur les pro­jets. Elle est de la respon­s­abil­ité du client, mais requiert une col­lab­o­ra­tion étroite entre prestataire et client. En effet, le client est respon­s­able du net­toy­age des don­nées exis­tantes, de l’extraction des don­nées, de la val­i­da­tion des don­nées con­ver­ties (avant charge­ment) et de la recette de l’intégration des don­nées (après chargement).

Le prestataire est respon­s­able des spé­ci­fi­ca­tions de reprise, de la con­ver­sion des don­nées extraites (avant charge­ment), des pro­grammes d’injection et du charge­ment des données.

Recette : la responsabilité du client

Le client est glob­ale­ment respon­s­able de la recette. Le prestataire a prin­ci­pale­ment en charge les livraisons du progi­ciel ou logi­ciel pour recette et les cor­rec­tions des anomalies.

Dans notre exem­ple, l’analyse des griefs de la phase recette porte sur les ques­tions suiv­antes : les scé­nar­ios de tests sont-ils con­formes aux dossiers d’analyses ? Les retards ont-ils pour cause le délai de déroule­ment des tests (respon­s­abil­ité du client) ou le délai de cor­rec­tion des anom­alies iden­ti­fiées par le client (respon­s­abil­ité du prestataire)?

Les anom­alies non cor­rigées en fin de recette sont-elles accept­a­bles en regard des con­di­tions d’acceptation de recette définies au PQP, lequel dis­tingue les anom­alies blo­quantes, majeures et mineures ?

Accord amiable

J’ai présen­té un cas représen­tatif des exper­tis­es ordon­nées par un tri­bunal, à la demande d’une par­tie, suite à l’abandon d’un pro­jet de mise en œuvre de sys­tème d’information, que ce soit la réal­i­sa­tion d’un développe­ment spé­ci­fique ou l’intégration d’un progiciel.

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

Ces exper­tis­es sont par­ti­c­ulière­ment com­plex­es du fait de la col­lab­o­ra­tion étroite ayant existé entre les par­ties pen­dant le pro­jet et de l’absence de régle­men­ta­tions ou de normes par­ti­c­ulières. L’expert com­mence par une prise de con­nais­sance du référen­tiel con­tractuel et une recon­sti­tu­tion de l’historique du projet.

Ensuite, pour chaque phase du pro­jet, l’expert analyse les griefs exposés par les par­ties, lesquels sont con­sti­tués par des écarts entre ce qui a été fait et ce qui aurait dû être fait, puis les caus­es de ces écarts et à qui elles sont imputa­bles. Certes, l’expert ne reçoit pas pour mis­sion de con­cili­er les parties.

Néan­moins, une exper­tise bien con­duite per­met de rétablir un dia­logue entre les par­ties et de don­ner à cha­cune une vision claire de ses forces et faib­less­es. C’est pourquoi, dans la grande majorité des cas, l’expertise aboutit à un accord ami­able qui met fin au lit­ige, et cela en cours d’expertise ou après le dépôt du rap­port de l’expert.

---

Articles similaires :

Quand le juge con­sulaire fait appel à l’expert judiciaire L’expertise en con­seil dans un monde de plus en plus com­plexe et volatile Un mod­èle péd­a­gogique unique pour des futurs experts en informatique Des exper­tis­es sec­to­rielles pour des usages opti­misés et une trans­for­ma­tion réussie Le défi du décideur face à l’incertitude Le cuiv­re, ses alliages et les épidémies