Cet article constitue le deuxième article #2 du cycle sur l’échec du projet informatique (et comment l’éviter !).

De nombreux outils juridiques peuvent être mis en place afin d’encadrer l’exécution d’un contrat informatique : cahier des charges, PAQ, pénalités de retard.

Toutefois de tels outils juridiques peuvent être considérés avec un prisme négatif par les opérationnels : le contrat[1] peut devenir principalement un moyen de pression du client sur le prestataire.

Or, cet état d’esprit ne doit pas être celui des contrats pour lesquels l’obligation de collaboration est fondamentale pour réussir le projet, notamment les projets informatiques. En outre, le contrat vécu est en effet rarement celui qui a été conçu avant le démarrage des travaux ^[2].

C’est pourquoi, nous pensons que ces outils juridiques doivent plutôt être utilisés, avec d’autres, pour anticiper les événements probables qui pourraient venir perturber l’exécution des obligations prévues ou permettre au contrat de s’adapter.

Certains diront que les clauses rendant flexible l’exécution du contrat, seront « maitresse de la pagaille ». Elles limiteraient les possibilités de parvenir au succès du projet, car le prestataire qui ne subit pas de pression ne réalise pas idéalement son service. C’est une vision qui nous paraît obsolète. La transparence et la prise en compte de la réalité du projet doivent être les maîtres mots d’un projet de ce type.

En appréhendant ces outils différemment, le client obtiendra le projet le plus adapté à sa situation dans son contexte. Et surtout il disposera d’outils pour essayer d’éviter l’échec. Ce mode d’appréhension des projets permet même souvent de dépasser les limites de ce qu’il est possible d’espérer avec un contrat rigide, qui n’évolue pas avec la situation réelle du projet.

Nous présenterons donc ci-dessous des outils pratiques permettant d’équilibrer rigidité voulue par le client et flexibilité préférable pour le prestataire, en fonction des trois paramètres fondamentaux des projets informatiques : les besoins, les délais et les prix^[3].

1. Bonnes pratiques et outils juridiques pour appréhender les besoins évolutifs du client

La difficulté lorsqu’il est question des besoins est que le client pense avoir exprimé son besoin en totalité dès le départ (phase de RFQ) ou lors de la conception et se retrouve en phase de test avec un logiciel inadapté à ce qu’il souhaitait réellement ; de son côté, le prestataire a recensé les besoins de son client, mais malgré le travail accompli, celui-ci se révèle mécontent de la prestation fournie.

La conséquence de cette difficulté se révèle désastreuse pour le projet informatique. Lorsqu’il est question d’examiner la situation après quelques mois de projet, on s’aperçoit parfois que le besoin n’avait pas été exprimé de manière suffisante par le client. Ce qui peut être considéré comme une faute pour le prestataire^[4] ou une légèreté pour le client en l’absence de cahier des charges pourtant demandé par le prestataire^[5]. Or, l’inexistence, l’inconstance, le manque de clarté entraînent des objectifs instables menant à un potentiel projet sans fin.

Plusieurs outils peuvent permettre d’anticiper ces risques.  

Cahier des charges : Le pire dans un projet est de se rendre compte le jour de la recette que le système réalisé ne contient pas l’ensemble des fonctions essentielles souhaitées. Or, cette situation a fréquemment pour origine d’une part, l’absence de document suffisamment précis pour exprimer le besoin souhaité et d’autre part, l’absence d’implication suffisante des utilisateurs finaux dans le processus d’expression de besoin.

Il convient donc impérativement de rédiger un cahier des charges. Mais ce cahier des charges est parfois insuffisant pour des projets dépassant 1500 jours hommes (environ un an de projet).

Expression de l’existant et documentation des processus : Des documents spécifiques doivent donc également être transmis en fonction des types de projet réalisés. Par exemple, pour l’intégration d’un système de gestion de relation client, il convient également de préparer les documents permettant de décrire l’ensemble des règles de gestion existantes au sein de l’entreprise^[6], en plus du cahier des charges.

Le contrat doit également prévoir la transmission de ces documents avec un délai de transmission bref (habituellement 15 jours) et intégrer ce processus de communication au PAQ (voir plus bas).

Implication des utilisateurs : Par ailleurs, le contrat doit prévoir, pour toutes les phases du projet, l’implication des utilisateurs (point également à intégrer au PAQ) :

