André MEILLASSOUX ATM Avocats – Paris Président de l’AFDIT "Heurs et Malheurs de l’intégration des ERP" 8 mars 2016 au salon tunisien du TRAIN BLEU - Gare de Lyon Echanges croisés d’un DSI et d’un avocat spécialisé André MEILLASSOUX, ATM Avocats Paris, Président de l’AFDIT ameillassoux@atmavocats-associes.com

On peut classer les contrats IT en deux catégories, 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.

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 prestations 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.

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.

Le contrat d’intégration de progiciel est le « maître contrat ». 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”

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 Editeur Hard-ware Services Sous traitants

IV.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 « clé en mains » revient à confier toute la latitude à l’entreprise générale : le projet perd donc en 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

Schéma B : Pas d’intégrateur : descriptif 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

Schéma B : Pas d’intégrateur : variante 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

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 satisfaisants, 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

Schéma C: avec un “intégrateur-maître d’œuvre” IV.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 Prestataires Hardware ERP

Le cas spécifique des contrats « cloud » 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é

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, 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.

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