Un client et un fournisseur qui se choisissent, s’entendent, contractualisent et finalement réalisent un projet, c’est un mariage réussi. Chaque étape aura contribué au succès et le contrat sera rempli. Pour autant, un client et un fournisseur qui se choisissent et contractualisent ont un long chemin à parcourir.
On comprend alors l’importance des enjeux du contrat informatique : mariage ou guerre des mondes ? Succès ou échec ? …avec toute la palette des dégâts collatéraux : dérapage des plannings, dépassements budgétaires, frustration des équipes et objectifs métiers non atteints. Plus que jamais, c’est à la signature du contrat qu’il faut s’assurer que l’on parle bien le même langage.
Contractualiser un projet informatique est une lourde tâche. Après le choix du fournisseur ou de la solution, vient effectivement le temps de la négociation, du cadrage et de la construction du projet. L’ensemble de ces actions devra être synthétisé dans le contrat. Tout manquement erreur ou omission fait peser une menace sérieuse sur l’aboutissement du projet, que les soucis soient d’ordre organisationnel (pas assez de ressources, pas de ressources compétentes), financier (dépassement budgétaire, menaçant la rentabilité) ou fonctionnel (périmètre trop restreint ou trop large, besoins non exprimés).
Le contrat, au-delà du juridique
Dans ce contexte le contrat est plus qu’un outil juridique. Il doit être envisagé comme un outil de construction, une référence, un guide opérationnel auquel l’ensemble des acteurs pourra se référer. La contractualisation apparait dès lors comme un projet en lui-même ayant pour objectif de fournir le cadre et les moyens d’une relation saine entre le client et son fournisseur.
La qualité de la relation ainsi mise en œuvre est un gage de succès. Ainsi, pour un contrat de logiciel en mode SaaS (« software as a service ») dans le domaine du jeu et des paris, la roadmap définie et annexée sert toujours, un an et demi après la signature, de référence. La vision des acteurs métier qui ont contractualisé était pertinente. Retranscrite fidèlement dans le document elle constitue aujourd’hui une partition que les acteurs interprètent avec conviction. La vie des projets informatiques est effectivement jalonnée d’imprévus et il faut les appréhender de façon pragmatique.
Le contrat est un document relativement figé, mais il doit laisser une place aux changements, s’ils sont pertinents. En effet, ces derniers ne doivent-être ni évités ni repoussés, mais traités avec des moyens adaptés. Les méthodes « agiles » découlent directement de cet objectif de réactivité du SI par rapport à son environnement.
Anticiper les risques
Par exemple, le cahier des charges pris comme référence unique pour valider la solution porte en son sein un risque de méthode. Les besoins métiers peuvent évoluer pendant la phase de conception d’un projet et la description initialement figée dans le contrat peut se révéler approximative ou fausse.
Si le contexte l’exige, le responsable du contrat devra alerter les contractants et proposer un dispositif contractuel qui permettra de compléter ou de réviser aussi souvent qu’il le faudra, le référentiel du contrat. Il proposera des rendez-vous – ateliers et comités – pour affiner la conception de la solution et en cadrer le référentiel.
Les phases de réalisation pourront alors leur succéder. On voit donc une alternative à l’exemple cité précédemment (roadmap détaillée et contractualisée) : les équipes affinent au fur et à mesure la solution et alimentent un référentiel documentaire qui fera partie du périmètre contractuel.
La phase de conception peut alors être étalée dans le temps ce qui procure une certaine souplesse au client. La collaboration est la pièce maitresse du dispositif « agile » : c’est la collaboration entre les équipes dans des instances adaptées qui permettra de construire ou de modifier le référentiel du contrat. La gouvernance fournit le cadre dans lequel s’exprimera la richesse des équipes. A la notion de cahier des charges on préfère alors celle de ‘BackLog’ : la solution est spécifiée par les équipes client et fournisseur en collaboration étroite et par itérations successives.
Le lotissement est l’autre clef de la souplesse : il parait en effet prudent de se préparer à viser une cible mouvante. L’objectif du projet informatique peut alors être reformulé ainsi : « utiliser au mieux la capacité à faire et le temps disponible pour satisfaire le besoin métier ». Le lotissement est alors un processus continu et on cherchera tout au long du projet à découper et à prioriser les réalisations en fonction de leur valeur métier et de leur complexité technique.
Chaque phase de réalisation suivra les étapes classiques du cycle en V, conception, spécification fonctionnelle, spécification technique, développement, recette, formation, mise en production et assistance post-démarrage. Les risques de mauvaise surprise – après des périodes longues ou les équipes travaillent en tunnel -, sont ainsi réduits.
A chaque lot, la collaboration entre les équipes permet de réduire les écarts entre la solution livrée et la cible à atteindre car les écarts seront constatés conjointement et dans un délai court.
On se trouve alors dans des conditions adaptées pour affiner la solution et donc pour répondre au besoin. Cette pratique se retrouve dans les projets web: les technologies et possibilités graphiques évoluent vite et les équipes doivent être réactives pour proposer des solutions correspondant à l’état de l’art du moment. Rien n’est pire en termes d’image, qu’une page web dont la technologie est dépassée dès le jour de mise en ligne… Les équipes travaillent donc par « sprints » successifs. Sur des périodes de 2 mois et sur des lots dont le découpage est adapté.
Les priorités sont revues, les besoins sont vérifiés, les solutions sont précisées puis réalisées, testées et déployées dans ces périodes courtes. Certes cette pratique n’est pas possible avec toutes les technologies, certes elle nécessite en permanence une forte implication des équipes et elle a donc un cout, mais elle est réellement sécurisante en comparaison à des projets qui ne livreront leur résultat qu’après une longue période de réalisation et en une seule fois.
Le contenu d’un bon contrat
La structure classique des contrats informatiques n’est pas pour autant obsolète.
Un défaut de vision, de méthode ou de contraintes se traduira toujours par un coûteux défaut de résultat, quelle que soit la méthode.
– La définition d’un référentiel demeure un impératif. La mise en place du cahier des charges et des spécifications peut être initiale ou progressive mais ce référentiel servira toujours de base au fournisseur pour bâtir la solution. On le retrouvera en annexe principale du contrat :
– Une annexe fixant le périmètre applicatif pourra compléter la définition fonctionnelle de l’application.
– Une annexe technique précisera la technologie et les caractéristiques techniques de la solution à mettre en œuvre. – La liste des prestations attendues devra figurer en annexe. Elle fixera les rôles du fournisseur et éventuellement du client.
– Un Plan d’Assurance Qualité ou un Plan Qualité de Services pourra décrire les processus à mettre en oeuvre, les méthodes et critères de qualité à respecter et les instances de gouvernance qui suivront les réalisations.
– Une convention de services pourra détailler les indicateurs et objectifs qui devront être atteints pour chacun des services attendus. On pourra y ajouter un caractère contraignant en couplant la convention de service à des pénalités financières pour le fournisseur qui n’atteindrait pas les niveaux de services attendus.
– Le calendrier de réalisation sera aussi annexé. Dans l’intérêt du client comme de son fournisseur le planning de réalisation doit être formalisé et le périmètre cadré. Les dérives éventuelles seront d’autant mieux traitées qu’elles seront constatées par rapport à un référentiel connu. Et si le choix de l’agilité est fait, le contrat doit le matérialiser en fournissant les instances et procédures qui permettront de l’encadrer et de le sécuriser. Par exemple, le contrat rendra impératif de formaliser les résultats des groupes de travail. Et à défaut, il en sanctionnera l’absence ou encore l’absence de résultat.
Qu’il s’agisse d’instaurer un référentiel initial qui permettra d’évaluer la solution ou de prévoir le dispositif qui permettra graduellement d’aboutir à ce référentiel, le contrat doit conserver sa fonction contraignante car les taches qu’il encadre sont déterminantes et il ne doit pas laisser de place au hasard.
Faire ses choix en connaissance de cause
Contractualiser c’est anticiper les dérives potentielles et prévoir le dispositif qui -en fonction du contexte- permettra de les empêcher, de les identifier si elles surviennent et d’alerter au plus tôt la hiérarchie des deux parties pour qu’elles puissent réagir avant qu’il ne soit trop tard.
Le responsable de la contractualisation doit donc proposer des réponses adaptées au contexte. Quelques soient la technologie et le degré de maturité du projet il faudra mêler rigueur et agilité pour aboutir à un document pertinent et opérationnel.
Les choix structurants ne sont pas faits pour le contrat mais ce dernier doit en être le reflet. Un contrat visionnaire est certes un atout indéniable pour la réalisation d’un projet informatique. Mais à défaut, une approche agile et collaborative pourra aussi permettre de trouver le meilleur chemin vers la cible. Une optique dynamique pourra se substituer à une vision nette et précise et les contractants pourront en faire le choix sans mettre en danger la solution. L’essentiel est d’en faire le choix en connaissance de cause et de jalonner la vie du projet des rendez-vous et des instances qui permettront de garantir la progression. La gouvernance conserve, au cœur du contrat, toute son importance.
Cet article a été écrit par Julien Lacombe, consultant senior au sein du cabinet Décision Performance Conseil.