L‘expertise judiciaire en informatique :

Douze à dix-huit mois de travail

Les exper­tises ordon­nées par un tri­bu­nal suite à l’abandon d’un pro­jet de mise en œuvre de sys­tème d’information, que ce soit la réa­li­sa­tion d’un déve­lop­pe­ment spé­ci­fique ou l’intégration d’un pro­gi­ciel, repré­sentent de gros enjeux finan­ciers pour les par­ties, au vu des pré­ju­dices consé­cu­tifs à l’arrêt du pro­jet, et sont par­ti­cu­liè­re­ment com­plexes du fait de la col­la­bo­ra­tion étroite ayant exis­té entre les par­ties pen­dant le projet.

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

Primauté au contrat

Contrai­re­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­cu­lières mais essen­tiel­le­ment sur des dis­po­si­tions contrac­tuelles au cas par cas sui­vant 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 mar­ché sont d’une part les socié­tés de ser­vices en ingé­nie­rie infor­ma­tique (SSII) et d’autre part les édi­teurs qui assurent la concep­tion, le déve­lop­pe­ment et la com­mer­cia­li­sa­tion de pro­gi­ciels et four­nissent des pres­ta­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 pres­ta­taire (SSII) signent un contrat qui défi­nit les condi­tions dans les­quelles ils vont col­la­bo­rer pour conce­voir, réa­li­ser, mettre 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 pro­gi­ciel, un contrat simi­laire est signé une fois le choix du pro­gi­ciel effec­tué par le client, ain­si qu’un contrat sépa­ré entre le client et l’éditeur qui défi­nit les condi­tions de la conces­sion au client d’un droit d’utilisation du progiciel.

Établir le référentiel contractuel

L’expert de jus­tice dési­gné par le tri­bu­nal reçoit une mis­sion décrite dans la déci­sion. En pre­mier lieu, l’expert doit prendre connais­sance du réfé­ren­tiel contrac­tuel et notam­ment du cahier des charges du client, reflé­tant l’expression de ses besoins ; de la pro­po­si­tion tech­nique et com­mer­ciale du pres­ta­taire vali­dée par le client, et du plan qua­li­té pro­jet (PQP) lorsqu’il existe.

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

Reconstruire l’histoire

En second lieu, l’ex­pert doit recons­truire le scé­na­rio du pro­jet : qui a fait quoi et quand ? À cet effet sont notam­ment à sa dis­po­si­tion les comptes ren­dus des ins­tances de pilo­tage du pro­jet : comi­tés stra­té­giques, comi­tés de pilo­tage, comi­tés tech­niques, etc., et les échanges de cour­riers et de cour­riels dans les­quels se trouvent sou­vent des infor­ma­tions impor­tantes pour l’expertise.

Enfin, en troi­sième lieu, l’ex­pert ana­lyse les griefs expo­sés par les par­ties, les­quels sont consti­tué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 pres­ta­taire est certes res­pon­sable de l’a­van­ce­ment du pro­jet, mais le client est acteur dans la mesure où l’a­van­ce­ment dépend d’une part de ses propres res­sources et com­pé­tences et d’autre part de cer­tains jalons qui sont de sa res­pon­sa­bi­li­té 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 pro­jet ; dépas­se­ment des res­sources affec­tées à telle ou telle tâche du pro­jet ; écarts avec la démarche métho­do­lo­gique du PQP ; enfin, risques (délais, res­sources, coûts) qui auraient dû être iden­ti­fiés et men­tion­nés clai­re­ment dans le registre des risques du projet.

Cha­cun des quatre griefs ci-des­sus peut être impu­table au client ou au pres­ta­taire. L’ex­per­tise devra faire la part des choses.

Analyse des besoins : lacunes et imprécisions

La phase d’a­na­lyse des besoins est sou­vent à l’o­ri­gine de dif­fi­cul­tés majeures sur les pro­jets. Elle est fon­dée sur une col­la­bo­ra­tion étroite entre le pres­ta­taire et le client, sous la forme d’a­te­liers d’a­na­lyse par thèmes, don­nant lieu à des comptes ren­dus rédi­gés par le pres­ta­taire et relus et vali­dés par le client.

Le client est répu­té aver­ti de la défi­ni­tion de ses besoins, avoir la connais­sance de ses besoins. Un dos­sier d’a­na­lyse vali­dé par le client consti­tue le nou­veau réfé­ren­tiel de l’ex­pres­sion des besoins, qui com­plète le cahier des charges contractuel.

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

