Colloque Les contrats informatiques : les clés 15 octobre 2015 au Conseil National des Barreaux

Transcription

1 André MEILLASSOUX ATM Avocats Paris Président de l AFDIT Colloque Les contrats informatiques : les clés 15 octobre 2015 au Conseil National des Barreaux Le niveau d engagement des prestataires informatiques : la nécessité d avoir une vraie maîtrise d œuvre dans les opérations complexes André MEILLASSOUX, ATM Avocats Paris, Président de l AFDIT ameillassoux@atmavocats-associes.com Document confidentiel Ne pas diffuser sans autorisation 1

2 I. La question du niveau d engagement des prestataires IT et la pertinence du concept de «maîtrise d œuvre» On peut classer les contrats IT en deux catégories, ceux à «haut» niveau ou à «bas» niveau d engagement, Les contrats pour les projets lourds, à forts enjeux, doivent impérativement être à «haut niveau d engagement», de la part des prestataires. On les qualifie juridiquement de contrats «sous maîtrise d œuvre». Les opérationnels les qualifient, de manière inadéquate, mais répandue, de contrats «au forfait», car c est souvent le mode financier retenu. En réalité le concept à retenir est bien celui de «maîtrise d œuvre», objet de cette présentation. 2

3 II. La nécessaire qualification juridique du contrat IT La méthode juridique, civiliste, classique considère comme une étape déterminante celle de «qualification juridique» du contrat, qui permet ensuite, d en tirer toutes les conséquences juridiques. Cette étape est presque toujours omise pour les contrats de prestation IT, d où une source de flottement préjudiciable. Les contrats de prestations informatiques, sont des contrats de «louage d ouvrage» (ou contrat d entreprise) des articles 1787 et suivants du Code Civil, qu on peut décrire comme la «livraison d un objet non préexistant» (à la différence de la «vente» où l objet préexiste). La conséquence juridique immédiate en est, comme dans le bon vieux domaine du BTP, la nécessité d un «architecte» pour la «construction d un ouvrage» quel qu il soit, et pour les projets IT, Et la présence d un maître d oeuvre. Or cette notion est souvent omise, passée sous silence, sous divers prétextes, voire considérée comme un «gros mot», à ne pas utiliser. Pourtant c est un enjeu clé de la négociation. 3

4 III. Le contrat d intégration, «maître-contrat» informatique : Une caractéristique essentielle, à ne pas omettre, dans le contrat d intégration de systèmes : sa double dimension C est un contrat à double objet, car le prestataire fait 2 grandes catégories de tâches, avec deux positionnements juridiques bien distincts :. La réalisation d un certain nombre de tâches et de livrables (tel un «artisan»), mais surtout. La maîtrise d œuvre : (tel un «architecte»), fonction transverse, qui est exercée tout au long du contrat de la conception de l ouvrage, pour sa réalisation, jusqu à sa réception. Le contrat doit présenter, par conséquent, une double série de clauses pour tenir compte de ce double objet : double objet, et surtout double recette, distinguant les «recettes unitaires» pour les livrables, de la «recette d intégration» du système, essentielle. Le métier d intégrateur comprend naturellement ces deux dimensions. Mais à défaut de prendre en compte ce dédoublement des problématiques, dans la rédaction des contrats, on aboutit à des impasses. 4

5 IV les Contrats d intégration : quel schéma contractuel privilégier? Le contrat d intégration de progiciel est le «maître contrat». En effet, il est le plus complet, le plus stratégique et le plus complexe. Il soulève toutes les questions, qu il doit régler et les solutions sont transposables à tous les autres contrats informatiques. Sa structure est essentielle et souvent mal appréhendée, Il faut arbitrer au regard des trois schémas suivants: Le contrat de fourniture de SI clé en main Un schéma sans intégrateur Un schéma avec un intégrateur- maître d œuvre 5 5

6 IV les Contrats d intégration : quel schéma contractuel privilégier? Désignation d un responsable pour le tout, du type «entreprise générale» Maître d ouvrage ENTREPRISE GENERALE Sous traitants Editeur Hard-ware Services 6 6