• en avant vente, le contrat doit valider le fait que le cahier des charges a été réalisé avec l’implication des utilisateurs qui ont pu exprimer, vérifier la formulation et valider le besoin^[7] ;
• en phase de cadrage et de conception, le contrat doit prévoir l’implication des utilisateurs lors des ateliers (ou lorsque leur mobilisation serait trop coûteuse – qu’ils soient toujours avisés des besoins exprimés – leur disponibilité est indispensable) ; un nombre précis d’utilisateurs impliqués peut être inscrit au contrat et les conditions de leur mise à disposition doivent clairement être décrites ;
• en phase de recette, ce sont les utilisateurs qui doivent tester la solution sur la base des besoins qu’ils savent avoir exprimés ; seuls ceux qui ont exprimé le besoin (ou l’ont validé) doivent pouvoir valider les développements ou ouvrir un ticket d’anomalie.

Processus de gestion des changements : Le contrat devra également anticiper les changements survenant dans le besoin. Ces changements sont constants dans un projet qui dépasse 1500 jours hommes (environ un an). En effet, un projet de cette taille s’étale dans la durée.

La durée implique des changements d’état d’esprit, ou des besoins affinés, ce qui entraîne presque mécaniquement la volonté du client d’ajouter ou de supprimer un besoin. Le client se rend souvent compte qu’il est possible d’optimiser son besoin en retirant une tâche qui finalement après réflexion se révèle chronophage et qui peut être économisée.  

Mais il convient de trouver un juste équilibre entre ces changements et le respect des délais et du budget du projet. C’est pourquoi, il convient de définir dans l’annexe Plan d’assurance qualité un processus strict pour gérer les changements.

Ce processus implique de définir en amont objectivement les priorités (un sponsor du projet chargé de défendre les priorités du projet peut être nommé au sein de l’équipe projet du client).

Escalade : En cas de litige sur le périmètre du projet entre maître d’œuvre et maître d’ouvrage, un processus d’escalade doit être prévu (comité de pilotage ou direction).

2. Les outils juridiques permettant d’assurer une flexibilité des délais

Un calendrier établi en toute transparence et adaptable sous conditions : Le délai de réalisation se définit en relation avec les deux autres facteurs du projet : besoin^[8] et budget. En général la racine cubique de la charge définit le délai en mois d’un projet (1500 jours hommes étant environ équivalents à 12 mois de projet^[9]). Or, la charge d’un projet dépend essentiellement du périmètre du projet.  

Ces interactions entre les délais, le budget et le besoin ne suffisent pas à garantir le respect des délais. En effet, après avoir déterminé le délai du projet, il faut encore que celui-ci soit respecté par un pilotage de projet.

Or, un tel pilotage est parfois très délicat à mettre en œuvre pour un prestataire qui par nature rend un service^[10] à ses clients. Un juste milieu doit donc être trouvé entre autorité et subordination du prestataire envers son client.

Cette contrainte, ajoutée à la nécessaire flexibilité du contrat, nous laisse penser qu’il ne faut pas prévoir de calendrier impératif rigide dans les contrats de projet informatique.

Le calendrier nous semble devoir être impératif bien sûr, mais adaptable sur acceptation des parties et sous conditions d’évolution des paramètres d’origine.

Pour faciliter l’acceptation du client, il faut qu’en premier lieu un débat ait eu lieu entre les parties sur la manière d’établir le calendrier. Les équations de ce débat doivent donc être définies en annexe du contrat et la transparence doit être le principe : par exemple 10 items de projet complexes et 5 moins complexes génèrent une charge de 200 jours de développement. Si un paramètre change en cours de projet, l’adaptation du calendrier est plus facile. Il est donc nécessaire d’éviter que le calendrier soit défini à huis clos par le prestataire seul. Il doit l’exposer au client afin que ce dernier sache sur quelles bases objectives les délais ont été calculés.

Plus précisément les dates choisies doivent prendre en considération la culture d’entreprise et les contraintes du client autant que du prestataire. Ces contraintes doivent être indiquées dans l’annexe (avec un PERT^[11] par exemple). Par exemple, l’impossibilité pour le client de mettre à disposition tous les utilisateurs pendant les ateliers de conception est une contrainte qui nécessite d’être prise en considération dans les délais du projet. Certains utilisateurs devront être contactés par le client, pour obtenir des informations à transmettre au prestataire. Ces informations n’auront pas été discutées en atelier. Le temps de traitement pourrait donc être rallongé.

Macroplanning détaillé : Dans ce cadre, la seule date de déploiement ne suffit pas. Les autres dates sont fondamentales pour fixer des objectifs afin d’atteindre une date de planification réaliste. Il doit contenir un macro planning (par lot et par phase) et un micro planning (par tâche).

Par ailleurs, une marge de manœuvre doit être prévue et acceptée par le client. Cette marge de manœuvre doit être objective : concrètement inscrite dans le contrat (à deux mois près par exemple).