Les griefs rete­nus dans notre exemple sont de quatre natures : des écarts n’ont pas été iden­ti­fiés pen­dant la phase d’a­na­lyse ; des écarts iden­ti­fiés ne pou­vaient être détec­tés à la lec­ture du cahier des charges ini­tial ; le besoin n’est pas res­té stable entre le cahier des charges et le dos­sier d’a­na­lyse ; la démarche de réso­lu­tion des écarts n’a pas été cor­rec­te­ment appli­quée (recherche de solu­tion de para­mé­trage ou de conduite de chan­ge­ment avant d’engager un déve­lop­pe­ment spécifique)

Conception et paramétrage ou développement

Le pres­ta­taire est clai­re­ment le res­pon­sable de cette phase. Tout man­que­ment (erreur tech­nique, indis­po­ni­bi­li­té de res­source, défaut de com­pé­tence, retard d’exécution, etc.) lui est donc impu­table sauf cas par­ti­cu­lier, comme, par exemple, un jalon de vali­da­tion non res­pec­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­cul­tés majeures sur les pro­jets. Elle est de la res­pon­sa­bi­li­té du client, mais requiert une col­la­bo­ra­tion étroite entre pres­ta­taire et client. En effet, le client est res­pon­sable du net­toyage des don­nées exis­tantes, de l’extraction des don­nées, de la vali­da­tion des don­nées conver­ties (avant char­ge­ment) et de la recette de l’intégration des don­nées (après chargement).

Le pres­ta­taire est res­pon­sable des spé­ci­fi­ca­tions de reprise, de la conver­sion des don­nées extraites (avant char­ge­ment), des pro­grammes d’injection et du char­ge­ment des données.

Recette : la responsabilité du client

Le client est glo­ba­le­ment res­pon­sable de la recette. Le pres­ta­taire a prin­ci­pa­le­ment en charge les livrai­sons du pro­gi­ciel ou logi­ciel pour recette et les cor­rec­tions des anomalies.

Dans notre exemple, l’analyse des griefs de la phase recette porte sur les ques­tions sui­vantes : les scé­na­rios de tests sont-ils conformes aux dos­siers d’analyses ? Les retards ont-ils pour cause le délai de dérou­le­ment des tests (res­pon­sa­bi­li­té du client) ou le délai de cor­rec­tion des ano­ma­lies iden­ti­fiées par le client (res­pon­sa­bi­li­té du prestataire)?

Les ano­ma­lies non cor­ri­gées en fin de recette sont-elles accep­tables en regard des condi­tions d’acceptation de recette défi­nies au PQP, lequel dis­tingue les ano­ma­lies blo­quantes, majeures et mineures ?

Accord amiable

J’ai pré­sen­té un cas repré­sen­ta­tif des exper­tises ordon­nées par un tri­bu­nal, à 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éa­li­sa­tion d’un déve­lop­pe­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­tises sont par­ti­cu­liè­re­ment com­plexes du fait de la col­la­bo­ra­tion étroite ayant exis­té entre les par­ties pen­dant le pro­jet et de l’absence de régle­men­ta­tions ou de normes par­ti­cu­lières. L’expert com­mence par une prise de connais­sance du réfé­ren­tiel contrac­tuel et une recons­ti­tu­tion de l’historique du projet.

Ensuite, pour chaque phase du pro­jet, l’expert ana­lyse les griefs expo­sés par les par­ties, les­quels sont consti­tué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 impu­tables. Certes, l’expert ne reçoit pas pour mis­sion de conci­lier les parties.

Néan­moins, une exper­tise bien conduite per­met de réta­blir un dia­logue entre les par­ties et de don­ner à cha­cune une vision claire de ses forces et fai­blesses. C’est pour­quoi, dans la grande majo­ri­té des cas, l’expertise abou­tit à un accord amiable qui met fin au litige, et cela en cours d’expertise ou après le dépôt du rap­port de l’expert.

---

Articles similaires :

Quand le juge consu­laire fait appel à l’expert judiciaire Le retour­ne­ment et le redres­se­ment des entre­prises : un domaine d’experts et de spécialistes Des exper­tises sec­to­rielles pour des usages opti­mi­sés et une trans­for­ma­tion réussie L’expertise humaine : levier de crois­sance du conseil en IT Le cuivre, ses alliages et les épidémies