JDB_N1_2019_WEB72-compressé

21 # N1 201 9 JOURNAL DU BARREAU DE MARSE I L LE AVOCAT ET NUMÉRIQUE le développement. Cette dernière repose sur la gestion du projet « ScrumMaster » par cycle ité- ratif ou « sprints », les tâches du projet vont être traitées par « lot ». Ce qui signifie qu’à chaque fin de sprint, les fonctionnalités terminées sont pré- sentées au client pour validation ou modification lors de réunions « revues de Sprint » et ainsi de suite, jusqu’à atteindre l’objectif global. Attention, il faudra être vigilant sur le prix de chaque itéra- tion et bien déterminer la réception des « sprints », la résolution du contrat en cours de « Scrum Master » face à des SSII armées pourra égale- ment s’avérer compliquée sans un écrit rigoureux. La phase précontractuelle du contrat informatique La phase précontractuelle ne doit pas être né- gligée et devra permettre la réussite du contrat. Il existe une véritable obligation de conseil et de mise en garde à la charge du professionnel. L’in- sertion d’une clause indiquant que le client est un professionnel compétent dans le domaine in- formatique n’est pas suffisante. Le corollaire de cette obligation est bien évidemment le devoir de collaboration du client pendant les pourpar- lers et pendant le déploiement de la solution au sein de son entreprise. L’avocat est trop souvent écarté de la phase des négociations et des études technico-écono- miques, ce qui est dommageable pour le client et le prestataire informatique. La formation du Contrat Il sera abordé quelques clauses à appréhender au sein du contrat : - Article : Obligation de confidentialité Le prestataire informatique sera nécessairement amené à étudier les besoins du client en exami- nant son système informatique et donc être en possession d’éléments confidentiels. Quant au prestataire, il faut lui garantir la confidentialité sur son savoir-faire et ses méthodes. - Article : Circulation du contrat L’intuitu personae est fort, il faut donc veil- ler à interdire la cession du logiciel à un tiers, la sous-traitance doit également être encadrée avec un agrément formel du client. - Article : pluralité de parties, indivisibilité du contrat Il s’agit rarement de contrats uniques il faudra donc prévoir la divisibilité des contrats suivant les éléments objectifs (durée, la date de signature, l’économie de l’ensemble et la volonté des par- ties). Attention, aux ensembles « clé en main ». La solution à la pluralité d’intervenants pour- rait être d’avoir une vraie maîtrise d’œuvre tout comme un chantier dans le BTP, ce sera un véri- table pilote juridiquement responsabilisé. - Article : la détermination de l’objet Il doit être évidemment très précis, la description du logiciel à réaliser doit déterminer les carac- téristiques, les fonctionnalités, le résultat, les objectifs attendus, les moyens mis enœuvre, les délais prévus et les évolutions futures envisagées. Une clause de suivi peut être prévue instituant un comité de suivi ou de pilotage qui rédigerait des PV des réunions. Dans la méthode dite « agile », il n’y a pas de cahier de charge, mais un « backlog » qui liste les fonctionnalités et les résul- tats à atteindre, il faudra alors prévoir des « Re- vues de sprint » et des « cérémonies agiles », plus souples que le comité de pilotage et qui servira de référence à la garantie de conformité. - Article du prix Le prix peut être forfaitaire ou par régie ce qui implique, pour cette deuxième option, de prévoir comment le temps sera calculé et la rémunéra- tion des intervenants en fonction de leur qualifi- cation. Le prix devra couvrir pour partie la cession des droits de propriété intellectuelle. Pour la méthode « agile » un forfait peut être prévu par itérationmixé avec la régie, ce qui peut permettre au client de sortir en cas de désaccord. L’exécution du contrat Pas de nouveauté, la loi des parties c’est le contrat. La problématique sera de déterminer les causes de résolution du contrat. La mise en œuvre de l’article 1184 du Code civil doit impli- quer un caractère grave dans la mauvaise exé- cution pour justifier la résolution, idem pour le mécanisme de l’exception d’inexécution. En cas de méthode « agile », il sera essentiel de prévoir un engagement de collaboration et dé- finir quelles sont les obligations réciproques. L’obligation du prestataire n’est pas forcément une obligation de résultat, elle est variable. Afin de la fixer, il faut déterminer la part d’aléa dans l’objectif recherché. En méthode « agile » l’aléa est particulièrement présent, il devra clairement figurer dans le contrat et les conséquences de- vront être annoncées au client. La difficulté sera ici de prévoir la possibilité pour le client de continuer son projet. S’agissant de la méthode « agile », il faudra prévoir qu’à chaque itération la « brique » développée du logiciel soit remise. - L’objet de l’obligation et le Code source C’est une question hautement stratégique et il convient de préciser que la mise à disposition du code source est indépendante du transfert des éventuels droits de propriété intellectuelle. - La conformité Le prestataire se doit de réaliser le logiciel « livrable » conformément aux documents contractuels et le cahier des charges. Au mo- ment de la cession, il faut garder à l’esprit que le logiciel doit répondre aux besoins de client, mais également aux obligations légales prévues et prévisibles pour sa durée de vie. En présence d’un développement spécifique il faut se placer sur la garantie de conformité et non la garantie des vices cachés. Les droits de propriété intellectuelle En cas de silence du contrat, les droits d’exploi- tation restent en possession de celui qui a créé le logiciel, le client dispose d’un droit d’utilisation. Pour que les droits soient transmis, le contrat devra prévoir les mentions exigées par l’article L. 131-3 du Code de la propriété intellectuelle. Dans les droits cédés, il faut encore envisager que le logiciel contient des « briques » de logiciels appartenant à d’autres prestataires, une licence spécifique devra alors être prévue pour ces élé- ments. (Maintenance, évolution du logiciel…) La réception : Pratique contrac- tuelle de la clause de recette dans le contrat informatique La clause recette permet d’organiser la récep- tion d’un livrable du prestataire qu’il s’agisse d’un matériel ou d’un logiciel ou encore d’un docu- ment d’étude. Il existe différentes recettes sui- vant la complexité du projet, le périmètre de la recette devra être précisé. Savoir s’il s’agit d’une recette par module avant une recette d’inté- gration ou s’il s’agit d’une recette d’une solution totale. Dans le cadre de la méthodologie agile, il faudra adapter la clause de recette avec une grande flexibilité et en introduisant des recettes partielles correspondant à la fin d’une période d’itération.