Le contrat doit en outre prévoir une discussion sur le calendrier à chaque Copil (environ tous les quinze jours).

Des modifications possibles et justifiées : Et dans ce cadre, la souplesse du calendrier impératif doit se trouver dans le processus de modification du calendrier. Les modifications doivent être soumises à une validation des deux parties sur la base d’éléments légitimes définis de manière exhaustive dans le contrat.

Le contrat prévoit donc une clause de type : « le calendrier peut faire l’objet de modifications exclusivement dans les cas suivants : 1) évolution du besoin ; 2) consentement des deux parties en comité de pilotage ; 3) complication dans la définition d’un besoin précis qui devra être défini ; 4) force majeure… ». Cela évite également que le prestataire ou le client ne demandent le décalage du planning pour des raisons extérieures au projet (gestion d’un autre projet…).

Chaque décalage du projet ou chaque demande complémentaire, devra donner lieu à une étude d’impact bien sûr.

Les mécanismes à éviter : selon nous les pénalités de retard ainsi que les success fee ne paraissent pas indispensable pour éviter les litiges entre les parties sur les délais. Ces mécanismes sont communément considérés comme des moyens d’éviter la démotivation du prestataire ou pour le motiver. Or, les difficultés de gestion de projet ne sont généralement pas liées à la démotivation du prestataire. Ces mécanismes peuvent donc être prévus au contrat pour gérer les risques de retard, mais il ne faut pas espérer qu’ils seront déterminants pour éviter l’échec des projets.

3. Les outils juridiques de flexibilité du budget

Une phase de cadrage : Comme les délais, le prix dépend en grande partie du périmètre du projet. Or, l’estimation des charges dans un projet informatique est sans aucun doute l’une des tâches les plus délicates pour le prestataire, notamment parce que le périmètre n’est en général pas tout à fait défini au début du projet.

Les masses financières peuvent se révéler non pertinentes ; les ratios d’évaluation peuvent ne pas être suffisamment caractéristiques du projet pour effectuer une comparaison avec des projets similaires. Certaines étapes du projet peuvent également être ignorées, ce qui fausse le calcul.

C’est pourquoi notre première recommandation est d’insérer au contrat une phase de cadrage. En effet, en avant-vente, le prestataire aura nécessairement des difficultés à définir un budget précis alors même qu’il n’a pas encore analysé les besoins de manière détaillée. La relation est déséquilibrée lorsque seul le prestataire porte le risque de l’aléa impliqué par l’absence de définition du besoin du client. Quant au client il croit qu’il est protégé par le forfait convenu, alors même qu’il n’a pas précisément^[12] expliqué ce qu’il souhaitait ! Une nouvelle discussion sur le prix doit donc être prévue après la validation de la phase de cadrage. Et en l’absence d’accord à la suite du cadrage, une sortie du contrat doit être possible pour les deux parties.

Une régie plafonnée : une autre possibilité serait la mise en place d’une régie plafonnée et non d’un forfait. Le forfait peut parfois apparaître trop risqué dans le cas d’un projet d’intégration informatique et la régie génère un risque de coût important pour le client.

La régie plafonnée peut avoir l’avantage d’obliger à une nouvelle discussion.

Et pour éviter les demandes intempestives du prestataire, il est possible d’inscrire dans le contrat un indice d’incertitude^[13] fondé sur des justifications précises. Cela permet au client de se rendre compte, en fonction de facteurs qui sont spécifiques, de la difficulté du prestataire à estimer les charges de son projet.

Des charges déterminées de manière transparente par le prestataire : dans le contrat, il nous paraît important d’être très transparent quant à la manière d’estimer les charges. Pour cela, une méthode collaborative doit être mise en œuvre avec le client. Le projet informatique est un projet de collaboration, l'estimation des charges doit selon nous être réalisée en énonçant précisément les équations ayant permis d’arriver au budget proposé par le prestataire. Le calcul du prix de vente en soi n’a pas nécessairement à être communiqué car il dépend de la stratégie globale du prestataire. Néanmoins, le contrat devra prévoir que les prix ont été définis en commun avec le client, qui a pu prendre connaissance des méthodes utilisées pour les charges de production (COCOMO, Delphes, point de fonctions…) et les charges de pilotage.

Ces précisions en annexe du contrat permettront au client et au prestataire de prévoir ensemble les charges du projet de façon précise et rigoureuse. Le manque de transparence dans ce domaine, crée l’incompréhension du client. Le client refuse alors de payer la valeur réelle du projet. Ou alors il existe une sous-évaluation qui cause d’autres dérives du projet.  