7 4.1 Schéma contractuel : A - clé en main : Observations Idéal du client : une seule tête responsable de tout Un seul contrat uniquement avec «l entreprise générale» Dans la plupart des cas, ce schéma ne convient pas : on confond responsabilités juridiques et répartition des rôles nécessitée par la vie du projet Ce n est pas l esprit d un projet d intégration d ERP, qui nécessite une collaboration du client à sa réussite Un contrat «IV clé les en Contrats mains» d intégration revient à confier : toute la latitude à l entreprise générale : le quel projet schéma perd contractuel donc en privilégier visibilité et? on reporte souvent la validation à la fin du projet Dans la pratique, c est le client qui, de fait : Choisit l ERP (même si l intégrateur préconise) Souhaite ne pas payer un «mark-up» sur le prix de la licence Conclut le contrat et gère, dans le temps, la relation : en direct avec l éditeur Conclusion : à rejeter en principe 7 7

8 IV. 2 les Contrats d intégration : quel schéma contractuel privilégier? Le schéma B. Schéma B : Pas d intégrateur : descriptif Maître d ouvrage Services divers Editeurs Hardware 8 8

9 IV,2 les Contrats d intégration : quel schéma contractuel privilégier? Le schéma B bis. Schéma B : Pas d intégrateur : variante Maître d ouvrage Qualifié aussi de Maître d oeuvre La SSII L éditeur Les fournisseurs 9 9

10 IV.2 les Contrats d intégration : quel schéma contractuel privilégier? Le schéma B Schéma B et B bis: Pas d intégrateur : ce qui manque Ces deux schémas ne sont pas satisfaisant, car il manque : Un «architecte» ou «maître d œuvre» Qui ne soit : ni le client, ni les «artisans» Qui conçoive et contrôle le projet indépendamment des fournisseurs: De l éditeur de l ERP sous licence De services complémentaires ou de ressources De hardware 10 10

11 4,3 les Contrats d intégration : quel schéma contractuel privilégier? Le schéma C Schéma C: avec un intégrateur-maître d œuvre Le schema le mieux adapté : Maître d ouvrage Intégrateur Maître d oeuvre ERP Prestataires Hardware 11 11

12 V. les Contrats «Cloud» Le cas spécifique des contrats «cloud». Les mêmes problématiques demeurent pour les contrats de prestations dans le Cloud (en mode distant, locatif, à la demande ) Mais c est un schéma éclaté qu il faut réagréger dans la construction contractuelle La nécessité d un maître d oeuvre d autant plus grande Qui est il? (éditeur, intégrateur, opérateur télécom?) Quelle que soit sa spécialité, il devrait, de préférence, être: un prestataire proche géographiquement, pour pouvoir le challenger facilement, y compris en Justice (siège local ou clause attributive de juridiction) Aux reins un peu solides, donc bien capitalisé 12 12

13 Conclusion (1) : faire mieux pour les contrats IT complexes Le besoin des clients- maîtres d ouvrage, même doté d une équipe projet structurée, même bien conseillée par des Assistants à la Maîtrise d ouvrage (AMOA), est d avoir un vrai «pilote», qui est juridiquement responsabilisé. On constate une tendance forte du marché, surtout de la part d intégrateurs de grande taille, puissants sur leur marché, qui sont incontournables sur certains grands projets, à se mettre en retrait de leurs engagements juridiques. On constate aussi, et ceci est confirmé par certains de nos grands témoins, présents au colloque, un moindre investissement dans l effort de la phase «contractualisation», de la part des prestataires. Et cette position, n est pas toujours suffisamment perçue comme problématique par les clients, qui du coup, signent des contrats insuffisamment bordés. 13

14 Conclusion (2) : garder le concept central de maîtrise d oeuvre Pourtant, pour des projets lourds, complexes techniquement, et à enjeux de plus en plus grands pour les entreprises qui s équipent, il faudrait au contraire des outils contractuels adéquats, travaillés, voire sophistiqués, pour bien encadrer leur gestion et leur risque. Le concept de «maîtrise d œuvre» est une clé, élémentaire pour les juristes, car inhérente à la nature juridique du contrat. La maîtrise d œuvre est, en l état de la technique contractuelle, utile et rôdée, presqu incontournable. A partir de là, on peut discuter, voire s en écarter, mais on ne peut faire l économie d une vraie discussion, sur le vrai attendu de l intégrateur 14