Une diarrhée de papiers

pqAvant d’écrire du code, il faut noircir du papier. Il y a le ou les contrats entre le ou les clients et le ou les prestataires. Ensuite il y a les lettres de mission, les accords de confidentialité, le cahier des charges, le plan d’assurance qualité, l’étude d’architecture et celle d’urbanisme, l’analyse de risque, les spécifications générales et détaillées, fonctionnelles et techniques. Il faut ajouter les cahiers de recettes, les comptes rendus, de comité de pilotage, de directoire…Tous ces papiers font l’objet de comités de relecture, de signatures par des vérificateurs, puis des valideurs.
Tous font partie du contrat au sens d’Oliver Williamson, l’économiste spécialiste des coûts de transaction. L’ensemble de ces documents définit les règles du jeu que doivent respecter les membres de l’équipe projet. Il faut entendre par là, qu’en cas de conflit, tous ces papiers pourront être utilisés devant un juge, qui les considèrera comme ce sur quoi se sont entendues les participants au projet.

Pourquoi ce flot de papier ?

La réponse première est la traçabilité. Les acteurs veulent conserver une trace de la manière et du pourquoi ils ont faits les choses, éventuellement de qui a fait quoi, pour pouvoir le réinterroger. Cette réponse a sa part de vérité.
Les concepteurs-développeurs sont obsédés par la traçabilité. D’abord parce que c’est l’un des atouts majeurs du système d’information numérique par rapport à ceux qui l’on précédé. Les membres d’un projet chercheront à mettre de la traçabilité partout.
Ensuite parce qu’ils ont souvent perdu du temps à rechercher les processus et modes opératoires des systèmes d’informations précédents. Ils espèrent ainsi préparer les évolutions du système d’information, se donnant à eux-mêmes ou à leurs successeurs des informations précieuses. Le risque c’est que trop d’information tue l’information, et que cette masse touffue de données constitue un massif impénétrable malgré tous les moteurs de recherche.
Mais, la réécriture constante du contrat a une autre cause. Nous avons été éduqué dans la crainte du Pater Familias, et sommes habitués au comportement indiscipliné et rebelle des enfants. L’économie de marché nous permet d’éviter les inconvénients de cette indiscipline. L’échange est quasi instantané (aujourd’hui sur les marchés de valeurs une nanoseconde). Il ne laisse pas le temps de la tromperie et celle-ci est d’ailleurs sévèrement réprimée par la justice et la police. Mais dans le projet, il va falloir collaborer pendant des semaines, voire des mois avec les autres en espérant qu’ils ne joueront pas aux enfants rebelles. Le contrat est donc une règle du jeu, qui doit être assez souple pour s’adapter aux évènements qui auront lieu au cours de la réalisation du projet, et assez précise pour s’opposer aux tentatives d’opportunisme des partenaires. Tout au long du projet, les documents fournis, validés et revalidés permettront de préciser ou de modifier ce contrat.

Que trouve-on dans ces papiers ?