Limitation de responsabilité : Enfin, il est fondamental d’ajouter dans le contrat une clause limitative de responsabilité. Le prestataire et le client doivent se mettre d’accord sur un budget maximal de risque, que les deux parties acceptent de prendre en charge en cas de faute. Il est également important de définir objectivement la valeur globale du risque du contrat permettant au prestataire d’anticiper les dépenses que le client envisage d’engager (et donc son éventuelle responsabilité).

4. Prévoir un PAQ

Le dernier outil qui peut être cité est bien sûr le PAQ (plan d’assurance qualité ou PQP plan qualité projet). Ce PAQ est l’outil essentiel et central de la gestion de projet.

Le PAQ doit nécessairement contenir les modalités pratiques de la gestion de projet et notamment :

• Les comités du projet (Copil, coproj, coano etc.), leurs rôles et responsabilités
• La gestion de la documentation projet
• La gestion des changements
• Les rôles et responsabilités des parties (RACI)
• Les indicateurs de suivi
• Les définitions des phases du projet et leur exécution
• Les conditions de recette / réception des livrables

Cet outil est quasiment un contrat par lui-même et les juristes ne doivent pas déléguer sa rédaction aux opérationnels. Le PAQ s’il est respecté et suivi est un outil puissant pour assurer une gestion de projet claire et transparente.

Conclusion : Cet article montre que les projets informatiques nécessitent un équilibre entre rigidité et flexibilité. Cet équilibre passe dans une très large mesure par une collaboration étroite, donc une transparence, entre le client et le prestataire. Quand bien même le client attend du prestataire un service qui lui permet d’obtenir le projet qui lui convient, il ne pourra pas bénéficier de son projet en laissant le prestataire en complète autonomie dans ce domaine.

Le client doit également prendre sa responsabilité dans la gestion du projet qui est réalisé pour lui. Il doit donc participer au projet et disposer de toutes les informations fondamentales pour comprendre les tenants et aboutissant du dimensionnement de son projet.

Ces outils (document d’expression de besoin, processus de gestion des changements, calendrier impératif souple, équation de calcul des délais ou du budget définis entre les parties…) sont caractérisés par des informations qui doivent figurer au contrat pour une plus grande sécurité juridique.

∞

Dans le cadre du cycle sur les moyens d’éviter l’échec du projet informatique qui est en cours, nous aborderons les thèmes suivants :

• #3 le contract management pour éviter l’échec du projet informatique ;
• #4 l’exposition d’une méthodologie de projet adapté à la collaboration avec le client : la méthode agile ;
• #5  les outils pour éviter le contentieux ;
• #6  les moyens de mener son contentieux ;
• #7  les typologies d’expertises.

[1] Nous entendons par contrat l’ensemble intégrant ces annexes qui sont souvent nombreuses dans les contrats informatique – intégrant PAQ, PAS, Prix.

[2] Le Tourneau, Philippe. Contrats du numérique: informatiques et électroniques. Onzième Édition remaniée et Augmentée, mise À jour au 26 juin 2020. Dalloz référence. Paris: Dalloz, 2020, §116.21, p. 144.

[3] Certaines précisions sont issus de l’ouvrage suivant : A. Durand, Maître d’œuvre des projets informatiques, Dunod, Paris, 2004.

[4] Grenoble, 4 juin 2015, 11/01817.

[5] Paris, 8 juill. 1981, M. Claude B. c/ SARL Kienzie Informatique.

[6] Il est ici question d’une situation sans prestation de redéfinition des processus de l’entreprise qui dans ce cas doit donner lieu à de nouvelles réflexions entre le prestataire et le client modifiant les procédures en place. L’existant peut néanmoins être nécessaire, mais dans une moindre mesure.

[7] Il convient de penser à toutes les interfaces et à la migration dans ce cadre s’il s’agit d’un projet d’intégration.

[8] C’est également vrai pour le besoin, le besoin peut être contraint par le budget et la durée. Cependant, nous pensons que le fait de définir le besoin dans un cahier des charges antérieur à la première prise de contact avec un prestataire implique qu’il soit à l’origine de la détermination des délais et du budget. Ce besoin peut être limité après cette première prise de contact, mais les cahiers des charges trop ambitieux sont cependant relativement rares.  

[9] V. à ce titre l’ouvrage de A. Durand, op. cit, p. 91.

[10] Onéreux, mais service tout de même.

[11] Program evaluation and review technique.

[12] Comme indiqué ci-dessus, le cahier des charges ne suffit pas. Des choix doivent ensuite être faits par le client en fonction des spécificités du logiciel ou du site internet qu’il souhaite.

[13] Peut-être basé sur le volume prévisible de besoin, la charge courante…