Le contrat peut être découpé en cinq chapitres qui se retrouvent toujours dans l’ensemble des papiers échangés : l’objet, les modalités d’exécution, les procédures de résolutions de conflit, la gestion des suites du contrat, les modalités de partage de la valeur.
L’objet c’est le produit ou le service que le projet est en charge de construire. Au fur et à mesure de l’exécution, sont produits des documents précisant de plus en plus ce produit. Cela commence par le cahier des charges établi par le maître d’ouvrage ou son assistant. Il s’agit d’un document à mi chemin entre la lettre au Père Noël et le manuel d’inquisition, où ont été consignés tous les espoirs dans le produit envisagé et toutes les règles et lois qu’il devra respecter. Cela finit par les spécifications techniques et fonctionnelles détaillées qui détaillent l’algorithme, et jusqu’à la couleur des écrans, la forme et la taille des icones, la marque des imprimantes.
Ensuite, il y a la description des ressources mises à disposition du projet, les personnes qui y participent, le chef de projet et l’organisation, leurs conditions de travail (locaux, badge d’accès, accords de confidentialité, matériels, …), il faut aussi préciser les documents et informations à échanger. Le maître d’œuvre ne pourra pas commencer son travail sans connaître les processus et procédures en cours au départ, celles qui peuvent être modifiées celle qui sont intangibles, les documents, les règlements intérieurs ,les lois sur lesquels devra s’appuyer le projet. A l’inverse le maître d’ouvrage aura besoin de connaître le résultat, les nouvelles procédures qu’impose le nouveau système d’information. Il n’y a pas besoin de disposer de tout à départ, mais il faudra préciser à quel moment ces documents sont nécessaires et les procédures de contournement à prévoir s’ils ne sont pas fournis. Ces chapitres sont essentiels. Plus la collaboration est intense, plus le projet avance vite, et moins l’une des parties pourra avoir un comportement opportuniste.
Les nouveautés apparues pendant l’exécution vont donner lieu à des arbitrages. Et qui dit arbitrage dit conflit potentiel. Aucune des parties d’un projet n’a intérêt à un procès. Ils ont tous de l’argent déjà dépensé et inutilisable tant que le produit final n’est pas livré. Ces capitaux immobilisés dictent leur conduite. Aller au procès, c’est faire intervenir un interlocuteur extérieur, qui ne connaît ni le sujet ni le contexte, donc c’est une source de perte de temps et d’argent, sans parler de l’aléa de faire intervenir quelqu’un qui peut avoir un avis totalement différent de celui des parties sur ce qu’est un projet et un système d’information. Tout est donc organisé pour éviter d’aller jusque là. Il y a d’abord le comité de pilotage qui permet de se concerter entre membres de l’équipe projet, si besoin le comité de contrat où sont discuté les aspects financiers entre acheteurs et commerciaux des prestataires , le Directoire où se rassemblent les hiérarchiques qui s’efforcent d’aplanir les litiges. Si le litige n’a toujours pas été réglé, il reste le recours à l’arbitrage. Les deux parties choisissent un tiers, compétent sur le sujet concerné, dont les deux reconnaissent l’impartialité et la compétence, et dont ils espèrent qu’il rendra un arbitrage équilibré et rapide. Si enfin rien n’a été réglé, il faudra passer à l’étape ultime, le passage devant le juge, investi de l’autorité de l’Etat, mais qui découvrira bien tard le projet et sa volumineuse documentation. Et il est préférable que les deux parties se soient mis d’accord au préalable sur le choix du juge (tribunal de Paris, de Londres, de New York ?), et du droit applicable (français, allemand, américain, Belouchistanais ?). Si la question n’est pas tranchée c’est le premier qui saisit un tribunal qui gagne.
Quatrième aspect du contrat, la gestion des suites du contrat. La documentation du système est d’abord définie, quels documents, où ils sont classés, qui doivent les produire. Ensuite les parties doivent s’entendre sur les garanties. Dans le monde du numérique, les garanties légales ne jouent pas beaucoup. La garantie pour vice caché, la garantie décennale, ou la garantie biennale ne joue pas de rôle significatif. Ce sont les garanties contractuelles qui définissent qui doivent payer en cas d’erreur. Un autre aspect de l’après projet fait l’objet de clauses complexes et détaillées, la propriété intellectuelle du produit. Ce dernier sujet fera l’objet d’amples développements dans d’autres chroniques.
Dernier aspect du contrat, le paiement des prestataires. Quelle va être la répartition de la valeur entre les différents participants au projet ? La valeur d’usage du système d’information produit reste au maître d’ouvrage. Le produit est fait pour lui, pour répondre à ses besoins, et donc il en retire le bénéfice direct par l’usage. Il lui revient donc de rétrocéder une partie de cette valeur générée aux différents autres participants du projet (maître d’oeuvre, assistant maître d’ouvrage, PMO…). Comme la valeur exacte du produit n’est pas connue à l’avance (voir facteur PI), il faut mettre en place des mécanismes complexes pour définir la part de valeur rétrocédée pendant l’avancée du projet.
Cela commence par des prix détaillés : prix de l’heure ou de la journée, d’ingénieur ou de technicien (les grilles de rémunérations peuvent être inépuisables), coût de mise à disposition de matériel. Le développement du SAAS complexifie les unités de paiements. Le SAAS (Software As A Service : logiciel comme un service) est une pratique en plein développement où le maître d’oeuvre au lieu de construire un système d’information pour le maître d’ouvrage d’information, met à disposition un service et est rémunéré en fonction de ce service (nombre de kilo-octets stockés, nombre de lettres traitées, nombre de lignes comptables, etc.). Quelle que soit l’unité choisie, l’important est que la quantité puisse faire l’objet d’un contrôle contradictoire par les deux parties, permettant de mesurer la valeur à rétrocéder.
Le prix de l’unité de référence est lui aussi soumis à des variations. Les contrats comprennent souvent des formules de variation de prix faisant référence à des indices publics sur lesquels les deux sont d’accord. A cela s’ajoutent des formules de pénalité ou de bonus destinées à inciter les prestataires à atteindre, voire dépasser les objectifs du projet.

« Le contrat est la loi des parties»

L’article 1103 du nouveau code civil français stipule que « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. » L’équipe projet est une communauté humaine comme une autre. Elle est obligée de se donner des règles, qui permettront de s’organiser, de définir le produit qu’elle doit réaliser et in fine de répartir équitablement la valeur du produit. C’est l’objet du contrat, et de l’ensemble des papiers qui l’accompagnent. Il est rédigé au préalable, mais comme le projet ne cesse d’évoluer en fonction des évènements et des nouvelles connaissances qu’il fait apparaître, le contrat aussi évolue, et la machine à produire du papier ne peut s’arrêter.

Bibliographie

Voir bibliographie de la chronique précédente.

Cet article a été publié dans système d'information. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s