Aspects Généraux de La Mutual

Aspects gnraux de la mutualisation informatique dans le secteur public
Etude ralise avec le soutien de la rgion wallonne : Commissariat EASI-WAL Direction gnrale des Pouvoirs locaux
Un rapport de : David De Roy (Chercheur CRID FUNDP) Aurlie Van der Perre (Chercheuse CRID FUNDP) Avec la collaboration de : Catherine Brocal (Assistante FUNDP) Alexandre Cruquenaire (Matre de confrence FUNDP) Robert Viseur (Assistant Management de lInnovation FPMs) Namur, le 15 dcembre 2007
Introduction gnrale
1. La mutualisation informatique : une double acception
1.Au sens o on lentend dans le cadre de ce rapport, la mutualisation informatique peut recevoir deux acceptions quil y a lieu de distinguer soigneusement : 1 il sagit de la mise en commun, par plusieurs administrations1, de moyens (humains, financiers ou matriels) en vue du dveloppement dun logiciel qui bnficiera lensemble des investisseurs (mutualisation en amont) ; 2 il sagit galement du partage de ressources informatiques dtenues par une ou plusieurs administrations qui choisissent den faire bnficier dautres utilisateurs, en ouvrant les droits dutilisation (mutualisation en aval). Chaque pratique de mutualisation empruntera lun ou lautre de ces modles, voire aux deux simultanment.
Etant entendu que ltude sinscrit dans le cadre du secteur public.
Mutualisation informatique dans le secteur public
2. La mutualisation informatique : divers objectifs

2.Parmi les objectifs assigns aux pratiques de mutualisation, quatre sont frquemment voqus2 : I. Les conomies dchelle
3.Utilise depuis longtemps dans le domaine de lachat public (tous secteurs confondus), lexpression conomie dchelle rfre lhypothse en laquelle plusieurs acheteurs sunissent pour effectuer une commande dont limportance du volume3 pourra leur permettre dobtenir, de la part du vendeur, une rduction du prix unitaire de chaque fourniture. Ces pratiques de groupement de commandes sont aujourdhui frquemment repres pour lachat dnergie, de fournitures classiques, de vhicules, 4.Lexpression nest cependant pas tout fait approprie lorsquil sagit dvoquer la mise en commun dinvestissements dans le dveloppement dun logiciel ; lenjeu nest alors pas de passer une commande pour le plus grand nombre de consommateurs 4, mais bien de faire en sorte quune prestation de dveloppement susceptible de bnficier un grand nombre dentre eux soit rtribue au juste cot du dveloppement5, et non en le multipliant par le nombre dacqureurs : en termes plus simples, ne pas faire payer plusieurs fois le mme travail 5.Cet objectif dordre financier peut se traduire dans le partage, entre les pouvoirs adjudicateurs concerns, des frais inhrents au dveloppement du logiciel (mutualisation en amont) ou dans lamortissement progressif des frais exposs pour ce dveloppement, par loctroi subsquent de licences dautres utilisateurs, moyennant rtribution (mutualisation en aval). II. La recherche dindpendance lgard des prestataires de services 6.Lallgement des charges dinvestissement et la valorisation financire de logiciels permettent dconomiser des ressources qui, le cas chant, seront affectes des initiatives permettant de mnager une plus grande indpendance lgard des prestataires de services. Tel sera le cas, lorsque ces ressources serviront lengagement et la formation de personnel spcialement ddi laccompagnement des administrations concernes. Ainsi, en sera-t-il
2
Cet aperu ne prtend nullement lexhaustivit : lobjectif de gestion du risque identifi par Franois Elie na pas t retenu dans le cadre de la prsente, ds lors quau travers des expriences analyses, il nest pas identifi de faon singulire, mais est prsent comme ressortissant dautres objectifs, telle lindpendance lgard des prestataires de services (Fr. ELIE, Splendeurs et misres de la mutualisation , Services publics et mutualisation informatique : de la thorie la pratique. Compte rendu de la journe organise par le Parlement de la Communaut franaise le 23 mars 2006, Bruxelles, 2006, pp. 99-100). 3 Provoque par le cumul des commandes individuelles. 4 La particularit tant, pour rappel, quil est fait pour le partage (Fr. Elie, op.cit., p.9), ce qui exclut de facto le modle associ lexpression conomie dchelle . 5 Ce qui nexclut, du reste pas, que ce cot soit calcul par le prestataire en fonction de diffrents facteurs, tel le degr de probabilit de commercialiser plus ou moins grande chelle le dveloppement quil assure pour un client.
4 galement des situations o des agents de ces mmes administrations dveloppent un travail communautaire de dveloppement, inspir des mthodes ayant cours dans le monde de lOpen source. III. La mise en commun de bonnes pratiques 7.La mutualisation en amont, par le partage des investissements dans un projet unique, suppose que les partenaires publics se soient clairement entendus sur un socle commun de besoins fonctionnels. Cette exigence pralable peut offrir loccasion de rflexions substantielles sur les pratiques au soutien desquelles un logiciel est appel servir, particulirement pour les applications mtiers . Cette mutualisation des pratiques peut, dailleurs, se traduire dans llaboration de produits spcifiques, utiles et utilisables indpendamment de loutil informatique, tels les processus modaliss. 8.Par ailleurs, la mise en commun permettra galement aux diffrents partenaires dchanger propos de (et damliorer) leurs pratiques de passation des marchs publics, l o chacun dentre eux ne matrise pas ncessairement tous les aspects, souvent complexes, de ces procdures6. IV. La prennit et linteroprabilit des outils dvelopps 9.Par les regards quils incitent porter sur les pratiques dautres acteurs, avec les systmes desquels il y a lieu dassurer une articulation efficace, la mise en commun des investissements et le dveloppement concert permettent de privilgier lusage doutils informatiques (tels les standards ouverts) servant utilement les idaux de prennit et dinteroprabilit auxquels est associe limage dune administration en rseau.
Tant pour les aspects lis la lgalit des procdures, que pour ceux qui permettent une gestion efficace de la commande publique.
3. La mutualisation informatique : aspects mthodologiques et juridiques

10.Ds lors quelle dsigne un ensemble de pratiques, la mutualisation informatique rfre ncessairement aux mthodes mises en uvre et au cadre juridique dans lequel sinscrivent ces pratiques ; sans grande surprise, cest donc au travers de ses aspects mthodologiques et juridiques quelle gagne tre examine. 11.La mthodologie de la mutualisation informatique sinspire notamment de recommandations techniques familires aux dveloppeurs, et dont certaines affichent une proximit vidente avec les mthodes de travail prouves dans le monde de lOpen source ; elle est galement commande par des considrations tenant la bonne gestion de projets dans lesquels interviennent des entits publiques, et utiles bien dautres domaines que celui de linformatique administrative (dfinition des besoins, des contraintes daction, du calendrier, affectation des ressources humaines, ). Il tait donc normal davoir gard ces deux sources dinspiration dans le cadre de ce rapport. 12.Le cadre juridique de la mutualisation est assez htrogne et, partant, complexe : il est constitu de nombreuses lgislations auxquelles les entits publiques doivent conformer leur action. Certaines de ces lgislations peuvent varier sensiblement suivant les administrations concernes : tel sera, notamment, le cas des normes rgissant la gestion budgtaire et comptable, le contrle administratif et budgtaire, les modes de coopration avec dautres entits, les contrles de tutelle, Pour cette raison, il savre illusoire de prtendre en rendre compte de faon systmatique. Les aspects juridiques traits dans le cadre du prsent rapport sont ceux qui peuvent donner lieu une approche commune toutes les administrations impliques dans un projet de mutualisation ; il sagit essentiellement des questions relatives au droit commun des contrats informatiques (en ce compris certains aspects du droit de la proprit intellectuelle) et la lgislation relative aux marchs publics. 13.En dpit de ce que parat sduisante une distinction claire entre aspects mthodologiques et juridiques, lintimit en laquelle les uns et les autres coexistent dans le cadre des pratiques de mutualisation7 incitent renoncer une prsentation binaire , pour lui prfrer un listage des diffrentes questions (qui tant en leurs aspects techniques, mthodologiques, institutionnels et juridiques se posent au praticien mesure quil envisage le scnario de son exprience).
Certains aspects juridiques ntant, par exemple, que la traduction de mthodes recommandes.
4. La mutualisation informatique : plusieurs modles

14.Notion applicable un trs large ventail de pratiques, ncessairement diffrentes les unes des autres, la mutualisation informatique ne peut se prter une tude gnrale qu la faveur dune approche par des modles correspondant des hypothses pralablement dfinies et de chacune desquelles peut tre rapproche toute exprience. Cest autour de lanalyse de quelques-unes de ces hypothses quest ordonnanc ce rapport. 15.Nous avons opt pour une prsentation en deux parties, selon que le logiciel doit tre dvelopp (1re partie) ou existe dj et peut tre ouvert dautres utilisateurs que ceux linitiative desquels il a t dvelopp (2me partie). La premire partie se dcline elle-mme en quatre hypothses auxquelles correspondent des enjeux tantt spcifiques, tantt communs plusieurs dentre elles, ainsi quen tmoigne le tableau propos ci-dessous :
1. Dveloppement, en interne, par une administration seule

Comment anticiper louverture ventuelle du logiciel dvelopper ?
2. Dveloppement par une communaut de dveloppeurs-utilisateurs, informaticiens des administrations concernes

Dveloppement du logiciel en communaut Comment anticiper louverture ventuelle du logiciel dvelopper ?
3. Dveloppement par un prestataire de services la demande dune administration seule

Comment anticiper louverture ventuelle du logiciel dvelopper ?
4. Dveloppement par un prestataire de services la demande de plusieurs administrations partageant linvestissement

Dveloppement du logiciel en communaut Comment anticiper louverture ventuelle du logiciel dvelopper ?
16.Cette manire dapprhender quelques-unes des principales hypothses de mutualisation informatique tranche quelque peu avec la distinction amont/aval, pourtant suggestive des deux principales approches conceptuelles de la mutualisation informatique8 ; elle permet cependant de couvrir un ensemble plus large de situations, dont certaines sans relever dune pratique de mutualisation en amont ou en aval incitent toutefois soulever quelques-unes des questions propres la mutualisation informatique dans le secteur public. Tel est le cas des hypothses ci-dessus rfrences 1 et 3, pour lesquelles, avant le dveloppement du logiciel, il ny a ni mutualisation en amont9, ni mutualisation en aval10, ce qui nempche que ladministration puisse tre amene anticiper louverture ventuelle du logiciel dautres utilisateurs et quelle doive donc sinscrire ds ce moment dans une perspective de mutualisation.
8 9
Cf. supra, n . Puisque ladministration concerne est seule. 10 Laquelle suppose que le logiciel existe dj (2me partie du rapport).
17.On prcisera, pour autant que cela soit ncessaire, que le caractre invitablement abstrait dune catgorisation ne peut faire perdre de vue que certaines situations relveront de plusieurs des hypothses nonces ci-dessus.
5. La mutualisation informatique : aspects gnraux

18.La trs grande diversit des situations, laquelle il a t fait allusion prcdemment, et la ncessit de contenir les rsultats de la recherche dans des limites raisonnables, qui ne compromettent pas la lisibilit du rapport et en favorisent, autant que possible, lutilit pratique, contraignent noncer des enseignements gnraux ; loin de se dcliner la manire dun vade mecum ou dun livre de recettes, ces enseignements apparatront davantage comme traant le fil conducteur des questions auxquelles les initiateurs de tout projet de mutualisation doivent ncessairement prter attention. Il sagit avant tout de poser des repres, synonymes tantt de gages de russite, tantt dobstacles apprhender en connaissance de cause. 19.Enfin, lallure apparemment thorique de ce rapport ne doit pas faire perdre de vue quil rsulte dun travail de recherche ancr, pour une part importante, dans lanalyse dexpriences rcentes ou en cours ; de nombreux exemples ponctuant le rapport en tmoignent, ainsi quune importante annexe proposant la description des expriences analyses. Les rfrences que contient le rapport final ces expriences ainsi dcrites attesteront du souci constant dadhrer la pratique qui a anim les auteurs de ce rapport.
Avertissement Le souci de favoriser une lecture commode du prsent rapport conduit formuler les suggestions suivantes : De nombreuses questions abordes dans le rapport sont inspires par les enseignements quont livrs les tudes de cas ; des rfrences (souvent localises dans les notes infrapaginales) lAnnexe permettront au lecteur dapprhender la question aborde la lumire dune exprience de mutualisation. De la mme manire, des renvois des cas pratiques vers la partie thorique de ce rapport ont t intgrs dans lAnnexe (en notes infrapaginales). Lexamen des quatre situations en lesquelles la solution logicielle nexiste pas et doit tre dveloppe a amen aborder certains aspects de faon rcurrente ; il sagit ainsi de permettre au lecteur qui souhaite examiner plus particulirement lune de ces quatre hypothse de prendre connaissance systmatiquement (et sans devoir parcourir lintgralit du rapport) de toutes les questions auxquelles il doit se montrer attentif. Pour limiter le risque de redondances qui alourdiraient dmesurment le rapport, des rfrences (souvent localises en notes infrapaginales) dirigent le lecteur vers les parties qui lui offriront des informations complmentaires. La lecture du rapport ne dispense pas le lecteur dutiliser dautres sources dinformations qui complteront son information sur certains des domaines visits. Sagissant plus particulirement des principaux domaines juridiques relatifs la mutualisation (marchs publics, contrats informatiques et proprit intellectuelle), ceux-ci nont t approchs quen leurs seuls aspects qui ont directement trait la mutualisation. On rappellera enfin que si ce rapport permet didentifier les repres indispensables la conduite de toute pratique de mutualisation et offre les lments thoriques utiles lanalyse des problmes rencontrs, il ne permet cependant pas de rencontrer, sans autre tude ou analyse complmentaire, chaque situation concrte, ncessairement contingente.
10
La solution doit tre dveloppe - Dveloppement avec perspective d'ouverture ultrieure

Introduction
20.En dpit des spcificits dont rendra compte lanalyse de chacune delles, les quatre hypothses en lesquelles le processus de mutualisation est envisag alors que la solution informatique nexiste pas encore, rvlent un tronc commun de proccupations ou dexigences dont permettront de rendre compte les trois observations qui suivent. I. Prospection de lexistant 21.Au risque de verser dans des lieux communs, on observera, avant tout, que le dveloppement dun logiciel rpond un besoin quprouve une administration pour la dmatrialisation de procdures dans lesquelles elle intervient, pour loffre de services publics forte connotation informatique ou encore pour la gestion de son fonctionnement. Le choix du mode de dveloppement sera prcd dune estimation pralable des moyens dont dispose ladministration : son personnel a-t-il la comptence et les disponibilits pour assurer pareille tche et, dans laffirmative, peut-il y tre affect dans des conditions compatibles avec les dlais dans lesquels le logiciel doit tre rendu disponible ? Selon les rponses apportes ces questions, le dveloppement sera assur en interne ou par les services dun tiers. Susceptibles dtre poses en bien des domaines11, ces questions revtent un intrt particulier dans le contexte de la mutualisation informatique. Les objectifs assigns celle-ci doivent inciter toute administration qui envisage le dveloppement dun logiciel prospecter, hors de sa sphre institutionnelle, les ressources disponibles auprs dautres entits, et susceptibles dapporter une rponse (plus ou moins) satisfaisante ses besoins. 22.Les avantages que lon reconnat une telle prospection pralable de lexistant sont multiples. A titre dexemple, elle permet : de reprer une solution qui existerait dj et dont pourrait bnficier ladministration, moyennant quelques adaptations mineures ; cette situation la dirigerait immdiatement vers le cas de figure tudi dans la seconde partie de ce rapport ; au contraire, de constater quaucun outil similaire celui qui devrait tre dvelopp nexiste, auquel cas lintrt danticiper une initiative de mutualisation en aval se laissera percevoir ; didentifier des outils complmentaires avec lesquels une articulation efficace gagnera tre envisage ;
11
Puisquelles conditionnent toute perspective de lancement de march public.
11 dobserver les mthodes et langages de dveloppement frquemment utiliss et susceptibles de prsenter les niveaux de qualit requis dans la conduite des projets de mutualisation.
23.Cette prospection de lexistant suppose que celui-ci puisse tre identifi, localis et suffisamment caractris. Deux filires dexploration peuvent a priori tre identifies : les communauts et projets de lOpen source12 et les administrations. Sagissant de ces dernires, laccs linformation pertinente quelles pourraient dtenir souffre du curieux paradoxe quentretient lessor de la socit de linformation : si lInternet garantit la rapidit et le confort daccs linformation, celle-ci se trouve disperse la mesure du nombre et de la diversit dacteurs et de projets, ce qui compromet sa localisation. Il est donc recommand que les acteurs qui, divers niveaux, jouent un rle essentiel dans la promotion de leGovernment prennent (ou encouragent) des initiatives qui permettront de centraliser les diffrents accs linformation utile. Par ailleurs, une fois localise, cette information ne sera pleinement utile que si elle affiche un niveau suffisant de qualit ; des mthodes de dveloppement de logiciels sont labores et permettent de donner de ceux-ci une description homogne.
Une illustration intressante est offerte par la grille dautodescription dveloppe dans le cadre du projet GPOSS port par lIDABC. Elle contient, propos de chaque logiciel inventori par lOpen source Observatory les informations suivantes : catgorie nom du projet description courte site Internet du projet version audience cible (type d'utilisateur et type d'administration) langage de programmation dpendances techniques licence logicielle description complte (historique, caractristiques et informations utiles pour un premier usage) types de documentation disponible types de support disponibles langues couvertes (ainsi que les possibilits d'extension) taille de la communaut (en terme de dveloppeurs et d'utilisateurs) rfrences (clients) statut du dveloppement coordonnes de la personne de contact
II. Importance des tudes pralables 24.Si la ncessit de faire prcder le dveloppement de logiciels dtudes suffisantes relve, une fois encore, des exigences dune bonne gestion de laction des pouvoirs publics, elle revt une importance particulire dans le contexte de la mutualisation informatique. Selon les circonstances et les modles de mutualisation, ces tudes pourront porter sur trois objets diffrents.
12
A proximit desquels gravitent, dans un certain nombre de cas, des projets de mutualisation informatique.
12
A. Etude des profils des utilisateurs et de leurs besoins fonctionnels 25.Ltude des besoins fonctionnels, qui prcde ncessairement tout dveloppement de logiciel13, offre galement loccasion dune rflexion utile sur les pratiques la dmatrialisation vers laquelle tend le logiciel. Une mutualisation de bonnes pratiques entre administrations peut ainsi tre initie ; le projet Qualicit sinscrit dans cette perspective14. 26.Lorsque le dveloppement du logiciel sinscrit dans un contexte de mutualisation en amont, impliquant donc plusieurs administrations ds lorigine du projet, ltude des besoins fonctionnels sera utilement assortie dune description des profils des administrations concernes ; elle permettra, par une analyse comparative de leurs mtiers , dvaluer la proximit de leurs besoins respectifs ; elle tiendra galement compte des tailles respectives des administrations concernes. Ces deux dimensions ont t largement prises en compte dans le cadre du projet Tabellio15. B. Etude de pr-requis techniques, mthodologiques ou juridiques louverture ultrieure des droits dutilisation du logiciel 27.La perspective douverture ultrieure des droits dutilisation du logiciel dvelopper incite prter attention certains aspects, tels le langage de programmation, la mthode de dveloppement, les conditions dutilisation et de diffusion de certaines composantes, Utile dans chacune des quatre hypothses examines en cette premire partie, pareille tude fera lobjet de dveloppements particulier dans la suite du rapport. C. Etude des forme juridique et modle conomique du processus de mutualisation 28.Dans certains cas, limportance du processus de mutualisation envisag (importance dduite des enjeux financiers, du nombre de logiciels dont le dveloppement est prvu, de la dure du processus ou du nombre et de la diversit des entits publiques concernes) incitera recommander la conduite dtudes relatives au cadre juridique de ce processus ou au modle conomique qui guide la mutualisation. Pareilles tudes peuvent tre imposes par les difficults dordres juridique, oprationnel ou institutionnel que fait natre la perspective de partenariat ; le projet e-Catalogue en fournit une intressante illustration16. 29.Si de telles tudes risquent, de toute vidence, de freiner le dveloppement informatique proprement dit, elles nen apparaissent pas moins invitables. Les diverses charges quelles peuvent gnrer reprsenteront cependant un investissement utile, particulirement l o le processus peut connatre un rayonnement important (dans le temps ou dans la population dadministrations concernes).
13
Ds lors que le dveloppement a prcisment pour objet doffrir la solution technique un besoin fonctionnel dtermin. 14 Cf. annexe, n I. 15 Cf. annexe, n IV. 16 Cf. annexe, n V.
13
III. Degr de la contrainte danticipation en fonction du degr de volont douverture 30.Dans chacune des quatre hypothses examines en cette premire partie, il est recommand dtre attentif certains aspects qui, ds avant le dveloppement du logiciel, peuvent conditionner louverture ultrieure des droits dutilisation et, plus largement, un processus de mutualisation en aval : lenjeu est ici celui de lanticipation de louverture ventuelle du logiciel. 31.Limportance des contraintes que fait peser cette anticipation sur les initiateurs du dveloppement variera selon le degr de probabilit douverture ultrieure. Si celle-ci nest pas encore vritablement esquisse la veille du dveloppement, l(es) initiateur(s) veillera(ont) uniquement prvenir les risques inhrents certains facteurs bloquants (code illisible et insuffisamment document, absence damnagement des droits de proprit intellectuelle, utilisation de composantes dont le mode de diffusion se rvle incompatible avec les objectifs financiers de la mutualisation en aval, )17. En revanche, si la mutualisation en aval correspond un objectif prcis (tenant, par exemple, lamortissement de linvestissement financier de dpart), il sagira daborder galement dautres questions sans lesquelles louverture ultrieure des droits dutilisation risque de se rvler illusoire. Ainsi, conviendra-t-il, par exemple et selon les cas, de dfinir les modalits de choix de nouveaux utilisateurs, lordre de grandeur de la communaut, les conditions gnrales daccs, Laperu des quatre hypothses rendra compte, au regard des considrations qui prcdent, de ce caractre variable de la contrainte danticipation.
17
Ces exemples sont videmment dtaills et exploits dans la suite du rapport.
14
1. Dveloppement, en interne, par une administration "seule"
Enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper?

I. Identification des perspectives douverture ultrieure dautres utilisateurs A. Besoins similaires ou complmentaires dautres administrations 32.Ladministration dveloppe en interne un logiciel en fonction de ses besoins propres en informatique. Cela nempche quune rflexion pralable sur les besoins dautres entits publiques puisse tre mene dans une optique de mutualisation ultrieure (en aval). Ladministration est attentive : aux besoins similaires dautres entits affichant un profil assez proche du sien ;
Une commune qui sapprte dvelopper un logiciel de gestion des cimetires communaux peut assez facilement vrifier si un tel outil est susceptible de rpondre aux besoins dautres communes.
aux besoins complmentaires dentits avec lesquelles elle peut tre appele collaborer.
Une rgion dveloppe un logiciel permettant de dmatrialiser la procdure doctroi des permis durbanisme dans laquelle elle intervient, tandis que les communes jouent galement un rle. En dpit de ce que ces entits interviennent des stades diffrents de la procdure, justifiant que leurs outils informatiques respectifs rpondent des fonctionnalits distinctes, elles gagneront se concerter, sinon pour dvelopper un outil commun, tout le moins pour sassurer de la compatibilit de leurs solutions respectives, de manire, par exemple, faciliter la communication et le traitement des documents entre elles.
33.Envisager une telle analyse nest certes pas un pr-requis indispensable pour la ralisation du programme mais peut savrer intressant si ladministration peroit une possibilit douverture des droits dutilisation ou dtecte une opportunit darticulation entre le logiciel quelle sapprte dvelopper et dautres instruments existants (ou dvelopper). On peut dailleurs imaginer que ces perspectives incitent ladministration concerne amorcer rapidement un partenariat avec dautres entits publiques et bifurquer vers un modle de mutualisation en amont, ce qui amnerait alors tudier sa situation au regard des hypothses 2/ et 4/ examines dans la suite du rapport. Les contraintes danticipation dpendent, en effet, dans une large mesure, du degr de volont (ou de probabilit) douverture au dbut de lopration.
15 B. Prcautions 34.Bien que lobjectif premier de ladministration soit le dveloppement de lapplication informatique pour son utilisation propre, certaines prcautions peuvent tre prises afin de favoriser (ou, tout le moins, de ne pas empcher) louverture ventuelle des droits portant sur le logiciel. Ainsi, lentit sassure de la titularit des droits patrimoniaux de la proprit intellectuelle sur le dveloppement, ce qui lui garantit la possibilit dune ouverture du logiciel. 35.Elle veille galement se mnager laccs au code source et une documentation approprie de celui-ci. Cette prcaution revt une importance particulire pour assurer lexploitation du logiciel (maintenance, formation, adaptation). La clart des langages utiliss et la lisibilit du code sont encore des facteurs cls de russite dun processus de mutualisation, tandis que des lacunes cet gard constitueront probablement un obstacle. 36.Enfin, si ladministration poursuit un objectif prcis de mutualisation en aval, elle veillera disposer des ressources humaines ncessaires louverture et envisagera la manire dont les tches pourraient ventuellement tre assures par de futurs utilisateurs. II. Ressources humaines ncessaires pour assurer le dveloppement et louverture du logiciel A. Ressources pour le dveloppement et le suivi 37.De manire gnrale et en dehors de tout processus de mutualisation, ladministration qui souhaite dvelopper en interne une application informatique ne pourra lenvisager que si elle dispose des ressources humaines requises et si celles-ci sont en mesure de mener bonne fin les oprations dans les dlais requis pour la satisfaction des besoins qui justifient le dveloppement.
Ainsi, une commune, ne disposant en interne que dun agent informaticien engag temps rduit, nest pas en mesure dassurer par elle-mme la programmation ; elle sera donc amene faire appel au secteur priv pour le dveloppement du logiciel.
38.Ladministration sassure encore de disposer des ressources humaines suffisantes pour le suivi du logiciel (en ce compris limplmentation, les maintenances corrective et volutive et laccompagnement), sauf recourir un prestataire extrieur. B. Ressources pour louverture 39.Ladministration est consciente de ce que plus les utilisateurs sont nombreux, plus les tches de gestion, de maintenance, dadaptation ou encore de formation sont lourdes. Si lobjectif long terme est de mutualiser lapplication dveloppe en interne, ladministration anticipe la manire dont ces charges seront assures, soit par elle-mme, soit par les entits partenaires, soit par des prestataires extrieurs.
16
III. Cession des droits ladministration
patrimoniaux18
sur
le
logiciel
au
profit
de
40.Il est indispensable que ladministration dispose de droits tendus sur le logiciel si elle envisage une ouverture ultrieure. Plus elle jouit de droits sur lapplication informatique, plus elle peut lexploiter sa guise et vitera, par ailleurs, les risques inhrents une situation de dpendance dans laquelle elle pourrait se trouver, lgard tant de ses agents informaticiens (A) que des prestataires de services qui assisteraient ceux-ci dans leurs tches (B). A. Logiciel entirement dvelopp par les agents de ladministration 41.Les droits patrimoniaux19 de la proprit intellectuelle sont prsums tre cds des auteurs ladministration. Dans cette hypothse, les auteurs du programme, titulaires originaires des droits de la proprit intellectuelle sur le logiciel, sont les agents (statutaires ou contractuels) de ladministration. Larticle 3 de la loi du 30 juin 199420 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur dispose que : Sauf disposition contractuelle ou statutaire contraire, seul l'employeur est prsum cessionnaire des droits patrimoniaux relatifs aux programmes d'ordinateur crs par un ou plusieurs employs ou agents dans l'exercice de leurs fonctions ou d'aprs les instructions de leur employeur . En dautres termes, la disposition tablit une prsomption de cession des droits patrimoniaux au profit de lemployeur, cest--dire dans notre hypothse ladministration qui devient titulaire driv des droits. Lentit publique est ds lors habilite exploiter le logiciel sa guise, ce qui lui permettra notamment de dsigner librement les futurs utilisateurs et dapporter au logiciel toutes les modifications que pourrait requrir son exploitation21.
18
Ces droits comportent la reproduction permanente ou provisoire, la distribution sous toute forme au public, ladaptation, larrangement, la location et le prt du logiciel (art. 5 L. 30 juin 1994 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur, M.B., 27 juill. 1994). 19 Prcisons que le droit moral de lauteur est inalinable. Larticle 6bis de la Convention de Berne pour la protection des uvres littraires et artistiques du 9 septembre 1886 (modifie diverses reprises), auquel renvoie la loi transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes dordinateur, limite les droits moraux en matire de logiciel : lauteur conserve le droit de revendiquer la paternit de luvre et de sopposer toute dformation, mutilation ou autre atteinte la mme uvre, prjudiciable son honneur ou sa rputation. 20 L. 30 juin 1994 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur. 21 En outre, lon peut dduire que le logiciel, dvelopp avec une ou plusieurs composantes libres, ne pourra tre diffus sous une licence Open source par les informaticiens dveloppeurs de ladministration quavec laccord de celle-ci.
17
B. Logiciel dvelopp par les agents contractuels ou statutaires de ladministration avec laide dun prestataire extrieur 1)La lgislation relative aux marchs publics est applicable : 42.Si ladministration ne dispose pas des ressources humaines ncessaires en interne, il est possible quelle fasse appel au secteur priv pour bnficier dune aide technique, mme ponctuelle, pour le dveloppement de lapplication informatique22. Un contrat de prestation de services, et plus particulirement de louage douvrage, est conclu entre lentit publique et le prestataire selon les rgles de la lgislation relative aux marchs publics23. Nous reviendrons ultrieurement sur certains aspects juridiques des marchs publics24. 2)Le transfert des droits patrimoniaux au pouvoir adjudicateur doit tre prvu par le cahier spcial des charges ou rgi par une licence Open source25 : 43.Contrairement la cession des droits patrimoniaux de lagent au profit de ladministration lorsque le logiciel est dvelopp en interne, aucune prsomption nexiste pour les lments de lapplication raliss par un prestataire extrieur, et ce, mme si la plupart des fonctionnalits sont programmes en interne. Le transfert des droits patrimoniaux au profit du pouvoir adjudicateur doit tre organis par le cahier spcial des charges. Pour sassurer une jouissance paisible des droits patrimoniaux qui lui sont contractuellement transfrs, ladministration insre des clauses particulires dans le cahier spcial des charges (par exemple une clause de garantie dviction ou une clause tablissant le droit exclusif pour le pouvoir adjudicateur de dcider de lutilisation des rsultats). Les dispositions insrer dans le cahier spcial des charges feront lobjet dune analyse plus approfondie en aval de ce rapport26. 44.Il est possible que le prestataire de services propose la diffusion de son apport suivant les conditions et modalits dune licence Open source, ce qui confre ladministration des droits tendus sur cet apport. Elle sera nanmoins attentive aux effets que peut produire lintroduction dlments libres dans un ensemble de composantes, particulirement pour les modalits de diffusion de cet ensemble. Il se peut quelle soit tenue de diffuser celui-ci en Open source, alors que telle ntait pas ncessairement son intention27. Par contre, ladministration sera, si elle le souhaite, apte diffuser le logiciel en mode Open source, puisque de tels lments sont libres de droits (sauf si lon se trouve face une licence hybride).
22
Notons que ladministration peut galement faire appel un prestataire de services des fins autres que le dveloppement du logiciel. Nous pensons entre autre aux prestations annexes, telles la maintenance sur le logiciel ou la certification de la qualit du code source (Cf. infra, n IV et III-III). 23 L. du 24 dc. 1993 relative aux marchs publics et certaines catgories de travaux, de fourniture et de services, M.B., 22 janv. 1994 et L. 15 juin 2006 relative aux marchs publics et certaines catgories de travaux, de fourniture et de services, M.B., 15 fvr. 2007. 24 Cf. infra, n II et suiv.. 25 Notons, pour tre tout fait prcis, que la licence Open source nopre pas vritablement un transfert des droits patrimoniaux de la proprit intellectuelle mais plutt un partage de ceux-ci. 26 Cf. infra, n III et suiv.. 27 Cf. infra, n IV.
18
IV. Code source A. Accs au code source 45.Il est indispensable pour louverture du logiciel et pour son exploitation que ladministration jouisse de laccs au code source. Disposer du code est essentiel pour les modifications, adaptations ou corrections ultrieures du logiciel et ce, notamment en cas de dpart dun ou de plusieurs agent(s) contractuel(s) ou statutaire(s) de ladministration ayant particip au dveloppement de lapplication informatique. Il en va de lindpendance de ladministration lgard de ses agents informaticiens (et, dans la mesure o il y est fait appel, du prestataire de services tiers).
Ladministration octroie une licence dutilisation dautres entits publiques auxquelles elle communique le code source uniquement des fins de maintenance. Ces entits pourront donc assurer la maintenance (par leurs agents ou en recourant des prestataires tiers) sans tre dpendantes des agents et/ou prestataires qui avaient dvelopp le logiciel lorigine. Si ladministration ne dispose plus de ressources internes suffisantes, pour lexploitation du logiciel que ses propres agents avaient dvelopp, elle peut faire appel un prestataire extrieur qui assurera les services sollicits et, le cas chant, adaptera le code aux besoins de nouvelles administrations utilisatrices, si cela savre ncessaire. Le risque de dpendance dune administration lgard de ses agents informaticiens est ainsi limit. Ladministration peut opter pour la diffusion de lapplication informatique sous licence libre. Dans ce cas de figure, lobjectif de ladministration est logiquement que le programme puisse tre utilis par une grande communaut dutilisateurs. Afin de leur garantir une certaine indpendance, notamment au niveau de la maintenance, la comprhension du code doit tre irrprochable.
46.Comme il la t expos prcdemment28, ladministration est prsume cessionnaire des droits patrimoniaux de ses agents informaticiens sur le logiciel, ou le devient en vertu du cahier spcial des charges ou dune licence Open source. Ds lors, elle bnficie de laccs au code source dont elle est titulaire et dont elle gre lexploitation sa guise. La reconnaissance du droit daccs au code source ne suffit cependant pas garantir un accs effectif et atteindre ainsi lobjectif dindpendance. B. Lisibilit du code 47.Il ne suffit pas que ladministration ait accs au code source, encore faut-il que celui-ci soit lisible si elle veut se garantir une indpendance face ses agents dveloppeurs et si lapplication informatique a vocation tre mutualise.
28
Cf. supra, n III et suiv..
19 1)Il est indispensable de disposer dun code lisible : 48.Au titre des qualits quaffichera le code pour tre considr comme lisible, on retient gnralement quil doit tre structur, facilement comprhensible, dcoup en modules ; il doit respecter les conventions de codage et avoir fait lobjet de plusieurs tests pralables. 2)Il est important de disposer de la documentation adquate : 49.Afin dviter les risques lis une mauvaise lisibilit du code, ladministration sassure de disposer de toute la documentation ncessaire la comprhension des algorithmes et lexploitation du logiciel : copie du code, rgles de codage, choix de larchitecture, manuel dutilisation, guide dinstallation. 3)Il est recommand de procder la certification du code source : 50.Comme il la t dvelopp prcdemment, la lisibilit du code doit tre excellente. Celuici doit ds lors tre test afin de dtecter dventuelles erreurs de conception ou de programmation. Le recours un prestataire extrieur de certification peut tre relevant cet gard. Si le contrat pass avec le prestataire de services peut tre qualifi de march public, la lgislation affrente sera dapplication29. Il faut cependant garder lesprit que la vrification des codes sources est une opration dlicate. En particulier, le test d'un nouveau dveloppement doit idalement s'effectuer au sein mme de l'environnement de travail prexistant ; or, cette possibilit existe rarement. En outre, les cots lis ces oprations de vrifications sont importants, de mme que le temps que cela ncessite.
C. Utilisation dlments Open source : prcautions

51.Lors de la programmation dun logiciel adapt aux besoins de ladministration, les informaticiens peuvent utiliser certains lments dits libres30 ou Open source31 . Notons que nous utiliserons indistinctement ces deux termes dans le cadre du rapport.
29 30
Cf. infra, n II et suiv.. Un logiciel est considr comme libre par la Free Software Fundation lorsque quatre liberts fondamentales sont respectes: la libert dutiliser le programme, pour tous les usages la libert dtudier le fonctionnement du programme et de ladapter aux besoins, ce qui ncessite laccs au code source la libert de redistribuer des copies la libert damliorer le programme et de publier les amliorations pour en faire profiter toute la communaut, ce qui ncessite laccs au code source. 31 LOpen Source Initiative considre quun logiciel dit Open source doit rpondre dix critres : redistribution du programme libre et gratuit livraison du code source avec le programme distribution des travaux drivs dans les mmes termes que la licence du logiciel dorigine prservation de lintgrit du code source de lauteur absence de discrimination envers des personnes ou des groupes absence de discrimination envers des domaines dactivit pas besoin de se conformer des termes de licence complmentaires pas de licence spcifique un produit pas de licence imposant des restrictions sur dautres logiciels neutralit technologique .
20 52.Le recours des lments prexistants Open source peut susciter certaines difficults, tant dans la conception que pour la diffusion de lapplication informatique. 53.Ainsi, certains lments sont distribus sous des licences libres qui peuvent tre incompatibles entre elles. Ce cas de figure ncessite un minimum de prcaution lors de la rutilisation de code existant dans la programmation du logiciel de ladministration. 54.Lincompatibilit des licences peut encore tre illustre par le cas classique dun lment propritaire en prsence dun autre lment Open source copyleft . Les licences gauches dauteur ou copyleftes empchent toute appropriation ds lors que tout logiciel driv devra tre diffus sous la licence dorigine. Cest ce qui est communment qualifi de systme juridique du copyleft, utilis par exemple dans la GPL (General Public License). Les composantes libres non copyleftes dune application, qui peuvent tre diffuses sous une licence de type propritaire, sont dites acadmiques . En dautres termes, un lment libre peut tre contaminant, cest--dire que lorsque tout ou partie de son code source est intgr dans un systme propritaire, lensemble du programme devra obligatoirement faire lobjet dune rediffusion en mode libre.
Si un agent de lentit intgre un lment contaminant dans lapplication informatique, celle-ci sera soit distribue en mode libre, soit limite une utilisation interne (la contamination ne sapplique quen cas de diffusion externe), indpendamment de la volont de ladministration.
Bien entendu, si lapplication informatique est programme afin dtre ultrieurement distribue sous licence libre, le risque de contamination est annihil. Nous reviendrons ultrieurement sur les modes de diffusion, en libre ou en propritaire, dun logiciel32. V. Langage clair pour louverture du logiciel 55.Les objectifs douverture des droits sur le logiciel et dindpendance de ladministration face ses agents informaticiens inciteront galement recommander lutilisation dun langage de programmation clair et communment admis. Ladministration peut ventuellement prospecter les langages utiliss par des entits quelle a rpertories comme partageant des besoins identiques ou complmentaires aux siens. Le recours aux mmes langages informatiques favorisera sans aucun doute un futur processus de mutualisation. Il sert, par ailleurs, linteroprabilit des outils. VI. Identification du mode ultrieur de diffusion 56.Lentit publique ayant dvelopp lapplication en interne (avec ou sans laide dun prestataire extrieur) peut avoir intrt bnficier dune certaine contrepartie financire de lutilisation du logiciel, afin de rentabiliser, notamment, les frais engendrs par la programmation.
32
Cf. infra, n I et suiv..
21 Ainsi, si ladministration espre obtenir une rtribution financire de la part de nouveaux utilisateurs en contrepartie de loctroi dune licence, elle opte pour la diffusion du programme en mode propritaire. A. Licence Open source 57.Si lapplication informatique dveloppe est ultrieurement distribue sous une licence Open source, toute rmunration due en contrepartie de lutilisation du logiciel est exclure puisque le logiciel sera, par dfinition, librement diffus33. Ds lors, ladministration sera particulirement attentive, lors de la programmation, ne pas intgrer dans le logiciel destin tre distribu sous une licence propritaire une composante dite copylefte 34. Dans pareille situation, lensemble de lapplication, et donc de tous ses lments, serait diffus sous une licence libre, ce qui exclurait toute possibilit desprer une contrepartie financire de lutilisation du logiciel35. 58.Par contre, si ladministration ne peut esprer une contrepartie financire de lutilisation du logiciel, il en va autrement des prestations de maintenance quelle effectue sur celui-ci. En effet, ladministration ayant dvelopp le logiciel peut rclamer aux entits utilisatrices une certaine rmunration en contrepartie de services quelle leur fournit, telle la maintenance informatique. Il y aurait ds lors lieu, dans cette hypothse, de se poser la question de lapplicabilit de la lgislation relative aux marchs publics, dont certaines rgles peuvent savrer contraignantes36. Il est donc possible pour ladministration de sorienter vers un systme de mutualisation bas sur un modle libre, sans devoir exclure automatiquement toute rtribution financire. B. Licence propritaire 59.Par contre, une contribution financire des entits publiques utilisatrices nest certes pas exclure lorsque la licence est propritaire. Lavantage financier dont peuvent bnficier les donneurs de licence est incontestablement li la philosophie du modle propritaire. Ladministration prend ds lors garde utiliser un mode de diffusion strict lui garantissant un contrle sur les futurs utilisateurs. Les diffrents modes de diffusion dun programme feront lobjet de nos proccupations dans la deuxime partie de ltude ( la solution existe dj ) 37.
33
Nous tenons toutefois prciser que libre ne signifie pas gratuit et que tout diteur dun logiciel diffus en Open source retire un avantage, telle par exemple la reconnaissance professionnelle de ses pairs ou la contrepartie financire des services annexes fournis. 34 Cf. supra, n IV. 35 Il y a lieu de prendre compte du fait que la distinction opre entre la licence Open source et la licence libre nest pas toujours aussi tranche dans la pratique. 36 Cf. infra, n II et suiv.. 37 Cf. infra, n 89 et suiv..
22
Illustration de la premire hypothse : tableau rcapitulatif
OBJECTIF : ANTICIPER LOUVERTURE DU LOGICIEL Facteurs de russite 1. Identifier les besoins similaires ou complmentaires dautres administrations Prcautions particulires
2. Sassurer de dtenir les ressources humaines ncessaires pour le dveloppement, le suivi et louverture du logiciel
-Faire ventuellement appel un prestataire extrieur pour un soutien technique
3. Sassurer laccs aux codes sources
4. Sassurer de la lisibilit du code
-Dtenir une documentation approprie (exigences l'origine du dveloppement, documents d'architecture, documents de gestion de projets, document d'aides au dveloppeur, document d'aide l'installation, manuel utilisateur, etc.) -Procder la certification du code -Obtenir les commentaires appropris (astuces de programmation, signification de variables, rle de fonction, etc.)
5. Sassurer de la clart des langages utiliss
6. Identifier le mode de diffusion et sassurer de sa faisabilit
-Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts ) -Indiquer expressment la cession des droits patrimoniaux dans le cahier spcial des charges si un prestataire tiers intervient -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts )
7. Sassurer la cession des droits de la proprit intellectuelle sur le logiciel son profit
23
2. Dveloppement par une communaut de dveloppeursutilisateurs, informaticiens des administrations concernes
2.1/ Premier enjeu : Dveloppement du logiciel en communaut (mutualisation en amont)
I. Ncessit de besoins fonctionnels suffisamment proches 60.Les besoins actuels des administrations doivent tre proches. Une trop grande htrognit de ceux-ci peut constituer un obstacle la mutualisation, voire rendre le processus irralisable. Il est recommand de procder une comparaison minutieuse des besoins fonctionnels des diffrentes institutions. Une telle analyse permettra, le cas chant, didentifier ds les prmisses du processus de mutualisation certains points de blocage. II. Groupe au stade du dveloppement A. Taille du groupement 61.Il se peut que les initiateurs dun processus de mutualisation en amont soient trs nombreux. Il nest sans doute pas souhaitable que tous participent effectivement au dveloppement. Un trop grand nombre dinterlocuteurs peut, en effet, nuire la mise en place dun plan daction prcis et un travail efficace ; il complique galement la dfinition de besoins communs, ds lors que le risque de divergences entre les attentes respectives sera plus lev. 62.Au-del dune certaine taille du groupement, il y a lieu de choisir de manire approprie les personnes qui participeront effectivement ce travail de dveloppement du logiciel. Plusieurs modes de dsignation peuvent tre envisags (lection, tournante, critres de qualit,). 63.Il se peut galement que des contraintes organisationnelles provoquent une slection naturelle des participants.
Si une administration dcide de ne sengager dans un processus de dveloppement communautaire qu la condition de disposer dun logiciel dans un dlai strict, et si toutes les entits publiques ne sont pas en mesure daffecter leurs informaticiens suivant des modalits appropries au respect de ce dlai, seuls participeront ceux que leurs administrations acceptent de dtacher (dans une mesure plus ou moins importante) pour le dveloppement communautaire.
24
B. Composition du groupement 64.En dpit du dveloppement au sein dune communaut de dveloppeurs, il est essentiel que le groupement ne soit pas exclusivement constitu des informaticiens des entits concernes. On veillera associer la gestion du projet, selon des modalits appropries, des reprsentants des administrations partenaires, tels les futurs utilisateurs des applications dvelopper ; leur participation est le gage dune adquation entre les solutions techniques dfinies et les besoins fonctionnels (lesquels ne peuvent dailleurs tre efficacement dfinis sans une concertation avec ces utilisateurs ). 65.Ces modalits dchange et de concertation peuvent videmment varier selon les situations. Ainsi, il ne simpose pas ncessairement dassocier directement les utilisateurs au dveloppement stricto sensu, si par ailleurs des mcanismes de collaboration sont mis en place, tels les comits de pilotage, et si des tests frquents permettent dvaluer ladquation des solutions aux besoins. III. Calendrier et gestion du temps 66.La dfinition dun calendrier de travail suffisamment prcis sert un double objectif : dune part, elle permet de dterminer, en termes dobjectif, le dlai dans lequel un dveloppement doit tre assur ; cet lment est important sil conditionne la participation de certaines des entits au processus de mutualisation ; les contraintes et besoins propres chaque entit peuvent sinscrire dans des calendriers politiques qui se rvleront peut-tre incompatibles et compromettront ainsi le partenariat. A cet gard, la dfinition du calendrier permettra, tout le moins, de dceler les difficults ventuelles ds avant le lancement du processus ; dautre part, elle facilite une valuation du rythme de travail (chances, frquence des runions, ) et, partant, des besoins en ressources humaines susceptibles dtre affectes au projet ; les dcisions des administrations concernes, relatives laffectation de leurs informaticiens, pourront ainsi tre prises en connaissance de cause.
Ce calendrier de travail gagnera tre intgr dans une convention de collaboration entre les entits publiques, ce qui nexclut pas quune souplesse lmentaire puisse tre mnage. 67.La circonstance que lorganisation dun dveloppement, dans le cadre dun groupe inspir du modle des communauts Open source, permette dmanciper le projet et ses artisans de contraintes administratives souvent lourdes ne doit pas faire perdre de vue que les informaticiens participant au projet relvent dadministrations dont les responsables (mandataires politiques et/ou fonctionnaires dirigeants) sont anims de proccupations diverses auxquelles une dfinition soigne des contraintes dactions du projet de mutualisation (tel le calendrier) peut apporter une rponse utile, notamment sur le plan de la bonne gestion.
25 IV. Ressources humaines A. Ressources humaines propres aux administrations 68.Lorsque les entits publiques dcident de dvelopper le logiciel lintervention exclusive de leurs informaticiens, il y a lieu, avant le lancement des oprations, de vrifier les disponibilits et les comptences de ces agents et damnager les modalits de leurs contributions respectives. Les modalits daffectation des ressources humaines des partenaires publics gagneront tre dtermines dans une convention de collaboration. B. Appel un prestataire tiers 69.La participation dun prestataire extrieur peut tre envisage dans le cadre du dveloppement de lapplication informatique. En effet, mme si les entits disposent de comptences confirmes en interne, un prestataire extrieur sera toujours le bienvenu pour donner un avis sur une application, estimer la viabilit du programme ou encore pour apporter son soutien technique. Deux hypothses doivent tre distingues, selon que cette intervention est sollicite par les informaticiens ou par les administrations desquelles ceux-ci relvent. 1)Intervention sollicite par les informaticiens 70.Lventuelle proximit avec dimportantes communauts Open source peut inciter y rechercher des collaborations raison des mrites reconnus aux prestataires lis ces communauts. Si lintervention du prestataire est conue titre gratuit, elle peut tre sollicite par les informaticiens titre personnel , sans contrainte particulire. Si cette collaboration ne peut tre envisage qu titre onreux, et sauf considrer que les informaticiens usent de leurs deniers personnels, le financement de cette intervention sera assur par lensemble des administrations concernes ou lune dentre elles. La prestation de services sera invitablement qualifie de march public et relvera du champ dapplication de la lgislation y relative. Le march sera conjoint (cest--dire pass par lensemble des entits reprsentes par lune dentre elles) 38 ou sera pass exclusivement par lune des administrations39. 2)Intervention sollicite par les entits concernes. 71.Lintervention peut tre sollicite la seule initiative des administrations ; tel pourra, par exemple, tre le cas, lorsque celles-ci envisagent de faire certifier la qualit du code crit par lensemble de leurs informaticiens (souci dindpendance). Dans ce cas, la passation dun march public simposera en rgle gnrale.
38 39
Cf. infra, n VIII et suiv.. Cf. infra, n VIII et suiv..
26
* * * 72.Cette hypothse du recours un prestataire tiers, dans le cadre dun march public, tmoigne de ce que, mme si comme on la dj relev le travail en communaut de dveloppeurs permet dmanciper la conduite dun projet des contraintes propres laction des pouvoirs publics, ce modle de mutualisation ne conduit pas un affranchissement complet du contexte administratif dans lequel sinscrit le dveloppement du logiciel. V. Organisation du leadership 73.Lorganisation du leadership est frquemment prsente comme un lment dterminant dans la conduite dun projet de mutualisation. Lanalyse dexpriences rcentes ou actuellement en cours rvle que, entendue dans le contexte de la mutualisation informatique, la notion de leadership peut dsigner deux ralits diffrentes, que sont respectivement la cration dune structure de pilotage (A) et la dsignation dun animateur de projet (B). A. Cration dune structure de pilotage 74.La conception du projet de mutualisation, lorganisation des travaux et les tapes de programmation du logiciel seront utilement supervises par une structure (dnomme, par exemple, comit de pilotage ) dont les membres sont choisis parmi les responsables des administrations impliques, les (futurs) utilisateurs de lapplication informatique et, bien videmment, les informaticiens affects au dveloppement40. 75.Outre lorganisation des travaux en amont , la structure de pilotage sera, le cas chant, galement sollicite, pour se prononcer sur les perspectives douverture du logiciel, notamment en tant que mandataire des administrations, pour dsigner, au nom et pour le compte de celles-ci, les nouveaux utilisateurs du logiciel ou dfinir des modalits douverture. 76.La cration dune structure de pilotage ne doit pas tre confondue avec celle dune structure institutionnelle de mutualisation, distincte des entits qui la composent, et dont il sera question ultrieurement dans la suite de ce rapport. La structure de pilotage ne rpond pas un besoin de cration dune entit juridique spcialement ddie la conduite de projets de mutualisation ; elle constitue simplement un lieu de concertation, dchange dinformations et de collaboration qui peut observer (et, le cas chant, orienter) la conduite du projet en tant dote dune lgitimit que lui confre notamment son caractre htrogne. La composition et les modalits de fonctionnement de la structure de pilotage pourront tre amnages par le biais dune convention de collaboration entre les partenaires publics.
40
En cas dappel un prestataire de services tiers, celui-ci pourra galement tre associ aux travaux de la structure de pilotage.
27
B. Dsignation dun animateur de projet 77.La conduite effective de lexprience de mutualisation peut galement passer par la dsignation formelle (ou la reconnaissance, en cette qualit) dun animateur qui, parmi les entits concernes par le projet, donnera limpulsion et assurera un suivi permanent. La reconnaissance de cette qualit de leader peut simposer naturellement, raison de limportance de linvestissement que consent cet animateur (en ressources humaines et/ou financires, par exemple) ou de circonstances particulires (tel le respect dune chance qui lamne piloter le projet). Ici encore, les modalits dorganisation de ce pilotage pourront tre amnages par la convention de collaboration.
VI. Outillage facilitant la collaboration A. Mthodes de travail 78.Les partenaires peuvent recourir certaines mthodes classiques pour faciliter leurs relations de travail et pour assurer une programmation optimale du code source. Le mode de dveloppement des fonctionnalits sera gnralement court et suivi par des tests de qualit afin de dtecter immdiatement les bugs, erreurs de programmation ou tout autre accroc dordre informatique.
Dans le cadre du projet PloneGov, les partenaires ont recours aux techniques dites du sprint, du peer-programming et au procd de dveloppement agile 41 : 1)La technique du sprint : Le sprint peut tre dfini comme tant une courte priode de programmation dun logiciel. Les participants un projet de mutualisation se runissent un intervalle de temps rgulier pour programmer le systme. Les ides et les proccupations de chaque partie sont mises en avant. Cette technique est particulirement utilise pour les dveloppements et modifications de logiciels distribus sous licence Open source. 2)La technique du peer-programming : Le peer-programming consiste en lorganisation de runions rduites rassemblant les acteurs les plus expriments. Il sagit dune mthode par laquelle chaque participant va vrifier de quelle manire le code est crit et de quelle manire celuici est modifi.
41
Cf. annexe, n I.
28
3)Le procd agile : Le procd agile permet un cycle de dveloppement trs court. A chaque runion, un nouveau logiciel est cr. Cette mthode ncessite une implication tendue des administrations pour le compte desquelles le logiciel est ralis, ce qui permet de bien cibler leurs besoins fonctionnels. Quatre valeurs fondamentales forment la base de la mthodologie : lquipe est au centre du processus ; lapplication doit fonctionner ; la collaboration entre toutes les parties impliques est essentielle ; les parties sont prtes accepter de lgres modifications dans la structure du logiciel et dans la planification initiale du projet si cela savre ncessaire42.
B. Outils de communication 79.La collaboration doit impliquer un vritable dialogue entre les partenaires. Ds lors, la mise en place doutils de partage, comme par exemple la cration dun site Internet, dun wiki , dun forum de discussion ou dun blog sur lesquels chacun peut dposer ses remarques et ides, facilite la collaboration ( tout le moins si le logiciel est vou tre diffus librement).
De la sorte, les sites Internet PloneGov.eu et CommunesPlone.org sont des outils de partage. En outre, un site reprenant on-line les outils de partage dvelopp par PloneGov est en voie de cration43.
80.Lorsque lapplication informatique est destine tre distribue selon un modle propritaire, les administrations ont recours des techniques de communications prives, tels que les mailings ou les systmes intranet. 81.Il est prudent de dsigner un gestionnaire de ces outils. VII. Conclusion dune convention de collaboration : traduction juridique de la mthodologie et importance de saccorder sur les modalits de la collaboration 82.Les considrations prcdemment exposes ont rvl que le dveloppement communautaire peut tre assorti de contraintes daction , gnres notamment par lenvironnement administratif dans lequel sinscrivent les projets. Ds lors que ces contraintes peuvent conditionner les modalits de collaboration et, plus largement, la conduite des projets, les entits publiques gagneront saccorder leur propos. La conclusion dune convention dterminant les modalits de la collaboration est donc, pour cette raison, vivement recommande. Outre quelle traduit (et formalise) laccord entre partenaires publics quils sengagent respecter, cette convention apparat comme le lieu dexpression des besoins et attentes respectifs de ces diffrents partenaires ; ce titre, elle est dote dune importante valeur de repre et joue, en quelque sorte, le rle de tableau de bord du projet.
42
De telles modifications ne peuvent tre apportes que si elles respectent les objectifs tablis par les administrations lorigine du projet. 43 Cf. annexe, n I.
29
A. Une convention de collaboration estelle absolument ncessaire ? 83.A supposer que la dfinition du projet ne rvle aucune contrainte daction et que les parties nidentifient aucune question propos de laquelle pourrait ultrieurement surgir une contestation susceptible de vouer le projet lchec, la conclusion dune convention de collaboration nest videmment pas ncessaire; un formalisme inutile ne doit pas freiner (ou alourdir) la conduite des travaux. Cela tant, lanalyse de diverses expriences rvle que ce cas de figure en lequel une convention de collaboration se rvlerait inutile, parat exceptionnel et peu probable. B. Quel formalisme dans la conclusion du contrat ? 84.Le formalisme auquel est souvent associe ( tort ou raison) la conclusion des contrats peut faire craindre que cette dmarche freine la conduite du projet et soit difficilement compatible avec lesprit informel des dveloppements communautaires. 85.Ce formalisme peut toutefois tre trs lger et se traduire dans ltablissement, par les acteurs directement impliqus, de documents communs soumis lapprobation de leurs autorits respectives44. 86.On rappellera, par ailleurs, que la conclusion de telles conventions nest, au regard du droit commun des contrats, soumis aucune formalit particulire ; si cette considration ne peut luder les ralits propres la qualit publique des parties (laquelle est, bien sr, souvent synonyme de lourdeur), elle permettra de relever que ltablissement dun cadre contractuel de collaboration ne parat pas constituer un vritable obstacle la conduite dun projet de mutualisation, mais garantit plutt la scurit juridique des parties et contribue, de la sorte, au succs de lopration de programmation du logiciel. C. Nature politique ou juridique de la convention et degr de prcision (et de contrainte) des engagements souscrits 87.Le caractre indit de telles conventions qui ne relvent pas dun rgime juridique particulier incite invitablement se demander si elles ont la force qui sattache ordinairement aux contrats de droit commun ou si elles ne revtent essentiellement quune dimension assez symbolique que traduisent de vagues engagements. Cet apparent antagonisme entre les caractres politique et juridique de la convention sera dpass lorsquon aura gard son objet et la porte que les parties entendent lui reconnatre : les deux dimensions (politique et juridique) peuvent dailleurs coexister dans le cadre dun mme projet de mutualisation. 88.Un premier accord, rdig en termes gnraux et manifestement peu contraignants, permet aux autorits politiques des entits concernes de faire part de leur adhsion de principe un projet fond sur la collaboration des parties. Sans dfinir des obligations prcises, cet accord
44
Cf. ce qui est expos, dans lanalyse dune autre hypothse, propos du projet Tabellio (Annexe, nII et suiv.).
30 tmoignera dune volont de collaboration et tracera un cadre gnral dans lequel les agents des entits concernes pourront concevoir les termes plus prcis dun projet de mutualisation. Des accords ultrieurs (limits, le cas chant, des aspects particuliers de collaboration) fixeront les modalits plus contraignantes de la collaboration. Au travers de ces contrats, les entits publiques sengageront dans des liens dobligations traduisant des aspects plus ponctuels du projet, sans lesquels celui-ci ne peut aboutir. Un tel chelonnement des contrats (du plus symbolique au plus effectif ) rgissant lamnagement contractuel des modalits de collaboration permet de tenir compte du fait que la conception dun projet de mutualisation peut tre progressive et ne se prte pas une dfinition pralable, absolue et abstraite du processus. D. Contenu de la convention de collaboration 89.Certains aspects susceptibles dtre rgis par la convention ont dj t voqus, tels lamnagement des mthodes de travail, laffectation des ressources humaines et/ou financires, la dfinition des objectifs et dun calendrier commun, Il est vivement conseill daborder ces aspects qui, de toute vidence, pourront savrer cruciaux pour la viabilit du projet. 90.Quelques questions relatives des phases ultrieures, telle louverture des droits dutilisation du logiciel (mutualisation en aval), peuvent dj tre, sinon rgles, tout le moins suggres, en prcisant, par exemple, quelles feront lobjet dune convention particulire ou seront abordes par certains reprsentants des entits concernes, que cette convention dsigne.
2.2/ Deuxime enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper? (Mutualisation en aval)
I. Identification des perspectives douverture ultrieure dautres utilisateurs A. Besoins identiques ou complmentaires 91.Comme il la dj t dmontr dans notre premier cas de figure (programmation dun logiciel par une administration seule, il est sage pour les partenaires de procder, pralablement au dveloppement de lapplication informatique, une rflexion sur les besoins similaires ou complmentaires dautres entits publiques. Une telle analyse prsentera lavantage de faciliter, si besoin est, une ventuelle mutualisation en aval.
31
B. Prcautions 92.Anticiper louverture des droits dutilisation sur le logiciel ncessite de la part des administrations de prendre certaines prcautions lors du dveloppement de lapplication informatique. Il sagira pour les entits de sassurer de dtenir les droits patrimoniaux ncessaires sur le logiciel, de mettre au point un code source lisible et dutiliser un langage clair et communment admis. En outre, les administrations vrifient que leurs ressources humaines sont suffisantes pour garantir louverture45. Enfin, si les partenaires esprent obtenir une contrepartie financire de lutilisation ultrieure du logiciel, ce qui supposera un mode de distribution propritaire, ils veilleront ce que le dveloppement nintgre pas de composantes Open source qui auraient pour effet dimposer une diffusion libre de lensemble de la solution. II. Droits patrimoniaux de la proprit intellectuelle A. Logiciel dvelopp en interne 93.Il a t prcdemment expos46 que larticle 3 de la loi du 30 juin 199447 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur tablit une prsomption de cession des droits patrimoniaux au profit de lemployeur, cest--dire dans notre hypothse les administrations publiques. Celles-ci deviennent titulaires drivs des droits patrimoniaux de la proprit intellectuelle, alors que leurs agents sont titulaires originaires. B. Co-titularit, uvre de collaboration et amnagement des droits entre les administrations 94.Lorsque le logiciel est dvelopp par les agents des administrations et que celles-ci deviennent cessionnaires des droits dauteur, il est lgitime de sinterroger sur la rpartition exacte des droits entre les partenaires. Chaque administration est-elle considre comme cessionnaire des droits patrimoniaux sur lensemble du logiciel ou au contraire, chaque administration nest-elle considre comme cessionnaire que pour les lments concrtement raliss par ses employs ou agents statutaires ? 95.En tout tat de cause, lon peut estimer que le programme est une uvre de collaboration48 sur laquelle les droits sont indivis. Une distinction doit tre faite selon que les contributions respectives peuvent ou ne peuvent pas faire lobjet dune individualisation : 45
Si les participations de chacun peuvent tre isoles, lon se rfrera par analogie larticle 5 de la loi du 30 juin 1994 relative au droit dauteur et aux droits voisins49 qui
Ici encore, lintensit de cette exigence dpendra du degr de volont douverture qui peut tre constat avant le dveloppement du logiciel. 46 Cf. supra, n III. 47 L. 30 juin 1994 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur. 48 Au sens de la loi du 30 juin 1994 relative au droit dauteur et aux droits voisins. 49 L. du 30 juin 1994 relative au droit dauteur et aux droits voisins.
32 tablit que lorsquil [un logiciel dans notre hypothse] sagit dune uvre de collaboration o la contribution des auteurs peut tre individualise, ces auteurs ne peuvent, sauf convention contraire, traiter de leurs uvres avec des collaborateurs nouveaux. Nanmoins, ils auront le droit dexploiter isolment leur contribution, pour autant que cette exploitation ne porte pas prjudice luvre commune . Si les contributions des informaticiens des partenaires publics ne peuvent tre individualises, lon peut considrer que les entits publiques sont cessionnaires indivis et lon se rfrera par analogie larticle 4 de la loi prcite : lorsque le droit dauteur est indivis, lexercice de ce droit est rgl par les conventions. A dfaut de convention, aucun des auteurs ne peut lexercer isolment, sauf aux tribunaux se prononcer en cas de dsaccord .
Autrement dit, les administrations sont prsumes tre co-cessionnaires des droits patrimoniaux sur une uvre de collaboration. Elles pourront exploiter leurs contributions limitativement si les participations peuvent tre individualises. Dans la situation inverse, une convention dterminera les modalits dexploitation de luvre. Il est ds lors recommand, comme dans toute hypothse de co-titularit ou de co-cessibilit des droits, damnager les relations entre les partenaires publics dans un contrat de collaboration afin de prvoir en outre, les modalits de prise de dcisions et dexploitation ultrieure du logiciel. Il pourrait ainsi tre stipul que chaque entit est libre de dsigner de nouveaux utilisateurs sans avoir obtenir un accord pralable des autres partenaires publics, ou, au contraire, quun tel accord est ncessaire. C. Logiciel dvelopp en partie par un prestataire extrieur 1)Les droits sont amnags dans le cahier spcial des charges : 96.Si les administrations font appel un prestataire de services pour la programmation dune composante du logiciel, la lgislation relative aux marchs publics est dapplication. Le march sera conjoint (cest--dire pass par lensemble des entits reprsentes par lune dentre elles) ou sera pass exclusivement par lune des administrations50. Le march est conjoint 97.Dans notre premier cas de figure, les entits recourent la technique du march conjoint, cest--dire que toutes ont le statut de pouvoir adjudicateur. Le cahier spcial des charges dtermine les droits qui sont transfrs de manire indivise aux pouvoirs adjudicateurs. En dautre terme, puisque les entits sont co-titulaires des droits, tout acte dexploitation ultrieur de la composante ne sera possible que si les partenaires saccordent lunanimit51. Le march est pass par une seule administration
50 51
Cf. infra, n VIII et suiv.. Ce qui est dailleurs galement le cas des autres composantes dveloppes en interne par les administrations. Comme il la t dvelopp au point prcdent (cf. supra, nII) les modalits dexploitation du logiciel (une fois celui-ci entirement programm) devront tre amnages dans une convention de collaboration.
33 98.Dans le second cas de figure, lorsquune seule administration est pouvoir adjudicateur, le cahier spcial des charges doit galement mentionner clairement et sans quivoque les droits de la proprit intellectuelle qui sont transmis de ladjudicataire au pouvoir adjudicateur. Etant donn que seule celui-ci devient titulaire des droits patrimoniaux, il est invitable de conclure une convention de collaboration afin de prvoir, avec les diffrentes administrations, un partage des droits sur la composante entre les diffrentes administrations concernes. En effet, lobtention pour les autres entits dun simple droit dutilisation ne serait pas suffisante tant donn que dans notre hypothse dveloppement dun logiciel par plusieurs administrations en interne le prestataire de services nopre que de manire ponctuelle pour une composante de lensemble de lapplication. Les administrations qui ne sont pas pouvoirs adjudicateurs doivent tre titulaires des droits sur tous les lments du logiciel et non pas uniquement sur ceux quelles auraient dvelopps en interne. Si tel nest pas le cas, lon arriverait invitablement une situation de blocage du processus ou de dpendance des entits face lune dentre elles, seule titulaire des droits sur lensemble des composantes de lapplication informatique52. 2)Les droits sont amnags par le biais dune licence Open source : 99.Que le march soit conjoint ou unique, le prestataire de services peut proposer lutilisation de composantes libres pour la programmation du logiciel. Dans cette hypothse, lamnagement des droits au profit du ou des pouvoirs adjudicateurs ne pose gure de problme tant donn que la licence Open source prvoit le partage de ces droits entre tous les utilisateurs. Les administrations sont cependant attentives ne pas insrer dans le logiciel un lment dit copyleft , qui ne peut faire lobjet dune appropriation (si toutefois lobjectif des entits est de diffuser le logiciel en mode propritaire) 53. III. Code source A. Accs au code source 100.Il est crucial pour la russite du projet de mutualisation que les administrations puissent bnficier de laccs au code source. Dans notre hypothse, les partenaires publics disposent du code source puisquils se sont amnag les droits sur le logiciel. Ils pourront donc lexploiter leur guise pour les modifications, adaptations ou corrections ultrieures du logiciel.
52
Il serait en effet difficile davancer dans le processus de mutualisation si le logiciel est compos dlments dont la titularit des droits sur les composantes varie dune administration lautre. 53 Cf. supra, n IV.
34
B. Lisibilit du code et prestataire de certification 101.La lisibilit du code est essentielle pour assurer louverture du logiciel. Un code clair permet encore de garantir lindpendance des administrations face aux agents internes dveloppeurs de lapplication informatique54. 1)Plusieurs prcautions sont prendre dans le chef des informaticiens dveloppeurs : Les informaticiens sont attentifs la manire dont sera rdig le code lors de la programmation de lapplication informatique (respect des conventions de codage, dcoupage du code55). Ils ont recours des procds de dveloppement impliquant des vrifications rgulires du code, comme cest la cas dans la technique du peer-programming 56. Ils sont attentifs au problme dincompatibilit des licences. En outre, il veille ne pas intgrer dlments copylefts57 dans le programme.
2)Plusieurs prcautions sont prendre dans le chef des administrations : Les partenaires publics sassurent de dtenir toute la documentation ncessaire la comprhension du code source (architecture du code, copies) et dtre ainsi en mesure de la transmettre des entits qui utiliseront le code des fins, par exemple, de maintenance sur le logiciel. Elles prennent le soin de recourir aux services dun prestataire extrieur de certification. Notons que les modalits de la certification soulvent un certain nombre de questions pouvant tre rgules au sein dune convention de collaboration entre les administrations. Ainsi, les partenaires publics peuvent dsigner ds les prmisses du projet de mutualisation un prestataire de certification dtermin qui interviendra pendant et aprs le dveloppement de lapplication informatique. Les entits publiques conviennent des modalits de dsignation du prestataire : lunanimit des partenaires ou selon le choix de lun ou de plusieurs dentre eux. En outre, afin dviter les blocages ultrieurs, les partenaires saccordent ds le stade du dveloppement de lapplication sur le mode de financement du prestataire de certification. IV. Langage clair pour louverture du logiciel 102.Telle la bonne lisibilit du code source, lutilisation dun langage clair et amplement utilis favorise louverture du logiciel dautres entits publiques. En effet, les administrations, futures utilisatrices du logiciel, seront mme dassurer le suivi de son exploitation.
54 55
Cf. supra, n IV et suiv.. Cf. supra, n IV. 56 Cf. supra, n VI. 57 Cf. supra, n IV
35
Ainsi, les initiateurs du projet PloneGov ont procd une prospection des diffrents langages utiliss par les administrations, avant de se baser sur le langage plone et sur le langage python, dont lutilisation a dernirement doubl. Leur objectif tait dviter tout prix un langage qui puisse devenir un frein la mutualisation58.
103.En outre, si la technologie est largement utilise, les administrations pourront toujours faire ultrieurement appel des prestataires extrieurs pour assurer le suivi de lutilisation du programme. Les risques de dpendance face un membre du personnel irremplaable sont amoindris. V. Disponibilit en ressources humaines et financires pour assurer l'ouverture 104.Il est recommand dtablir conventionnellement les modalits daffectation des ressources humaines et financires pour assurer louverture ds le stade du dveloppement du logiciel. Cependant, lvolution du projet nest pas toujours aise prvoir (nouveaux utilisateurs, dpart dun partenaire) et il y a lieu de garantir un modus operandi relativement souple afin de permettre ladaptation ultrieure de ces affectations. La viabilit du processus de mutualisation informatique peut tre affecte si les parties ne parviennent pas saccorder sur ces modalits de collaboration. A. Ressources financires 105.Tout projet de mutualisation ayant vocation durer dans le temps, il y a lieu dassurer la viabilit financire du projet. Les administrations saccordent sur le prix quelles entendent ventuellement faire payer aux futures entits, en contrepartie de la licence dutilisation ou en contrepartie des prestations de maintenance si elles assurent ces dernires. 106.La contrepartie du droit dutilisation dun logiciel nest pas ncessairement dordre financier. Ainsi, lorsquun logiciel est diffus sous licence libre, chaque membre de la communaut apporte sa contribution en fonction de ses moyens et espre tirer profit de lapport des autres partenaires. Il est ds lors moins important de saccorder sur le prix faire payer par de futures entits utilisatrices que de sassurer de leur ventuelle volont de collaboration et de partage. B. Ressources humaines 107.Tel le financement, lintervention humaine des partenaires pour le suivi de lexploitation du logiciel est un aspect sur lequel les parties doivent au plus vite saccorder, de prfrence par le biais dune convention de collaboration. Il y a lieu de fixer clairement comment le logiciel sera ultrieurement exploit, comment les prestations annexes, telles que la maintenance corrective, volutive ou encore la formation des futures entits utilisatrices, seront fournies. Eu gard au fait que ces prestations ne pourront peut-tre pas toujours tre assures par les agents des administrations concernes, et devront ltre par un prestataire
58
Cf. annexe, n I.
36 dans le cadre dun march de services, il peut tre utile de dterminer, par la convention de projet, les modalits de passation du march (march conjoint, par exemple). Cette prcaution nexclut toutefois pas que ces modalits soient ultrieurement revues la faveur dun nouvel accord entre toutes les parties. VI. Identification du mode ultrieur de diffusion 108.Les entits publiques ayant dvelopp lapplication en interne (avec ou sans laide dun prestataire extrieur) peuvent avoir intrt bnficier dune certaine contrepartie financire de lutilisation du logiciel afin de rentabiliser, notamment, leurs frais de programmation. 109.Si les administrations comptent sur ces ressources financires en contrepartie de lusage du programme, elles sassurent de diffuser celui-ci sous une licence propritaire. Lutilisation dun logiciel Open source est en effet gnralement gratuite (sauf considrer les logiciels que lon pourrait qualifier d hybrides : mi-libres, mi-propritaires). Ds lors, ladministration sera particulirement attentive lors de la programmation ne pas intgrer dans le logiciel une composante dite copylefte dont lappropriation est impossible. Nous renvoyons pour le surplus nos commentaires prcdents59.
59
Cf. supra, n VI et suiv..
37
Illustration de la deuxime hypothse : tableau rcapitulatif

OBJECTIF : DEVELOPPEMENT DU LOGICIEL EN COMMUNAUTE Facteurs de russite 1. Ncessit de besoins fonctionnels proches entre les administrations 2. Sassurer que la taille et la composition du groupe sont adaptes au processus de dveloppement -Favoriser une taille modre du groupe au stade du dveloppement -Dterminer la composition du groupe en fonction de la situation (impliquer les utilisateurs, mettre en place un comit de pilotage etc.) Prcautions particulires
3. Dfinir prcisment le calendrier de travail 4. Sassurer de dtenir les ressources humaines ncessaires pour le dveloppement 5. Organiser le leadership 6. Prvoir des outillages favorisant la collaboration 7. Rdiger une convention de collaboration
-Faire ventuellement appel un prestataire extrieur pour un soutien technique -Crer une structure de pilotage -Dsigner un animateur de projet -Dterminer une mthode de travail et prvoir des outils de collaboration -Dterminer lamnagement des mthodes de travail, laffectation des ressources humaines et/ou financires, la dfinition des objectifs et dun calendrier commun etc.
OBJECTIF : ANTICIPER LOUVERTURE DU LOGICIEL Facteurs de russite 1. Identifier les besoins similaires ou complmentaires dautres administrations 2. Sassurer la cession des droits de la proprit intellectuelle sur le logiciel son profit Prcautions particulires
-Dterminer les modalits dexploitation de luvre dans une convention de collaboration afin de soulever les problmes lis la co-titularit des droits -Indiquer expressment la cession des droits patrimoniaux dans le cahier spcial des charges si un prestataire tiers intervient
38 -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts ) -Faire ventuellement appel un prestataire extrieur pour un soutien technique -Dtenir une documentation approprie (exigences l'origine du dveloppement, documents d'architecture, documents de gestion de projets, document d'aides au dveloppeur, document d'aide l'installation, manuel utilisateur, etc.) -Procder la certification du code -Obtenir les commentaires appropris (astuces de programmation, signification de variables, rle de fonction, etc.) -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts )
3. Sassurer de dtenir les ressources humaines et financires ncessaires pour le suivi et louverture du logiciel 4. Sassurer laccs aux codes sources
6. Sassurer de la clart des langages utiliss 7. Identifier le mode de diffusion et sassurer de sa faisabilit
39
3. Dveloppement par un prestataire de services la demande d'une administration "seule"
Enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper?

I. Identification des perspectives douverture ultrieure dautres utilisateurs A. Besoins identiques ou complmentaires 110.Ladministration qui fait appel un prestataire extrieur pour le dveloppement dune application informatique sest, dans un premier temps, cantonne lanalyse des manquements informatiques qui lui sont propres.
Le caractre spcifique du projet Iriscom (dveloppement dune application informatique de gestion des chantiers de voirie pour la Rgion de Bruxelles capitale) na pas incit ses initiateurs se proccuper des besoins similaires existants ventuellement dans le chef dautres administrations60.
111.Lentit publique peut cependant, pralablement au dveloppement du logiciel, examiner la proximit des besoins identiques ou complmentaires dautres administrations, ce qui permettra dengager ultrieurement un processus de mutualisation en aval. B. Prcautions 112.Dans loptique dune ouverture du logiciel dvelopper, ladministration est amene prendre certaines prcautions au stade de la programmation. Ainsi, elle prend soin dacqurir les droits patrimoniaux de la proprit intellectuelle ncessaires une potentielle mutualisation en aval. Elle exige en outre du prestataire de services que les codes utiliss soient aisment comprhensibles et que les langages choisis soient communment admis. Elle procde une rflexion sur ses ressources humaines et financires et anticipe la manire de combler certains manquements. Enfin, afin dviter de dpendre dun prestataire extrieur pour les services de maintenance sur le logiciel (adaptation, correction, amlioration, formation), elle sassure de disposer des codes sources et de toute la documentation y relative.
60
Cf. annexe, n .
40
II. Contrat de louage douvrage, application de la lgislation relative aux marchs publics et cahier spcial des charges A. Qualification du contrat 113.La qualification reconnatre au contrat revt une importance significative sur lvolution du projet de mutualisation. Dune part lapplication de la lgislation relative aux marchs publics, dont les rgles peuvent savrer contraignantes, dpendra de la qualification attribue la convention et dautre part, chaque contrat dtermine des droits et obligations spcifiques pour les parties. 114.Le contrat de dveloppement dun logiciel sur mesure pour les besoins de ladministration est un contrat de prestation de services qualifi de contrat de louage douvrage et est dfini comme tant un contrat par lequel lune des parties sengage faire quelque chose pour lautre, moyennant un prix convenu entre elles. 61 Si le matre de louvrage est un pouvoir adjudicateur au sens de la lgislation relative aux marchs publics ce qui est le cas dans notre hypothse alors, celle-ci sera dapplication.
B. March public62
115.La lgislation relative aux marchs publics est susceptible de sappliquer tout march que constituent les marchs de travaux, de fourniture et de services. Sagissant de la dernire catgorie, le lgislateur dfinit le march public de services comme un contrat titre onreux conclu entre un prestataire de services et un pouvoir adjudicateur et ayant pour objet des services viss dans lannexe 2 de la loi. 63 Les conditions dapplication de la lgislation (un contrat conclu titre onreux une prestation de services la qualit de pouvoir adjudicateur) sont rencontres lors du dveloppement dun logiciel sur mesure par un prestataire de services et la demande dune administration. Les rgles relatives aux marchs publics sont ds lors dapplication dans notre hypothse. Ladministration doit procder la passation du march et pour ce faire, rdiger un cahier spcial des charges. Notons toutefois que la prestation ne peut tre qualifie de march public lorsque la situation envisage rencontre les caractristiques des oprations in house . Nous reviendrons ultrieurement sur les questions souleves par les marchs in house64.
61 62
Art. 1710 C. civ. Nous renvoyons aux L. du 24 dc. 1993 et du 15 juin 2006 relatives aux marchs publics et certaines catgories de travaux, de fourniture et de services. 63 Art. 5 L. du 24 dc. 1993 relative aux marchs publics et certaines catgories de travaux, de fourniture et de services. 64 Cf. infra, n V et s..
41 III. Clauses insrer dans le cahier spcial des charges 116.Dans un objectif douverture des droits sur le logiciel, ladministration prend soin de rdiger le cahier spcial des charges de la manire la plus prcise possible afin dviter toute inscurit juridique. Le cahier ne doit poser aucun problme dinterprtation : les expressions redondantes, inutiles, non pertinentes et les contradictions sont viter. Il doit en outre tre complet, cest--dire que lensemble des besoins y est exprim. Un cahier des charges rdig de la sorte minimise les risques juridiques, les dpassements de budget et les problmes de calendrier. 117.Lentit publique se doit dtre particulirement vigilante lors de la rdaction de certaines clauses, fondamentales pour un processus de mutualisation en aval. Ce sont ces clauses que nous proposons danalyser dans le cadre de ce rapport. A. Utilisation ultrieure du logiciel 118.Les clauses concernant lutilisation ultrieure du logiciel par des entits autres que le pouvoir adjudicateur doivent faire lobjet dune attention toute particulire : elles seront dterminantes pour la russite dun projet de mutualisation en aval. Ces clauses sont spcialement importantes dans le cas de figure o le pouvoir adjudicateur ne se voit pas transfrer la totalit des droits de la proprit intellectuelle sur le logiciel (ce qui reviendrait pouvoir exploiter inconditionnellement lapplication informatique). Le prestataire de services a en effet intrt se rserver certains droits de manire continuer lexploitation ultrieure du logiciel et en retirer un certain profit. Signalons que plus les possibilits offertes au pouvoir adjudicateur sont importantes, plus le cot payer sera consquent. 1)Les futurs utilisateurs sont dsigns dans le cahier spcial des charges : 119.Une premire possibilit pour le pouvoir adjudicateur, afin damnager louverture du logiciel, rside dans linsertion dune clause dans le cahier spcial des charges, dsignant les futurs utilisateurs dtermins ou dterminables. Sil dsire garder la mainmise sur la distribution du logiciel, le prestataire de services sera rticent ce que les futurs utilisateurs puissent tre dsigns de manire quivoque. 120.Dans ce cas de figure, le pouvoir adjudicateur peut recourir la technique dite de la stipulation pour autrui : le stipulant fait promettre au promettant quun avantage du contrat bnficiera au tiers bnficiaire si ce dernier laccepte65. Ainsi, dans notre hypothse, cela reviendrait ce que le pouvoir adjudicateur ou stipulant, fasse promettre au prestataire de services ou promettant, quune administration extrieure au contrat, cest--dire le tiers bnficiaire, pourra utiliser le logiciel et ventuellement bnficier des services annexes telle que la maintenance corrective. Cette hypothse semble respecter les trois conditions de la stipulation pour autrui que sont : lintention de dterminer un droit direct et immdiat la dsignation dun tiers dtermin ou dterminable le caractre accessoire de la clause face au contrat principal. Notons encore que lacceptation par le tiers bnficiaire nest pas une condition de validit de la stipulation. Leffet de lacceptation est dengendrer un
65
Larticle 1121 C. civ. dispose que : on peut pareillement stipuler au profit dun tiers, lorsque telle est la condition dune stipulation que lon fait pour soi-mme ou dune donation que lon fait un autre. Celui qui a fait cette stipulation, ne peut plus la rvoquer, si le tiers a dclar vouloir en profiter .
42 droit au profit dune administration que le prestataire de services ne sera plus habilit rvoquer. La stipulation pour autrui prsente un avantage indniable face une clause classique de dsignation dun utilisateur : la stipulation implique que lentit bnficiaire dtient un droit direct et immdiat lencontre du promettant et pourra revendiquer son exercice en justice, si celui-ci ne respecte pas ses engagements. 2)Le pouvoir adjudicateur se rserve une facult douverture des utilisateurs non identifis : 121.Les futures entits utilisatrices de lapplication informatique ne sont gnralement pas identifies et dnombres prcisment ds le stade de la programmation du logiciel. Si les droits de la proprit intellectuelle ne lui sont pas transmis de manire exhaustive, le pouvoir adjudicateur prend soin quune clause du cahier spcial des charges lui garantisse une facult douverture des acteurs encore non identifis. Plus la cause est extensive, plus le pouvoir adjudicateur se garantit un large champ daction. Il se peut cependant que la clause soit rdige plus restrictivement afin de rencontrer les proccupations du prestataire de services. Les modalits de la dsignation sont alors prcises il est par exemple stipul que louverture du logiciel se limite lobjectif vis par la mutualisation ce qui empche le prestataire de services de craindre une utilisation illimite de lapplication informatique. Une augmentation sensible des prix peut, de la sorte, tre vite. B. Droits patrimoniaux de la proprit intellectuelle 1)Lamnagement des droits patrimoniaux doit tre prcis dans le cahier spcial des charges : 122.Nous avons vu quil existe une prsomption de titularit drive au profit de lemployeur, et donc au profit de ladministration lorsque le logiciel est dvelopp en interne par les employs et/ou agents statutaires66. Par contre, aucune prsomption nexiste lorsque lapplication est ralise par un prestataire extrieur. Il faut, dans cette hypothse, amnager contractuellement la manire selon laquelle seront rpartis les droits sur lapplication informatique entre le pouvoir adjudicateur et le prestataire de services. Dailleurs, si le prestataire de services est lauteur du logiciel (cest--dire la personne physique qui a cr luvre, titulaire originaire des droits), la loi relative au droit dauteur et aux droits voisins impose que la cession des droits soit expressment prvue67. Dans les autres cas, o le prestataire de services est le titulaire driv des droits (par exemple lemployeur du dveloppeur de lapplication informatique), il est galement indispensable de prvoir le transfert des droits de manire expresse dans le cahier spcial des charges. 2)Il existe diverses manires damnager contractuellement les droits patrimoniaux :
66 67
Cf. supra, n II et suiv.. Art. 3, 3, al. 3 de la loi du 30 juin 1994 relative au droit dauteur et aux droits voisins : Lorsque les uvres sont cres par un auteur en excution dun contrat de commande, les droits patrimoniaux peuvent tre cds celui qui a pass la commande pour autant que lactivit de ce dernier relve de lindustrie non culturelle ou de la publicit, que luvre soit destine cette activit et que la cession des droits soient expressment prvue.
43
123.Lamnagement des droits patrimoniaux sur le logiciel est un lment fondamental de la russite dun projet de mutualisation en aval. Rappelons que ces droits comportent la reproduction permanente ou provisoire, la distribution sous toute forme au public, ladaptation, larrangement, la location et le prt du logiciel68. 124.Diffrentes situations rsultant de lagencement des droits patrimoniaux peuvent tre envisages. Dun ct, le prestataire de services qui a amlior son savoir faire peut souhaiter garder une certaine mainmise sur le logiciel et sur son exploitation ultrieure. De lautre ct, le pouvoir adjudicateur qui, sil dsire entamer un processus de mutualisation en aval, a tout intrt obtenir des droits tendus sur le logiciel. Si le pouvoir adjudicateur se rserve la titularit de la plupart (voire de la totalit) des droits de la proprit intellectuelle sur le logiciel, il pourra exploiter librement celui-ci. Dans ce cas de figure, ladministration dsignera sa guise les futurs utilisateurs de lapplication informatique et sera mme habilit prvoir la distribution du logiciel en mode libre afin de lui garantir une utilisation largie.
- Dans le cadre du projet IAM PAM, la Rgion wallonne sest vu transfrer la totalit des droits sur le logiciel, ce qui a permis ladministration de dsigner librement les utilisateurs de lapplication informatique. Nanmoins, ladministration a t confronte certains blocages juridiques lors de louverture du logiciel des entits autres que les dpartements de la Rgion wallonne. En effet, ds lors que les organismes dintrt public et les pouvoirs locaux ont une personnalit juridique distincte de la Rgion wallonne, ils ne bnficient pas automatiquement des droits patrimoniaux69. - Une clause du cahier spcial de charges peut amnager le transfert de la proprit sur les rsultats : Le travail de ladjudicataire et les rsultats sont la proprit du pouvoir adjudicateur. Ainsi, ladjudicataire cde au pouvoir adjudicateur lensemble des droits de proprit intellectuelle, et en particulier les droits dauteur, affrents aux Rsultats. Outre une copie sur support numrique de lapplication informatique, ladjudicataire remet une copie (sur support papier et sur support numrique) des documents prparatoires, de la documentation, des manuels dutilisation et des codes sources relatifs aux applications ralises en excution du march.
Cependant, le transfert de la quasi-totalit des droits nest pas toujours indispensable pour le processus de mutualisation en aval. Ainsi, lorsque le pouvoir adjudicateur sest garanti une certaine facult douverture des droits (stipulation pour autrui ou clause de dsignation de futurs utilisateurs), le simple accs au code source pour la modification du programme, uniquement des fins de maintenance, peut savrer tre une solution suffisante et efficace. Le prix de la prestation de dveloppement du logiciel dpendra dans une large mesure du partage de ces droits.
68
Art. 5 L. 30 juin 1994 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur. 69 Cf. annexe, n II.
44
3)Certaines clauses accompagnent utilement lamnagement des droits patrimoniaux : 125.Outre la clause amnageant les droits sur les rsultats, il est judicieux dinclure dans le cahier spcial des charges les dispositions suivantes : - Une clause dfinit le terme Rsultat afin dviter toute ambigut :
Par Rsultats on entend lensemble des produits du travail de ladjudicataire, en ce compris les documents prparatoires, les codes sources, la documentation, les manuels dutilisation, les applications informatiques et toutes autre donnes ou pices relatives lexcution du march.
- Une clause de garantie dviction protgera le pouvoir adjudicateur contre la revendication dun tiers qui serait titulaire de certains droits sur lapplication informatique :
Ladjudicataire garantit tre investi de tous les droits quil cde au pouvoir adjudicateur. Ladjudicataire garantit donc que les rsultats ne sont grevs daucun droit de proprit intellectuelle au profit de tiers et ne font lobjet daucune revendication de la part de tiers. Ladjudicataire garantit le pouvoir contre toute revendication dun tiers (en ce compris les prposs ou les personnes qui il aurait confi une partie de ses tches) propos de lutilisation des rsultats. En cas de revendication dun tiers, ladjudicataire sengage ngocier, ses seuls frais, les autorisations de cession de droits ventuellement manquantes. Si cela savre impossible, il devra fournir au pouvoir adjudicateur une solution de rechange rpondant aux mmes fonctionnalits et pralablement agre par le pouvoir adjudicateur. Ladjudicateur garantit nutiliser aucune composante dont lintgration dans les rsultats aurait pour effet de confrer des tiers un quelconque droit sur tous (ou partie de) ces rsultats.
- Une clause de confidentialit permettra dviter les situations embarrassantes o le prestataire de services communique des informations sur les qualits intrinsques du logiciel :
L'adjudicataire sengage ne pas divulguer directement ou indirectement aux tiers, que ce soit titre publicitaire ou nimporte quel autre titre, qu'il excute le prsent march pour le client sans avoir obtenu son accord pralable et crit. Dune manire gnrale, l'adjudicataire s'engage observer la plus stricte confidentialit concernant lensemble des renseignements et informations, en ce compris les donnes qu'il aura obtenues ou dont il aurait eu connaissance dans le cadre ou l'occasion de l'excution du prsent march. Ils ne divulgueront ces informations confidentielles qu ceux de leurs employs, ou employs du partenaire privilgi, qui sont directement impliqus par lexcution du march ou qui utilisent le logiciel; ils garantissent que ces employs connaissent et respectent les obligations concernant le caractre confidentiel des informations.
45
Les obligations de confidentialit prvues dans le contrat persisteront aussi longtemps que ces informations conserveront leur caractre confidentiel, mme au-del de la date de fin du contrat. 70
- Il peut encore tre prvu que les rsultats ne pourront tre diffuss que si le pouvoir adjudicateur a marqu son accord :
Toute publication ou prsentation du travail effectu dans le cadre du prsent contrat, sous quelque forme que ce soit, mme partielle, par ladjudicataire, doit tre autoris par le pouvoir adjudicateur. De mme, toute publication de ce travail par le pouvoir adjudicateur, se fait en mentionnant obligatoirement le nom de ladjudicataire, les droits scientifiques de ce dernier tant dautre part, sauvegards.
- Une clause prcisant que seul le pouvoir adjudicateur sera habilit dcider de lutilisation ultrieure des rsultats. Cette disposition est directement lie un transfert de tous les droits patrimoniaux au profit du pouvoir adjudicateur. Nanmoins, une telle clause peut prvenir dventuels malentendus sur la porte des droits transmis.
Dans lhypothse dun processus de mutualisation, une disposition du cahier spcial des charges prcise comment seront utiliss les rsultats et la porte des droits dutilisation : Seul le pouvoir adjudicateur est habilit dcider de lutilisation ultrieure des rsultats et dsigner les bnficiaires ainsi que la porte des droits dutilisation de lapplication informatique ralise et fournie par ladjudicataire. Le pouvoir adjudicateur se rserve le droit dexploiter et de rutiliser les rsultats toutes fins utiles et sous quelque forme ou support que ce soit.
C. Accs aux codes sources 1)Le pouvoir adjudicateur devient propritaire71 du code : 126.Le pouvoir adjudicateur, titulaire des droits patrimoniaux sur le logiciel, accde de ce fait aux codes-sources qui lui permettront dexploiter le logiciel, de le modifier ou de le dvelopper sa guise. 127.Toujours afin de garantir son indpendance, il est recommand au pouvoir adjudicateur de se mnager laccs tous les documents, tels que les manuels dexplication du systme de codage, en autant dexemplaires souhaits, lui permettant une utilisation optimale du code source. 128.Enfin, le pouvoir adjudicateur, par le biais des clauses techniques du cahier spcial des charges, prend toutes les mesures ncessaires pour assurer la lisibilit du code et pour viter les problmes dincompatibilit des licences. Il peut encore recourir aux soins dun prestataire
70
La clause provient du cahier spcial des charges du Parlement de la Communaut franaise de Belgique et du Parlement francophone bruxellois pour la libralisation de la suite logicielle Tabellio (cf. annexe, n II et suiv.). 71 La proprit est entendue sous rserve de certaines nuances puisque les droits moraux sont inalinables.
46 extrieur de certification du code72. Le recours un tel prestataire fera lobjet dun march distinct.
- Dans le cadre du projet IAM PAM, ladministration a souhait obtenir le transfert du code source des fins de prcaution. Le pouvoir adjudicateur se garantit ainsi une certaine indpendance73. - Dans le cahier des charges Tabellio 74, une clause garantit la bonne lisibilit du code : Tous les lments de code seront documents exhaustivement, et plusieurs niveaux d'abstraction si la complexit du code l'exige. Le style et le niveau de documentation sont uniformes travers tout le code. Le code comprend galement toutes les procdures dinstallation et tous les fichiers de configuration dment documents. Le code comprend aussi un rfrentiel reprenant les rgles de codage. Ces rgles dfinissent les conventions de style essentielles pour lobtention dun style uniforme de codage assurant une meilleure lisibilit du code.
2)Le pouvoir adjudicateur nest pas habilit utiliser librement le code source : 129.Mme si les codes sources appartiennent au pouvoir adjudicateur, ce dernier peut voir son indpendance face au prestataire de services samoindrir si les outils de dveloppement du code sont rests en mode propritaire.
Ainsi, bien que les codes-sources appartiennent ladministration initiatrice du projet Iriscom, les outils de dveloppement de ce code sont propritaires et seul le prestataire en a la matrise. Le mode de mise disposition du code-source est inappropri une ventuelle volont de mutualisation en aval75.
130.Pareillement, si le code source ne peut tre utilis qu des fins de maintenance corrective76 cest--dire pour parer aux bugs et erreurs de lapplication le pouvoir adjudicateur reste dans une position de dpendance face au prestataire de services.
Le pouvoir adjudicateur nest alors habilit utiliser le code source que de manire limite et devra faire appel au prestataire extrieur lorsque se fera sentir la ncessit doprations plus lourdes, telle quune adaptation ou une modification des qualits intrinsques de lapplication informatique.
72 73
Cf. supra, n IV. Cf. annexe, n II. 74 Cf. annexe, n II et suiv.. 75 Cf. annexe, n . 76 Cf. infra, n III.
47
3)Les parties recourent la technique de l escrow agreement : 131.La technique juridique de lescrow agreement fait appel un tiers qui sera habilit communiquer le code source au pouvoir adjudicateur dans des circonstances particulires et prdfinies par le cahier spcial des charges. Cet amnagement laisse une grande souplesse dans la dfinition des situations o le pouvoir adjudicateur peut utiliser le code. La scurit juridique est garantie grce lintervention dun tiers de confiance. Comme dans la situation prcdente, le pouvoir adjudicateur na pas la possibilit dexploiter le code-source librement. Il doit ds lors requrir du prestataire de services que les amliorations et dveloppements ultrieurs du logiciel lui soient communiqus. D. Responsabilit du prestataire de services et dissolution du contrat 132.Les parties sont soumises en rgle gnrale au droit commun de la responsabilit contractuelle en cas dinexcution de leurs obligations. Il est toujours possible dalourdir ou dallger les obligations respectives du pouvoir adjudicateur ou du prestataire de services par le biais de clauses insres dans le cahier spcial des charges. Il est crucial de dterminer prcisment quelle sera la responsabilit du prestataire de services en cas de dysfonctionnement de lapplication informatique o si ses fonctionnalits ne correspondent pas aux attentes et aux besoins du pouvoir adjudicateur. Des indemnits peuvent tre contractuellement amnages.
Une clause amnageant la responsabilit du prestataire de services est prvue dans le cahier spcial des charges : Ladjudicataire est responsable du choix des services proposs en vue dobtenir les rsultats viss tels que dcrits dans les Dispositions techniques . Il sengage observer tous les engagements pris et toutes les garanties quil a donnes dans son offre ainsi que tous documents signs par lui. Ladjudicataire rpondra vis--vis du client de toutes les prestations excutes par lui-mme ou par ses sous-traitants. Cette responsabilit ne saurait tre limite par aucune clause contractuelle. La prsente clause prvaut, le cas chant, sur toute clause contraire des documents contractuels du march. Le soumissionnaire demeure, par ailleurs, seul et pleinement responsable des engagements quil a souscrits envers le client et du fait de ses sous-traitants. Lappel de sous-traitants nexempte ladjudicataire, ni entirement ni partiellement, des dispositions gnrales ou spcifiques applicables au march. Ladjudicataire devra avoir souscrit et maintenir en vigueur, pendant toute la dure dexcution du march, une police d'assurance couvrant tant sa responsabilit en cas d'accident du travail, que sa responsabilit civile professionnelle pour tous les dommages corporels ou incorporels de quelque nature et de quelque montant que ce soit. Il devra, si cela n'a dj t fait au stade de la remise de son offre, en apporter la preuve dans les quinze jours de calendrier suivant la conclusion du march77.
77
Clause du cahier spcial des charges du projet Tabellio (cf. annexe, n II et suiv.).
48 133.Une question parallle celle de la responsabilit du pouvoir adjudicateur mrite dtre pose : le pouvoir adjudicateur, en cas dinsatisfaction du travail de son cocontractant, a-t-il la possibilit de contracter avec un autre prestataire de services et ce, en gardant le profit du travail dj ralis et le bnfice des droits de la proprit intellectuelle sur les rsultats ? 1)Ladministration demande la rsolution78 du contrat en justice : 134.Lorsque ladjudicataire ne remplit pas ses obligations contractuelles, le pouvoir adjudicateur peut demander la rsolution du contrat devant les Cours et tribunaux. En outre, des clauses rsolutoires peuvent tre insres dans le contrat de prestation de services. La rsolution du contrat implique que les choses doivent tre remises dans le mme tat que si la convention navait jamais exist. Cela signifie que le pouvoir adjudicateur naura aucunement la possibilit dobtenir certains droits sur les rsultats dj raliss, sauf si une disposition du cahier spcial des charges prvoit le contraire. 2)Le pouvoir adjudicateur rsilie le contrat : 135.Il est plus judicieux pour le pouvoir adjudicateur, dans le cadre dun projet de mutualisation informatique, de recourir la rsiliation, qui ne produit ses effets que pour lavenir et qui ne ncessite pas dintenter une action en justice. La rsiliation, parce quelle est un mode anormal de dissolution dune convention, doit tre lgalement prvue. Larticle 1794 du Code civil dispose que : le matre peut rsilier, par sa seule volont, le march forfait, quoique louvrage soit dj commenc, en ddommageant lentrepreneur de toutes ses dpenses, de tous ses travaux, et de tout ce quil aurait pu gagner dans cette entreprise. Le pouvoir adjudicateur est donc habilit par sa seule volont et mme en dehors de la circonstance de linexcution dune obligation, exiger la rsiliation du contrat. Le ddommagement du prestataire de services peut cependant savrer tre une charge financire trs importante pour ladministration. Les modalits de la rsiliation peuvent tre contractuellement dfinies par le cahier spcial des charges. Le pouvoir adjudicateur peut alors prciser les circonstances dans lesquelles il est habilit requrir la rsiliation. En outre, une diminution des frais de ddommagement de ladjudicataire lors de la dissolution peut tre envisage.
Le cahier spcial des charges de Qualicit contient une clause de rsiliation au profit du pouvoir adjudicateur79 : Sans prjudice de lapplication des mesures doffice fixes par les articles 20 et 75 du Cahier gnral des charges, en cas de manquements graves du prestataire
78
Les articles 1183 et 1184 du C. civ. sont libells en ces termes : 1183 - La condition rsolutoire est celle qui, lorsqu'elle s'accomplit, opre la rvocation de l'obligation, et qui remet les choses au mme tat que si l'obligation n'avait pas exist. Elle ne suspend point l'excution de l'obligation; elle oblige seulement le crancier restituer ce qu'il a reu, dans le cas o l'vnement prvu par la condition arrive. - 1184 - La condition rsolutoire est toujours sous-entendue dans les contrats synallagmatiques, pour le cas o l'une des deux parties ne satisfera point son engagement. Dans ce cas, le contrat n'est point rsolu de plein droit. La partie envers laquelle l'engagement n'a point t excut, a le choix ou de forcer l'autre l'excution de la convention lorsqu'elle est possible ou d'en demander la rsolution avec dommages et intrts. La rsolution doit tre demande en justice, et il peut tre accord au dfendeur un dlai selon les circonstances. 79 Cf. annexe, n II et suiv..
49
dans lexcution de sa mission, le pouvoir adjudicateur se rserve le droit de rsilier le prsent contrat. Cette rsiliation sera prcde dun avertissement par lettre recommande avec accus de rception indiquant les motifs de cette rsiliation. Dans un dlai de quinze jours calendriers partir de la rception de cet avertissement, le prestataire a la possibilit de fournir par crit, sa prise de position sur les manquements qui lui sont reprochs. Au cas o le prestataire ne prendrait pas position ou si celle-ci ntait pas juge satisfaisante par le pouvoir adjudicateur, le contrat pourra tre rsili par lettre recommande avec accus de rception. La rsiliation prendra effet le jour de la rception par le prestataire de la lettre confirmant la rsiliation. Les documents tablis par le prestataire restent acquis au pouvoir adjudicateur pour autant que les honoraires relatifs ces prestations lui aient t pays. Dans le cas contraire, les documents restent la proprit exclusive du prestataire. Au cas o les manquements seraient tablis par toute voie de droit, celui-ci ne pourra prtendre dautres paiements quaux honoraires prvus et correspondant aux prestations rellement accomplies ainsi quaux frais rellement exposs.
136.Lannexe larrt royal du 26 septembre 1996 constitue le cahier gnral des charges applicables aux marchs publics. Ce cahier envisage la possibilit pour le pouvoir adjudicateur de demander la rsiliation, la rvision du contrat et des dommages et intrts dans les circonstances despce o les lenteurs, les carences ou tout autre fait imputable ladjudicataire occasionnent ladministration un retard et/ou un prjudice (article 16, 1)80. Le pouvoir adjudicateur peut en outre rsilier le contrat lors de la survenance dvnements extraordinaires et qui lui sont imprvisibles, lors de la passation du march (article 16, 2)81. Enfin, la rsiliation est encore prvue, de plein droit en cas de dcs de ladjudicataire ou sur demande, dans des circonstances telles que la faillite ou la condamnation pnale du prestataire (article 21)82. Le cahier gnral des charges envisage galement des pnalits, amendes pour retard, mesures doffice, rfaction, compensation et autres sanctions lorsque ladjudicataire est en dfaut dexcution (article 20)83.
A titre dexemple, nous vous proposons une clause du cahier spcial des charges rdig dans le cadre du projet Tabellio84. Cette clause renvoie aux articles du cahier gnral des charges applicables aux marchs publics :
80
Art. 16, 1 du cahier gnral des charges des marchs publics de travaux, de fourniture et de services et des concessions de travaux publics, en annexe de lA.R. du 26 sept. 1996 tablissant les rgles gnrales dexcution des marchs publics et des concessions de travaux publics, M.B., 18 oct. 1996. 81 Art. 16, 2 du cahier gnral des charges des marchs publics de travaux, de fourniture et de services et des concessions de travaux publics. 82 Art. 21 du cahier gnral des charges des marchs publics de travaux, de fourniture et de services et des concessions de travaux publics. 83 Art. 20 du cahier gnral des charges des marchs publics de travaux, de fourniture et de services et des concessions de travaux publics. 84 Cf. annexe, n II et suiv..
50
Si l'adjudicataire ne respecte pas les obligations dcoulant du prsent march, un procs-verbal de constat d'inexcution, motiv et fond, sera tabli conformment l'article 20, paragraphe 2 du Cahier gnral des charges. L'article 20, paragraphe 1er du Cahier gnral des charges est applicable. Ladjudicataire sera en toute hypothse considr en dfaut dexcution si les prestations ne sont pas acheves dans les dlais convenus ou lorsquelles n'auront pas t excutes conformment aux conditions stipules dans la partie "Dispositions techniques" du prsent cahier spcial des charges. Le client pourra, par ailleurs et si ncessaire, recourir des mesures d'office en application de l'article 20, paragraphe 6 du Cahier gnral des charges. Il sera fait application au prsent march des articles 20, 21 et 75 du cahier gnral des charges. Ladministration attire toutefois lattention sur le fait quen cas de manquement de ladjudicataire ses obligations, elle se rserve le droit de suspendre le paiement des ou de ses factures moyennant un crit. Si des carts devaient tre constats et/ou prsums suite des manquements du PCF ou du PFB, il incombera ladjudicataire den informer formellement le client sous peine que ces carts ne soient imputables ladjudicataire sans autre forme de procs. Si des carts importants devaient tre constats et que ladjudicataire ne peut mettre en uvre des actions qui lui permettent de rduire ces carts une dimension acceptable par le client (des carts de plus de 30 % ne sont pas acceptables), le client se rserve le droit de mettre fin au contrat aprs une mise en demeure de deux semaines et les indemnits que pourra rclamer ladjudicataire ne pourront excder 70 % du plus petit des deux montants qui suivent : - montant estim des travaux raliss (estimation ralise sur base de lavancement des travaux suivant indicateur de type EVA ou tout autre indicateur jug pertinent par le client), - montant des frais rellement engags par ladjudicataire (sur base de prsentation de preuves), en ce exclus tous frais de licences. En tout tat de cause, le client restera propritaire des travaux dj raliss. Ladjudicataire devra remettre au client tous les artefacts raliss durant le projet (toute documentation, tudes, procs-verbal de runions, rapports de projets, ). Tous les programmes sources et excutables deviendront la proprit exclusive du PCF et du PFB et ladjudicataire ne pourra en disposer sans laccord crit de ceux-ci. Les modalits dcrites sont valables pour tous les lots et seront excutes sparment. Conformment larticle 21, 4 du Cahier gnral des charges, si ladjudicataire est dclar en faillite, ou sil est mis en liquidation, sans que ce soit une liquidation en vue dune reconstitution ou dune fusion, le client pourra choisir de mettre fin au march sur le champ en le notifiant par crit ladjudicataire ou tout autre personne physique ou morale qui assume lexcution du march.
51
Le client pourra aussi laisser ces personnes la possibilit de continuer excuter le march en garantissant lexcution fidle de ce qui est prvu dans le cahier spcial des charges.
137.Quant savoir si le pouvoir adjudicateur pourra bnficier des rsultats dj raliss en cas de rsiliation, afin, par exemple, de contracter avec un autre prestataire de services qui terminera la programmation du logiciel, il y a lieu de rechercher lintention des parties. Celleci est en effet dterminante pour interprter un contrat lorsque rien nest contractuellement prvu. Nous ne pouvons ds lors que conseiller toute administration denvisager dans le cahier spcial des charges une clause stipulant (dans le meilleur des cas) quen cas de rsiliation du contrat, les droits sur les rsultats dj obtenus sont transfrs au pouvoir adjudicateur. E. Prestations annexes 138.Il peut tre commode que le pouvoir adjudicateur, qui ne dtient pas les comptences humaines ncessaires en interne, require du prestataire de services quil assume les prestations de suivi du logiciel, telle que la maintenance informatique. Dautres hypothses sont envisageables, le pouvoir adjudicateur peut pourvoir lui-mme tout ou partie de ses besoins en terme de maintenance (il sest assur laccs au code source) ou alors il opte pour le recours un prestataire autre que ladjudicataire (ce qui, pour des raisons de facilit, nest pas particulirement recommand, mais permet dchapper aux risques lis la situation monopolistique dans laquelle se trouverait ladjudicataire). 139.Il convient de se soucier du suivi de lapplication informatique ds le stade de la programmation du logiciel. Les prestations annexes, telles que la maintenance corrective ou les formations sur les fonctionnalits de lapplication informatique, sont primordiales pour une utilisation commode du logiciel. Il est ds lors souhaitable de dterminer leur porte et leur objet dans le cahier spcial des charges (en tout cas pour les prestations qui seront assures par ladjudicataire).
Une clause du cahier spcial des charges peut tre stipule de la sorte : A partir de la date dexpiration de la priode de garantie, cest--dire un an aprs la rception dfinitive, ladjudicataire sengage fournir, la demande explicite du client, des services de maintenance volutive, pour une dure minimale dun an. Ces services complmentaires de maintenance feront lobjet dune convention distincte, au forfait ou bordereau de prix. Dans le cas de prestations effectues bordereau de prix, les tarifs pratiqus par ladjudicataire ne pourront diffrer (sauf indexation) de ceux proposs dans son offre pour ce type de prestation [...]. La premire anne de maintenance pourra comprendre galement une assistance technique pour les administrateurs de la solution. Cette assistance technique ne sera pas ncessairement reconduite les annes suivantes. 85
85
La clause suivante est inspire du cahier spcial des charges du Parlement de la Communaut franaise de Belgique et du Parlement francophone bruxellois pour la libralisation de la suite logicielle Tabellio (cf. annexe, n II et suiv.).
52 140.Aucune application informatique nest impermable aux dysfonctionnements et les erreurs se rvlent au fur et mesure de son utilisation. Il est ds lors judicieux dinsrer une clause de garantie dans le cahier spcial des charges. Le prestataire de services assumera la maintenance corrective pour toute la dure de vie du logiciel (ou pour sa dure de vie estime). Les modalits de la garantie son prcises contractuellement : son caractre hypothtiquement gratuit, sa dure, la dfinition de l erreur . 141.Une clause du cahier spcial des charges indique encore que le pouvoir adjudicateur reoit, aprs un temps pralablement dtermin, une nouvelle version du programme. Divers autres services, tels que lassistance tlphonique, la formation ou lenvoi dun technicien peuvent encore tre contractuellement amnags. 142.Dautres prestations annexes, telles que la maintenance volutive (qui implique la modification du programme suite aux besoins volutifs de ladministration) et la maintenance dadaptation (qui ncessite daccommoder le logiciel aux volutions techniques et rglementaires) ne requirent pas spcialement un amnagement dans le cahier spcial des charges. Ces besoins de maintenance sont alatoires et le pouvoir adjudicateur se prserve une plus grande indpendance en se rservant le choix du prestataire. Pour des raisons similaires, il est dconseill de conclure une clause dexclusivit au profit de ladjudicataire pour tous les services de maintenance.
53
Illustration de la troisime hypothse : tableau rcapitulatif

OBJECTIF : ANTICIPER LOUVERTURE DU LOGICIEL Facteurs de russite 1. Identifier les besoins similaires ou complmentaires dautres administrations 2. Sassurer de dtenir les ressources humaines et financires ncessaires pour louverture du logiciel 3. Conclure un contrat de prestation de services qui respecte la lgislation relative aux marchs publics 4. Assurer les droits dutilisation ultrieure sur le logiciel Prcautions particulires
-Rdiger le plus prcisment possible le cahier spcial des charges -Insrer une clause de dsignation des futurs utilisateurs, une clause douverture des droits au profit du pouvoir adjudicateur ou une stipulation pour autrui dans le cahier spcial des charges -Indiquer expressment la cession de tout ou partie des droits patrimoniaux dans le cahier spcial des charges -Insrer une clause de garantie dviction dans le cahier spcial des charges -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts ) -Dterminer prcisment les prestations qui seront assures par le prestataire de services dans le cahier spcial des charges -Obtenir laccs juridique aux codes -Dtenir une documentation approprie (exigences l'origine du dveloppement, documents d'architecture, documents de gestion de projets, document d'aides au dveloppeur, document d'aide l'installation, manuel utilisateur, etc.) -Procder la certification du code -Obtenir les commentaires appropris (astuces de programmation, signification de variables, rle de fonction, etc.) -Dterminer les contours dune ventuelle rsiliation dans le cahier spcial des
6. Dterminer la manire dont seront assures les prestations de maintenance sur le logiciel 7. Sassurer laccs aux codes sources
9. Sassurer de la clart des langages utiliss 10. Dterminer la responsabilit du prestataire de services et prciser les
54 modalits inexcution de sanction pour charges -Prvoir une clause de garantie dans le cahier spcial des charges -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts )
55
Enjeux : dveloppement du logiciel en communaut et anticipation de louverture ventuelle du logiciel dvelopper
4.1/ Figure institutionnelle

143.Le dveloppement, par un prestataire de services, dun logiciel rencontrant les besoins de plusieurs administrations peut tre assur par lintermdiaire dune structure institutionnelle cre par lensemble (ou une partie) de ces administrations ; distincte de celles-ci, cette structure est, par hypothse dote de la personnalit juridique qui lui permettra, notamment, de passer des contrats avec des prestataires de services et, plus gnralement, de passer tout acte juridique contribuant la ralisation de son objet statutaire. Le recours cette figure institutionnelle comme modle de partenariat entre entits publiques appelle quelques observations, tant sur les caractristiques de la structure (4.1.1.) que sur le dveloppement du logiciel linitiative de celle-ci (4.1.2.).
4.1.1/ La structure institutionnelle de mutualisation

I. Avantages et inconvnients de la structure institutionnelle 144.Lanalyse dexpriences de mutualisation fondes, ou non, sur des structures institutionnelles permet didentifier les avantages et inconvnients le plus frquemment perus par les praticiens. A. Avantages 145.La structure, qui a la capacit dengager du personnel et de disposer dun patrimoine, peut, moyen terme, accumuler des ressources humaines et financires propres, lui permettant dassurer la gestion des moyens informatiques dvelopps pour ses membres, en vitant (ou, tout le moins, en limitant sensiblement) les risques que reprsente pour eux une trop forte dpendance lgard de prestataires privs. 146.Dans un environnement administratif, la structuration dun groupement dentits publiques en une institution dote dune identit propre (que caractrisent notamment une personnalit juridique, une vocation prcisment identifie et une proximit aisment traable avec les entits qui la constituent) reprsente de toute vidence un atout en certaines Mutualisation informatique dans le secteur public
56 circonstances ; tel sera notamment le cas, l o ces administrations souhaitent accder au bnfice de programmes daides ou de subventions. 147.Lorsque les pratiques de mutualisation sont censes reposer sur un groupe important dadministrations qui sy impliquent, le recours une entit unique et distincte86 peut reprsenter un important facteur de simplification87 des contacts avec les tiers.
Il est plus facile de faire passer par cette structure qui constituera le seul pouvoir adjudicateur, un march dont toutes les administrations bnficieront, que denvisager la passation dun march conjoint, dans lequel seraient impliques plusieurs dizaines dentits. De mme, laccs certains programmes daides europennes accordes des projets de partenariats entre divers acteurs publics suppose la dsignation, parmi ceux-ci, dun seul interlocuteur ; ce rle serait, en lespce, jou par la structure de mutualisation.
B. Inconvnients 148.La difficult de choisir pour cette structure une forme approprie et des modalits de fonctionnement efficaces peut contraindre mener dimportantes tudes ( caractre juridique ou conomique) pralables qui, apparemment loignes des proccupations propres la mutualisation informatique, risquent de dcourager les initiateurs des projets. 149.La lourdeur des formalits dadhsion ou de dsignation des reprsentants des membres au sein des organes de la structure de mutualisation peut galement constituer un frein. 150.Il en sera, enfin, de mme des contraintes lies lassujettissement certaines lgislations, contraintes qui pourraient tre vites en dehors dune structure de mutualisation.
Ainsi en est-il, propos de lapplicabilit de la lgislation relative aux marchs publics, lorsque le logiciel est dvelopp au sein dune communaut de type Open source dans laquelle des aides utiles pourraient tre trouves par les informaticiens des administrations concernes. Comme cela a toutefois t relev prcdemment88, cette conception ne vaut que pour autant que ces aides soient obtenues gracieusement ; le recours des services prests titre onreux fera invitablement retomber sous le coup de la lgislation relative aux marchs publics, avec ou sans structure institutionnelle89.
86
Ce qui nexclut nullement que les administrations soient fortement impliques dans le fonctionnement de cette structure. 87 En dpit, certes, des difficults que peut reprsenter la cration de la structure (cf. infra, n I et suiv.). 88 Cf. supra, n IV. 89 Sous rserve, une fois encore, de lhypothse dun financement par les deniers personnels des informaticiens contribuant au dveloppement.
57
II. Opportunit du recours une structure institutionnelle de mutualisation 151.De toute vidence, la cration dune structure institutionnelle de mutualisation ne doit pas constituer un objectif en soi ; elle doit davantage reprsenter un moyen permettant la conduite efficace de projets de mutualisation communs un nombre plus ou moins important dadministrations. 152.Limportance des investissements pralables cette cration (choix de la forme et des instruments juridiques, cration dun modle de viabilit conomique,) incite ne la recommander que l o le justifie la taille des pratiques de mutualisation constates ou projetes.
La structure institutionnelle sera particulirement approprie des projets ports par un nombre lev dadministrations, ou qui ont vocation se multiplier 90 ou sinscrire dans la dure. En revanche, un projet ponctuel port par deux administrations peut reposer sur des instruments juridiques plus souples et moins coteux en investissements satellites .
153.Des proccupations lies la prennit des solutions informatiques91 ou la valorisation financire des dveloppements dont louverture de nouveaux utilisateurs est envisage peuvent constituer une motivation suffisante pour la cration dune structure institutionnelle. 154.On notera enfin que la cration dune structure institutionnelle de mutualisation nest pas incompatible avec le recours des pratiques de dveloppement et de diffusion inspires des communauts informelles de lOpen source.
Liberaccs est dsormais fond sur une structure institutionnelle revtant la forme dun G.I.E., tout en assurant la diffusion en Open source de ses outils via une forge accessible sur le site Internet92.
III. Formes envisageables 155.Le caractre gnral du prsent rapport ne permet pas de lui assigner pour objectif une description de toutes les formes de structures institutionnelles envisageables ou la rdaction dun vade mecum qui permette de choisir la forme la plus approprie chaque projet. Comme le rvlent les expriences Liberaccs et Qualicit, le choix dune forme de structure relve de chaque cas despce et sera influenc tant par les exigences du droit commun des socits et associations (n 158) que par les caractristiques de chaque projet de mutualisation (n 159) : 156.Le droit commun des socits et associations peut subordonner le choix de certaines formes de structures des exigences particulires qui, selon les cas, apparatront appropries lintention des initiateurs : constitution dun capital, commercialit des actes, modalits de reprsentation des fondateurs,
90
Perspective de dveloppement dun nombre important de logiciels couvrant lensemble des besoins de toutes les administrations concernes. 91 Laquelle suppose un degr suffisant dindpendance lgard des prestataires de services. 92 Cf. annexe, n II.
58
A. Lassociation sans but lucratif Lassociation sans but lucratif est celle qui ne se livre pas des oprations industrielles ou commerciales et qui ne cherche pas procurer ses membres un gain matriel93. Le recours cette forme dinstitution semble appropri au processus de mutualisation informatique. Toutefois, les rgles suivre lors de la dissolution de la.s.b.l. savrent trs strictes. En effet, les statuts doivent prciser la destination, obligatoirement dsintresse, du patrimoine de linstitution en cas de dissolution94, ce qui exclut une rpartition entre les membres. Ds lors, il serait impossible de prvoir la cession des droits dutilisation sur lapplication informatique au profit des anciens membres en cas de dissolution. Une solution pour chapper la problmatique serait de prvoir des licences dutilisation pour toute la dure des droits de proprit intellectuelle95. En cas de dissolution, les membres conserveraient alors leur licence dutilisation. Encore, afin de prserver les droits des membres en cas de dissolution, le code source peut tre dpos chez un notaire afin de prserver la possibilit damliorer lapplication informatique. Une convention prvoirait que seules les administrations bnficiant de la qualit de membre au jour de la dissolution ont accs au code.
Le projet GILS (Gestion Informatique du Logement Social) a pris la forme dune a.s.b.l.96.
B. Le groupement dintrt conomique Le groupement dintrt conomique est dfini comme une socit qui, constitue par contrat, pour une dure dtermine ou indtermine, entre personnes physiques et morales, a pour but exclusif de faciliter ou de dvelopper lactivit conomique de ses membres, damliorer ou daccrotre les rsultats de cette activit laquelle lactivit du groupement dintrt conomique doit se rattacher et par rapport laquelle elle doit avoir un caractre auxiliaire97. Le g.i.e., de par sa grande souplesse, prsente de nombreux avantages : les frais de fonctionnement sont rpartis parts gales entre les membres (sauf disposition contraire)98 ; les membres sont libres de dterminer des rgles aussi importantes pour la mutualisation que celles concernant la prise de dcision, le montant des apports ou encore les conditions et les consquences dun ventuel retrait. De plus, contrairement la.s.b.l., le partage du patrimoine entre les membres est permis en cas de dissolution.
93
L. du 27 juin 1921 sur les associations sans but lucratif, les associations internationales sans but lucratif et les fondations, M.B., 1er juill. 1921. 94 Art. 2, 9 L. du 27 juin 1921 sur les associations sans but lucratif, les associations internationales sans but lucratif et les fondations. 95 En prenant soin dintgrer dans la licence une condition rsolutoire en cas dexclusion ou de dmission du membre. 96 Cf. annexe, n I. 97 Art. 840, 3 C. soc. 98 Art. 843 C. soc.
59 Par contre, le fait que la responsabilit des administrations est solidaire et illimite pour les engagements souscrits par le groupement, et ce, pendant toute la priode o elles ont la qualit de membre, est particulirement contraignant99. Enfin, les membres du g.i.e. doivent poursuivre une activit conomique. Dans le cadre dune mutualisation informatique dans le secteur public, il est malais de dterminer si les administrations, comme par exemple les communes, poursuivent une telle activit.
Les animateurs des projets Qualicit100 et LiberAccs101 ont opt pour le recours la structure du g.i.e.
C. La socit cooprative La socit cooprative poursuit, comme les autres socits commerciales, un but de lucre. La forme semble premire vue inapproprie un processus de mutualisation dans le secteur public ds lors que les administrations ne recherchent pas le profit102. Le lgislateur belge a toutefois palli au problme en crant les socits finalit sociale dans une loi du 13 avril 1995103. Ces socits empruntent une des formes vises larticle 2 du Code des socits, en ce compris la socit cooprative, sans que lobjet social ne soit lenrichissement des associs. Les rgles de mise en uvre de ces socits sont trs strictes et trs lourdes assumer. Enfin, le point faible principal de la socit cooprative rsulte du fait quelle nest pas auxiliaire des activits de ses membres. Or, le projet de mutualisation informatique sinscrit gnralement dans une perspective auxiliaire des activits des entits publiques. Cette dernire considration rend difficilement compatible la forme institutionnelle de la socit cooprative avec un processus de mutualisation. D. La socit en nom collectif La rgle principale de la socit en nom collectif est la responsabilit solidaire et illimite104 des membres qui la composent, ce qui savre contraignant pour un projet de mutualisation informatique. Mis part cet impratif, le rgime de la socit en nom collectif est presque vierge. Il y a ds lors lieu de recourir aux rgles de droit commun des socits, ce qui apporte lavantage non ngligeable de laisser une grande souplesse aux associs dans lorganisation du fonctionnement de linstitution.
99
Art. 843 C. soc. Cf. annexe, n II. 101 Cf. annexe, n II. 102 Prcisons que le lucre couvre les conomies, telles que dchelle, ce qui permettrait ventuellement de contourner le problme. 103 L. du 13 avril 1995 modifiant les lois sur les socits commerciales, coordonnes le 30 novembre 1935, M.B., 17 juin 1995. 104 Art. 204 C. soc.
100
60 Le problme attach cette forme de socit rsulte du fait quelle ne se veut pas auxiliaire des activits de ses membres. Au-del de cet inconvnient, la socit en nom collectif peut tre une structure intressante pour le projet de mutualisation. E. La socit prive responsabilit limite La SPRL, une socit o les associs nengagent que leur apport et o leurs droits ne sont transmissibles que sous certaines conditions 105, est peu approprie au processus de mutualisation informatique ds lors que les conditions daccs, dexclusion et de retrait des associs sont tablies trs strictement. Or, lon sait que le nombre de membres un projet de mutualisation est en constante fluctuation. F. La socit anonyme Quant la SA, elle est une socit de capitaux qui implique la libre ngociabilit des parts ou actions. Le fait quelle soit une socit de capitaux cadre mal avec un projet de mutualisation. * * * 157.Les considrations qui inspirent les initiateurs du mouvement de mutualisation peuvent galement les inciter exclure ou choisir certaines formes. Ainsi, par exemple, sils souhaitent une reprsentation paritaire de tous les fondateurs au sein des organes de gestion de la structure, et ce indpendamment des apports respectifs lors de la cration, ils excluront une forme qui privilgie une reprsentation proportionnelle ces apports (p. ex. au pro rata des parts de capital). 158. linverse, toutes les caractristiques de la pratique de mutualisation ne doivent pas ncessairement avoir une influence contraignante sur le choix de la forme de structure.
Ainsi, la circonstance quun logiciel dvelopp par plusieurs administrations et diffus suivant les conditions et modalits dune licence Open source puisse tre utilis par des entits relevant de divers Etats et soit ainsi lorigine dune communaut internationale dutilisateurs, nimpose pas, si la ncessit de crer une structure institutionnelle se laisse percevoir, de choisir une forme caractre international (a.i.s.b.l., g.e.i.e., ). Si le but poursuivi au travers de la cration de la structure institutionnelle est de disposer dune entit qui passera les marchs, percevra et centralisera les financements et sera linterlocuteur du groupe auprs dinstances ne souhaitant traiter quavec un interlocuteur reprsentatif, les entits concernes peuvent fort bien saccorder sur lassujettissement de cette structure au droit dun seul Etat, ce qui permettra dviter les difficults et incertitudes naturellement lies aux structures internationales de coopration.
159.Par ailleurs, on ne manquera pas davoir gard au fait que, pour certaines catgories dentits publiques, des lgislations spcifiques conditionnent le choix des formes de regroupement. Tel est particulirement le cas, en Rgion wallonne, des modes de coopration intercommunale. Cette question fait lobjet dune attention plus particulire dans le cadre du rapport consacr la mutualisation informatique dans les pouvoirs locaux.
105
Art. 210 C. soc.
61
IV. Modalits de fonctionnement 160.La latitude dont disposeront les fondateurs de la structure de mutualisation pour dterminer ses modalits de fonctionnement les incitera notamment avoir gard une dfinition des mcanismes de reprsentation et de collaboration des administrations concernes, qui tienne compte tant du caractre public et administratif de la structure (1) que des caractristiques dun projet de mutualisation informatique (2). (1) La proximit de la structure institutionnelle avec les sphres publiques et administratives106 justifie que ses organes soient constitus de reprsentants de ces entits, disposant dun mandat et dune lgitimit cette fin : l o ladministration concerne sidentifie une collectivit politique (une commune, par exemple), il est naturel quun mandataire politique soit dsign cette fin. (2) Cette reprsentation politique nexclut pas qu ct des organes propres la structure (assemble gnrale, conseil dadministration,), soient institus des lieux de collaboration, au niveau desquels seront conduits les projets de mutualisation : des comits techniques ou de pilotage 107 regrouperont ainsi des reprsentants des administrations concernes (ou de celles dentre elles qui acceptent de sengager plus activement dans un projet dtermin 108) ; ces reprsentants seront notamment choisis parmi les informaticiens et les utilisateurs des logiciels dvelopper. Pareille manire de procder permet de tenir compte du double souci dune composition la plus reprsentative des membres au sein des organes de la structure et de la configuration sur mesure de chaque lieu de collaboration associ un projet dtermin. V. Relations entre linstitution et ses membres 161.La relation entre chacune des entits publiques et la structure institutionnelle de mutualisation sera apprhende en termes diffrents, selon quelle a trait leur qualit de membre (A), lutilisation du logiciel dvelopp linitiative de la structure (B) ou la collaboration que chaque entit peut tre amene apporter aux projets ports par la structure (C). Chacun de ces points appelle quelques observations.
106
Proximit qui sexplique par le fait que ces structures sont cres par des entits publiques et contribuent la poursuite dintrt gnral. 107 En se rfrant ici une terminologie frquemment utilise, mais certainement pas exclusive. 108 Sur ce que tous les membres ne doivent pas sengager systmatiquement dans tous les projets, cf. infra, n V.
62
A. Adhsion 162.Selon la forme que revt la structure, ladhsion peut se traduire avant tout par des apports qui constitueront les premires ressources affectes la conduite des projets de mutualisation et la mise en place dune structure viable. Ces contributions peuvent, par exemple, se traduire dans des parts de capital (socit anonyme), dans des apports auxquels ladhsion est soumise (g.i.e.), ainsi que dans des contributions annuelles (cotisation un g.i.e. ou une a.s.b.l.). 163.Ladhsion fera natre des droits et obligations dans le chef des membres ; ces droits seront fixs par les statuts, un rglement dordre intrieur et, le cas chant, un acte dadhsion. Les droits ont trait la participation la vie de la structure et de ses organes ; ils peuvent, le cas chant, se rapporter immdiatement aux projets de mutualisation.
Ladhsion au g.i.e. Qualicit fait natre un droit daccs la documentation relative aux bonnes pratiques administratives109 ; elle conditionne lutilisation des logiciel (sans prjudice des conditions particulires auxquelles une licence dutilisation subordonnera la jouissance de ces droits), ainsi que la participation directe la conduite de projets (suivant les termes de conventions de collaboration tablir) 110. Dans le projet Liberaccs, ladhsion au g.i.e. conditionne la participation active aux projets de mutualisation, mais pas lutilisation des logiciels dvelopps, lesquels sont librement accessibles sur une forge111.
164.Enfin, et de manire plus gnrale, ladhsion une structure institutionnelle de mutualisation permet de constituer une population dentits publiques affichant une proximit suffisante pour partager un ensemble de projets. La structure peut ainsi contribuer la constitution dun observatoire des ressources et besoins informatiques, dont on a soulign, par ailleurs, lintrt pour la prospection de lexistant et des besoins112. B. Utilisation du logiciel 165.La mise disposition dun logiciel dvelopp par (ou linitiative d) une structure de mutualisation fera natre, entre cette structure et lutilisateur, un lien juridique que concrtisera et formalisera la licence dutilisation ; ce lien sera ncessairement tabli, et ce, quelles que soient les conditions et modalits de mise disposition du logiciel : mme un accs libre sur une forge suppose lexistence dune licence Open source. 166.Sans dvelopper ce stade les aspects que recouvre louverture des droits dutilisation 113, on formulera brivement quelques observations sur le lien entre la qualit de membre de la structure et laccs aux logiciels quelle dveloppe :
109
Documentation rsultant elle-mme dune mutualisation (par change et mise en commun) de bonnes pratiques, se traduisant notamment dans la modlisation de processus. 110 Cf. annexe, n II. 111 Cf. annexe, n II 112 Cf. supra, n I et suiv.. 113 Cf. infra, n II et suiv..
63 La qualit de membre de la structure nest pas absolument ncessaire, particulirement si la structure rend publiquement (et gratuitement) accessibles les logiciels. Cette qualit peut toutefois tre vivement recommande, ds lors quelle peut par le lien organique quelle tablit ainsi entre la structure et le membre offrir ce dernier une possibilit de se prvaloir de la thorie des contrats in house, pour recourir aux services de la structure sans devoir procder une mise en concurrence pralable pour le choix du prestataire. Cet avantage sera particulirement apprci lorsquil sagit de solliciter des services annexes la licence dutilisation. Nous reviendrons ultrieurement sur lopportunit du recours la qualification de marchs in house114. On relvera enfin que lobligation dtre titulaire de la qualit de membre peut inciter faire prendre conscience aux utilisateurs de limportance dune implication dans la vie de la structure de mutualisation ; cette implication peut se limiter une contribution financire annuelle dont les utilisateurs percevront lutilit pour la mise en uvre de ressources propres (en personnel, par exemple) qui contribuent garantir, pour lexploitation du logiciel, lindpendance lgard des prestataires de services. C. Collaboration 167.La circonstance que le dveloppement du logiciel soit pilot par une structure institutionnelle formellement distincte des entits qui la composent, nexclut pas que celles-ci prennent une part active dans la conduite des projets ; de leur implication (active ou limite la seule expression de besoins) dpend dailleurs lintrt dun projet et sa viabilit. On ne reviendra plus longuement sur lintrt dune convention de collaboration, dont on a vu quelle est souvent recommande, quel que soit le cas de figure auquel correspond lexprience de mutualisation115. La conclusion dune convention entre la structure et lun (ou plusieurs, de prfrence) de ses membres fera natre entre ceux-ci et celle-l un rapport juridique propre, tranger la qualit de membre116.
114
Sur ces questions lies la qualification de contrat in house et son incidence sur les pratiques de mutualisation, cf. infra, n V et suiv.. 115 Cf. supra, n VII et suiv.. 116 Mme si cette qualit reprsente parfois un pralable ncessaire toute collaboration.
64
4.1.2/ Le dveloppement du logiciel linitiative de la structure institutionnelle de mutualisation
I. Proximit des besoins fonctionnels au stade du dveloppement 168.Il est indispensable, lors de tout processus de mutualisation en amont, de sassurer de la proximit des besoins des diffrentes administrations partenaires.
Le projet GILS (Gestion Informatique du Logement Social) est n du retrait des prestataires de services actifs dans le secteur du logement social. Les socits de logement social se sentent alors abandonnes et se rendent compte de leur dpendance face aux prestataires. Nanmoins, constatant la proximit de leurs besoins actuels, elles dcident de crer GILS afin de dvelopper et de maintenir un logiciel au sein dune structure institutionnelle117. La structure institutionnelle Qualicit est base sur des partenariats existant entre cinq communes wallonnes qui se sont associes suite la prise en considration de la proximit de leurs besoins118.
II. Identification des perspectives douverture ultrieure dautres utilisateurs A. Besoins identiques ou complmentaires 169.Dans une perspective de mutualisation en aval, les entits publiques procdent une rflexion sur les ventuels besoins dautres administrations. Cette analyse sera dautant plus simple, utile et efficace lorsque les entits membres de la structure affichent des profils similaires.
Les logiciels dvelopps par Qualicit ont vocation tre utiliss par des entits publiques autres que les seules administrations participant au projet de dveloppement. Une analyse des besoins similaires des entits susceptibles dtre intresses par le logiciel sera mene pralablement au dveloppement des applications informatiques ; cette dmarche est essentielle pour garantir des chances douverture ultrieure de la communaut dutilisateurs et contribuer ainsi la viabilit (financire, notamment) du projet et de la structure institutionnelle dans laquelle il est pilot119. Quant au projet Liber Accs, il est n du besoin grandissant dune informatisation gnrale des pouvoirs locaux en France. Consciente de cette ncessit, la Communaut dAgglomration de La Rochelle a entam un processus de mutualisation informatique avec dautres Communauts ayant des besoins indiscutablement similaires. Les logiciels dvelopps dans le cadre de ce processus de mutualisation seront distribus terme sous licence libre, ce qui ncessit une
117 118
Cf. annexe, n II. Cf. annexe, n I. 119 Cf. annexe, n I.
65
communaut dutilisateurs importante prsentant ds aujourdhui, des besoins comparables ceux des initiateurs du projet120.
B. Prcautions 170.Toute volont douverture des droits dutilisation sur un logiciel implique la prise en considration de certaines prcautions, pralablement la programmation. Ainsi, les administrations seront attentives disposer dun langage clair et de codes lisibles pour louverture du logiciel. Elles samnageront encore les droits patrimoniaux ncessaires pour la mutualisation en aval. Ces considrations ne sont pas propres la situation du dveloppement dun logiciel par un prestataire de services la demande dadministrations regroupes au sein dune institution distincte, ainsi quon a dj pu lobserver par ailleurs121. 171.Les prcautions prendre, et qui relvent plus particulirement dune structure institutionnelle, portent sur lamnagement des ressources humaines et financires, au stade du dveloppement, mais aussi lors de louverture du logiciel. En outre, la manire dont seront transfrs les droits du prestataire de services linstitution, et puis de linstitution ses membres et mme des non membres, doit faire lobjet dune attention particulire. Enfin, les modalits de collaboration entre les membres doivent ncessairement faire lobjet de conventions claires et prcises122. III. Taille et composition du groupe au stade du dveloppement A. Taille du groupe 172.Lors du lancement dun projet de dveloppement, un nombre limit dintervenants favorisera une conduite optimale des travaux. Ultrieurement, les entits formalisent leur partenariat par la cration dune institution, laquelle sera appele accueillir dautres acteurs.
Les Communauts dagglomration initiatrices du projet LiberAccs ont peru la ncessit de formaliser la collaboration et de lui donner un support durable ; ce support apparat comme une condition ncessaire la mutualisation en aval. Par aprs, une communaut dutilisateurs beaucoup plus large est destine utiliser les applications informatiques puisque celles-ci sont voues tre diffuses en mode libre123.
173.Il se peut galement que le projet de dveloppement soit initi un moment o la structure institutionnelle existe dj. Une taille rduite de lquipe de projet sera galement recommande. Cela nexclut pas quau mme moment, la structure soit ouverte (et continue souvrir) un nombre beaucoup plus lev de membres qui peuvent participer son fonctionnement, sans affecter la conduite dun projet dtermin. Pareil dcalage entre une taille rduite du groupe (ou comit) de projet et le nombre (lev, par hypothse) de membres de la structure peut dailleurs constituer un atout pour la conduite de projets successifs (voire
120 121
Cf. annexe, n I. Cf. supra, n III ; n IV et suiv. ; n II et suiv. ; n III et suiv. ; .III et suiv. ; III et suiv.. 122 Cf. supra, n VII et suiv.. 123 Cf. annexe, n I.
66 simultans) dans lesquels seront impliqus des acteurs diffrents, ce qui (idalement) permet dviter de toujours solliciter la collaboration des mmes membres de la structure.
Dans le cadre du projet Qualicit, la distinction entre la qualit de membre et la participation un projet dans le cadre dune convention de collaboration tmoigne de ce que lquipe de projet ne sera pas ncessairement constitue de lensemble des membres du G.I.E. 124.
B. Composition du groupe 174.Permettre aux utilisateurs de participer la gestion du projet garantit une adquation entre le dveloppement du logiciel et les besoins fonctionnels.
La structure GILS a veill impliquer les utilisateurs au stade du dveloppement du projet. Des groupes de travail au sein desquels sont reprsents ces utilisateurs dterminent les orientations de programmation du logiciel. Des parrains sont dsigns au sein de chaque entit publique afin de soulager les informaticiens de GILS125.
175.On rappellera, par ailleurs, que les compositions respectives des organes de linstitution et des comits de projets doivent tmoigner du souci dassurer une reprsentativit suffisante des informaticiens, des agents utilisateurs, mais galement des mandataires (politiques, le cas chant) des administrations membres de la structure126. IV. Calendrier et gestion du temps 176.On a soulign limportance des dlais de dveloppement lorsque lchance de mise disposition conditionne soit la participation active dune administration un projet de mutualisation en amont, soit, simplement, la perspective dacquisition dune licence dutilisation. 177.Dans lhypothse qui retient lattention en lespce, ces proccupations seront traduites tant dans le cahier spcial des charges (pour faire peser une obligation de rsultat, cet gard, au prestataire de services), que dans la convention de collaboration passe entre la structure et les administrations qui simpliquent activement dans le projet127.
Afin de favoriser la russite des initiatives du groupement Qualicit, une convention de projet dfinit en dtail la planification horaire des participants avant le lancement effectif du processus128.
178.On observera, par ailleurs, que le leadership, assur par lacteur unique quest la structure institutionnelle, constitue probablement un facteur de simplification au regard dautres formules, tel le march conjoint, qui pourraient imposer des processus dcisionnels plus lourds.
124 125
Cf. annexe, n II. Cf. annexe, n I. 126 Cf. supra, n IV. 127 Cf. supra, n VII et suiv. ; n V. 128 Cf. annexe, n II.
67
179.Enfin, la gestion de projets par une structure qui en assure la matrise et, partant, une planification lmentaire permet aux administrations membres dvaluer les chances de disponibilit de logiciels dans des dlais dont elles verront immdiatement sils sont (ou non) manifestement incompatibles avec leurs attentes propres. V. Langage clair 180.Comme il la t expos prcdemment129, disposer dun langage clair et largement utilis est une condition sine qua non de louverture ultrieure dun logiciel.
Pour le dveloppement dune deuxime application informatique dans le cadre du projet GILS, un consultant externe a conseill le recours un nouveau langage. Cette situation a engendr des problmes (difficults dutilisation du logiciel) dus au fait que les administrations ne connaissaient pas ce langage130.
VI. Outillage facilitant la collaboration 181.Il peut tre utile pour les administrations partenaires de disposer doutillages facilitant, dune part les rencontres entre les participants, et dautre part la communication entre les membres de linstitution. Nous renvoyons pour le surplus ce qui t pralablement expos dans lhypothse de dveloppement dun logiciel en interne par plusieurs administrations131. VII. Ressources humaines et financires A. Ressources humaines 182.Lorsque le projet de mutualisation men par la structure institutionnelle implique plusieurs entits membres de celle-ci, il est essentiel de prvoir comment cette collaboration active sera assure, et notamment, selon quelles modalits des agents des administrations membres seront mis disposition de la structure dans le cadre dun projet dtermin 132. Les entits dcident alors de la manire dont chacune dentre elles va affecter une partie de ses ressources humaines au profit de la structure institutionnelle. Cette question peut tre apprhende par le biais dune convention de collaboration 183.Par ailleurs, il sagira galement dexaminer les possibilits de contribution des ressources propres la structure de mutualisation, si celle-ci dispose dun personnel permanent. A cet gard, des choix (en opportunit) devront tre ports propos de limportance de lengagement du personnel de la structure dans la phase de dveloppement, particulirement au regard des tches que ce mme personnel doit assurer dans les phases dexploitation dautres logiciels.
129 130
Cf. supra, n V. Cf. annexe, n I. 131 Cf. supra, n VI et suiv.. 132 Et ce, mme si comme dans le cas despce o il est essentiellement fait appel un prestataire tiers cette mise disposition est relativement peu coteuse en temps.
68
Le logiciel Jrme de GILS a t dvelopp par un prestataire extrieur et par des informaticiens de la structure institutionnelle. Trois informaticiens de GILS ont travaill avec trois consultants extrieurs, qui dirigeaient les oprations133.
Ces valuations de mise disposition de ressources humaines contribueront dfinir, par ailleurs, les tches qui incomberont au prestataire de services au titre du cahier spcial des charges. B. Ressources financires 184.Un projet de mutualisation qui sinscrit dans le cadre dune structure institutionnelle a naturellement (et par hypothse) vocation sinscrire dans la dure. Il y a donc lieu dassurer la viabilit financire du projet en dterminant les contributions respectives des partenaires publics actuels et futurs. Cet amnagement des ressources financires nest pas ais, comme le dmontrent les cas pratiques : Une possibilit de financement du projet est de prvoir une contribution des entits lors de leur adhsion linstitution et, par la suite, chances prcises.
Ce cas de figure est utilis par la structure Qualicit : chaque nouveau membre est tenu de verser un apport financier au groupement lors de son adhsion ; tout membre sacquitte dune cotisation annuelle134.
185.En outre, les administrations intresses par un projet particulier (telle que la programmation dune application informatique) sengagent verser des contributions supplmentaires lors du lancement du projet, au cours de sa ralisation et lors de sa concrtisation135. Ce mode de financement exige que les projets ne reposent pas toujours sur les mmes entits, tandis que dautres nassureraient jamais la charge de tels investissements. 186.Les administrations sont encore attentives au fait que lorsque les cots sont diviss entre les partenaires publics selon des cls de rpartition, par exemple sur le nombre de postes de travail, le dpart dune grosse entit fragilise le systme puisque les apports respectifs des partenaires sont dsquilibrs.
Le projet GILS est, quant lui, financ par les entits publiques de manire ce que les petites socits de logement social soient informatises un cot raisonnable. Ainsi, 15% des cots sont rpartis de manire gale et le surplus est divis en fonction dune cl de rpartition sur le nombre de postes de travail et de logements sociaux grs. Les nouveaux membres doivent en outre payer un droit dentre136.
VIII. Contrat de louage douvrage : applicabilit de la lgislation relative aux marchs publics
133 134
Cf. annexe, n I. Cf. annexe, n I. 135 Cf., ce propos, les dveloppements consacrs au projet Qualicit, annexe, n I. 136 Cf. annexe, n I.
69
A. Application de la lgislation relative aux marchs publics 187.Dans le cas de figure en cause, les partenaires publics, par le biais de linstitution, ont recours un ou plusieurs prestataire(s) extrieur(s) pour la ralisation et ventuellement le suivi du logiciel. Ds lors, un march public doit tre conclu entre les prestataires et linstitution qui assume le rle de pouvoir adjudicateur. Ds lors que cette structure de mutualisation est dote de la personnalit juridique, est cre (et contrle) par des entits publiques137 et poursuit une fin dintrt gnral, elle se voit reconnatre la qualit de pouvoir adjudicateur et sera donc soumise au respect de la lgislation relative aux marchs publics, pour les commandes quelle passe au bnfice conomique de ces entits membres.
Ainsi, la.s.b.l. GILS a conclu un march avec des consultants extrieurs. Lapplication informatique Jrme est dveloppe par les soins dun prestataire externe travaillant en troite collaboration avec les informaticiens de GILS138. Dans le cadre des projets Qualicit et LiberAccs, les logiciels sont programms par les soins de prestataires de services choisis dans le cadre de marchs publics passs par la structure de mutualisation. Les gestionnaires du projet LiberAccs favorisent cependant (et logiquement) le recours des applications informatiques existantes si celles-ci correspondent leurs besoins139.
B. Clauses du cahier spcial des charges 188.Dans un objectif douverture des droits sur le logiciel, ladministration prend soin de rdiger le cahier spcial des charges de la manire la plus prcise possible afin dviter toute inscurit juridique. 189.Linstitution est en outre particulirement attentive la rdaction de certaines clauses, fondamentales pour un processus de mutualisation en aval : - Les clauses douverture de lutilisation du logiciel (stipulation pour autrui au profit des membres de linstitution, possibilit de dsignation des futurs utilisateurs de lapplication par le pouvoir adjudicateur) ; ces clauses revtent une importance particulire, ds lors quen lespce le pouvoir adjudicateur ( savoir la structure de mutualisation) nest, en quelque sorte, pas le vritable bnficiaire conomique des prestations de dveloppement du logiciel. - Les clauses damnagement des droits patrimoniaux sur lapplication informatique (garantie dviction, droit exclusif du pouvoir adjudicateur de dcider de lutilisation ultrieure des rsultats, impossibilit pour le prestataire de publier les rsultats sans autorisation du pouvoir adjudicateur).
- A cet gard, la convention entre GILS et le prestataire extrieur prvoyait un partage des droits entre linstitution et le fournisseur de services. Cette rpartition
137 138
Ayant elles-mmes la qualit de pouvoir adjudicateur. Cf. annexe, n I. 139 Cf. annexe, n I.
70
ne sest pas rvle problmatique ds lors que chacune des parties est habilite exploiter librement le logiciel140. - Dans lhypothse dun processus de mutualisation institutionnel, une disposition du cahier spcial des charges prcise comment seront utiliss les rsultats et la porte des droits dutilisation : Seul le pouvoir adjudicateur est habilit dcider de lutilisation ultrieure des rsultats et dsigner les bnficiaires ainsi que la porte des droits dutilisation de lapplication informatique ralise et fournie par ladjudicataire. Le pouvoir adjudicateur se rserve le droit dexploiter et de rutiliser les rsultats toutes fins utiles, dans le cadre de son objet statutaire, et sous quelque forme ou support que ce soit, au bnfice des membres ou anciens membres. En cas de dissolution de linstitution, tous les droits concernant lutilisation des rsultats seront transfrs immdiatement aux anciens membres. Ceux-ci pourront traiter chacun directement avec ladjudicataire, notamment si un nouveau contrat (concernant, par exemple, la mise jour de lapplication informatique), doit tre conclu par la suite. Si la dissolution survient avant le paiement du travail fourni par ladjudicataire, les anciens membres de linstitution seront tenus de payer ladjudicataire conformment au prsent contrat. La modification des statuts du pouvoir adjudicateur ninflue pas sur les droits dutilisation de lapplication informatique accords par le pouvoir adjudicateur ses membres ou anciens membres.
- Les clauses dterminant la responsabilit des parties (responsabilit alourdie du prestataire de services en cas de dfaillance du systme) ; - Les clauses de dissolution du contrat en cas dinsatisfaction des services du prestataire (rsolution et rsiliation de la convention) ; - Les clauses techniques garantissant la lisibilit du code. En effet, le code source est un lment dterminant pour lvolution du projet. Il faut donc sassurer que celui-ci puisse facilement tre adapt aux dveloppements survenant dans le cadre du projet de mutualisation. Pour cela, sa lisibilit doit tre excellente ;
Le recours un prestataire de certification peut tre relevant cet gard. Le logiciel Jrme 1 , dvelopp dans le cadre du projet GILS, a prsent des faiblesses quant la stabilit du code lorsque des adaptations, dues au changement de rglementation dans le secteur social, sont devenues ncessaires141.
- Les clauses amnageant le transfert de la documentation (manuels dexplication du systme de codage, copie du code source) ; - Les clauses assurant le suivi de lutilisation du logiciel (maintenance corrective, volutive, dadaptation, nouvelles versions de lapplication, formation, assistance techniques).
140 141
Cf. annexe, n II. Cf. annexe, n I.
71 Les clauses du cahier spcial des charges ont fait lobjet de nos commentaires pralables lors de lanalyse de lhypothse o un logiciel est dvelopp par un prestataire de services la demande dune seule administration142.
4.2/ Figure contractuelle

I. Proximit des besoins fonctionnels au stade du dveloppement 190.De manire gnrale, la proximit des besoins des entits publiques dsireuses de se lancer dans un processus de mutualisation en amont est un lment cl de la russite du projet143.
Dans le cadre du projet e-catalogue, un logiciel de gestion dun catalogue lectronique de fournitures courantes devait tre dvelopp. A terme, ce logiciel devait rpondre aux besoins dun trs grand nombre dutilisateurs, savoir toutes les entits publiques agissant dans le cadre dun march public (cest--dire les pouvoirs adjudicateurs) dans les Etats membres de lUnion europenne. La similarit des droits et pratiques dachat public dans les diffrents Etats membres a rapidement conduit lidentification de besoins similaires pour les diffrentes entits publiques la base du processus (mutualisation en amont) et potentiellement utilisatrices (mutualisation en aval) 144. Les deux assembles parlementaires lorigine du projet Tabellio ont procd des tudes pralables tendant dcrire leurs profils et modalits de fonctionnement, ce qui a en outre permis de dgager la proximit de leurs besoins fonctionnels145.
II. Identification des perspectives douverture ultrieure dautres utilisateurs A. Besoins identiques ou complmentaires 191.Il nest nanmoins pas toujours ais de dterminer, ds le stade du dveloppement dune application informatique, les besoins dentits publiques potentiellement intresses par un projet de mutualisation. Il peut tre judicieux de dfinir de manire large et souple les objectifs de la mutualisation afin de rencontrer les besoins fonctionnels dun large groupe dutilisateurs.
Les entits initiatrices du projet Tabellio, aprs avoir identifi des besoins similaires dans le chef dautres administrations, ont opt pour des modalits de dveloppement flexibles permettant denvisager louverture des droits dautres assembles prsentant des diffrences, de type par exemple institutionnel, non ngligeables146.
142 143
Cf. supra, n III et suiv.. Cf. supra, n I. 144 Cf. annexe, n I. 145 Cf. annexe, n I. 146 Cf. annexe, n I.
72
Dans le cadre du projet e-catalogue, lidentification de besoins exprims par des utilisateurs potentiels tait dautant plus aise que le logiciel permettait la dmatrialisation de procdures (de gestion de marchs) fondes sur un cadre normatif commun lensemble des pouvoirs adjudicateurs de tous les Etatsmembres de lUnion europenne. Ce cadre commun, gnrateur de pratiques ncessairement proches les unes des autres, sest videmment rvl tre un lment favorable lidentification de perspectives douverture147.
B. Prcautions 192.En vue de rendre possible louverture des droits dutilisation dautres entits qui ne sont pas initiatrices du processus, les administrations partenaires seront attentives : Disposer dun langage clair pour louverture du logiciel148 ; Disposer dun code source lisible pour louverture du logiciel149 ; Disposer des ressources humaines et financires pour louverture du logiciel ; Se garantir une large panoplie de droits dauteur sur lapplication informatique150 ; Rdiger les clauses du cahier spcial des charges en tenant compte de louverture du logiciel (les clauses de dsignation des utilisateurs, les clauses de dissolution du contrat en cas dinsatisfaction des services du prestataire, les clauses amnageant le transfert de la documentation, les clauses assurant le suivi de lutilisation du logiciel)151. III. Taille et composition du groupe au stade du dveloppement 193.Un nombre trop important dinitiateurs au projet de mutualisation peut se rvler contraignant et compliquer la mise en place dun plan daction prcis152 .
Ainsi, dans le projet e-catalogue, dont le logiciel tait destin tre utilis par un trs grand nombre dutilisateurs, seulement deux administrations (lune, belge et lautre, franaise) relevant dEtats diffrents et partant soumises des rgimes juridiques et administratifs diffrents, ont gr le lancement du processus. Mme dans ce cas, la diffrence entre les deux systmes a contraint renoncer une mutualisation en amont, le logiciel ntant finalement dvelopp que par un des deux partenaires, qui sest toutefois montr attentif la possibilit dune ouverture ultrieure des droits dutilisation153.
194.Par ailleurs, permettre aux utilisateurs de participer la gestion du projet garantit une adquation entre le dveloppement du logiciel et les besoins fonctionnels154.
147 148
Cf. annexe, n I. Cf. supra, n V. 149 Cf. supra, n IV et suiv.. 150 Cf. supra, n III. 151 Cf. supra, n III et suiv.. 152 Cf. supra, n et suiv.. 153 Cf. annexe, n VI et suiv.. 154 Cf. supra, n et suiv..
73 IV. Calendrier et gestion du temps 195.Limportance de ltablissement dun calendrier, tant pour valuer le dlai de concrtisation du projet que pour dterminer le rythme de travail, a t souligne prcdemment et se pose en des termes similaires dans lhypothse actuellement envisage. Le calendrier sera fix conventionnellement. Ce calendrier doit, le cas chant, tenir compte dlments qui, trangers au dveloppement stricto sensu, conditionnent malgr tout lvolution du projet, telles les tudes pralables, portant sur la dfinition des besoins fonctionnels ou sur la rsolution des problmes juridiques et/ou conomiques lis la conduite gnrale du processus de mutualisation.
Au cours de la ralisation du projet e-Catalogue, de nombreuses questions inhrentes tout projet de mutualisation suscitaient un examen approfondi qui ne pouvait cependant tre envisag dans les limites du calendrier budgtaire impos155.
196.On ajoutera que lorsque, comme cest le cas en lespce, le dveloppement du logiciel doit reposer sur lintervention dun prestataire dans le cadre dun march public de services, le dlai apparatra galement comme une des conditions essentielles de lexcution du march ; il en sera donc ncessairement tenu compte lors de la rdaction du cahier spcial des charges. V. Ressources humaines et financires ncessaires pour le dveloppement et louverture du logiciel 197.Ainsi quon la relev par ailleurs, laffectation des ressources humaines et financires doit tre envisage ds le stade du lancement du projet de mutualisation. Il est recommand de rgler ces aspects par le biais de clauses appropries dans le cahier spcial des charges, lesquelles peuvent ne pas tre incompatibles avec la souplesse quexigeraient certaines questions ne pouvant ce stade tre prcisment rsolues. Cette valuation des ressources mettre disposition (particulirement en personnel) reposera sur divers critres, tels la taille, le budget, les besoins, les disponibilits des administrations, ainsi que les phases du projet (dacquisition, de dveloppement, dexploitation, de maintenance).
Au cours du projet e-Catalogue, laffectation des ressources humaines a retenu lattention tant pour la phase dacquisition du logiciel que pour celle de son exploitation ; la prise en charge financire du dveloppement du logiciel (et de services auxiliaires) doit galement tre envisage tant pour linvestissement initial (par les deux administrations) que pour une couverture partielle de cet investissement par les contributions de nouveaux utilisateurs. La difficult de dterminer les parts respectives des deux entits concernes a constitu lun des obstacles la conduite du projet ( tout le moins en tant quil sinscrivait dans un schma de mutualisation en amont) 156.
198.Dans lvaluation des ressources ncessaires, il faudra tenir compte de ce quen lespce et la diffrence de ce qui a pu tre observ par ailleurs 157, le dveloppement du logiciel repose principalement sur lintervention du prestataire de services, les agents des
155 156
Cf. annexe, n I. Cf. annexe, n I. 157 Cf. la deuxime hypothse Dveloppement par une communaut de dveloppeurs-utilisateurs, informaticiens des administrations concernes .
74 administrations concernes tant davantage appels intervenir dans laccompagnement du march (prparation, suivi, ). Cette donne pourra influencer la part proportionnelle de charges financires et de personnel ; sagissant de ces dernires, la proportion dinformaticiens158 affects ces tches sera probablement moins importante que dans les cas o ils sont appels assurer eux-mmes le dveloppement. VI. Outillage facilitant la collaboration 199.On a relev plusieurs reprises que les outillages facilitant les rencontres entre les membres et amliorant la communication entre ceux-ci sont certainement utiles au processus de mutualisation159 . VII. Amnagement dun leadership dans la convention de collaboration 200.Les questions relatives lamnagement dun leadership du projet ont t examines par ailleurs160. On se rfrera utilement aux dveloppements qui y ont t consacrs ; ils gardent leur pertinence dans le cadre de lhypothse actuellement examine. VIII. Contrat de louage douvrage : applicabilit de la lgislation relative aux marchs publics A. March pass par une seule administration 1)Une seule administration assume le rle de pouvoir adjudicateur : 201.Une des administrations impliques dans le projet assume seule le rle de pouvoir adjudicateur dans le cadre dun march public, dont il est entendu quil sera pass au profit conomique des autres partenaires publics. 202.Cette problmatique est propre tout contrat de service pass avec un prestataire extrieur tombant sous le champ dapplication de la lgislation relative aux marchs publics et pourrait concerner, outre le contrat de dveloppement du logiciel, les contrats de maintenance et de certification du code source. 203.Le cahier spcial des charges labor par (et sous la responsabilit de) ce pouvoir adjudicateur contiendra les clauses appropries la perspective doctroi, en faveur des administrations partenaires, du bnfice de droits patrimoniaux identiques ceux que le prestataire cde au pouvoir adjudicateur. Ainsi, il a t prcis que le pouvoir adjudicateur sassure que dautres entits pourront utiliser le logiciel lorsque celui-ci est dvelopp la demande dune seule administration161. De manire similaire, dans notre hypothse (o le logiciel est dvelopp pour plusieurs administrations), le pouvoir adjudicateur est attentif ce
158 159
Ou la part de temps consacre par chacun deux. Cf. supra, n VI et suiv.. 160 Cf. supra, n V et suiv.. 161 Cf. supra, n III et suiv..
75 que dautres administrations soient habilites, non seulement utiliser lapplication, mais en outre bnficier des mmes droits patrimoniaux que ceux qui lui sont transfrs par ladjudicataire. 2)Lamnagement des droits patrimoniaux entre le pouvoir adjudicateur et les autres entits publiques est organis par la convention de collaboration : 204.La rdaction dune convention de collaboration savre indispensable. Deux questions essentielles concernant les droits respectifs des parties doivent tre rgles par le biais de la convention : Le pouvoir adjudicateur bnficiera des droits sur le logiciel. Quels sont les droits quil cdera ventuellement aux autres partenaires ? Quels partenaires seront habilits dsigner ultrieurement les nouveaux utilisateurs de lapplication informatique ? Uniquement le pouvoir adjudicateur ? B. March conjoint 1)Plusieurs administrations assument le rle de pouvoir adjudicateur : 205.Le recours un march conjoint peut tre envisag pour le dveloppement dun logiciel lorsque le projet de mutualisation est initi par plusieurs pouvoirs adjudicateurs en dehors dune structure de mutualisation distincte. Larticle 19 de la loi du 24 dcembre 1993, relative aux marchs publics162 , dispose que Lexcution conjointe de travaux, de fournitures ou de services pour le compte de pouvoirs adjudicateurs diffrents peut, dans lintrt gnral, faire lobjet dun march unique attribu par adjudication, par appel doffres ou par procdure ngocie, dans les conditions dtermines par la loi. Les personnes intresses dsignent lautorit ou lorgane qui interviendra, en leur nom collectif, lattribution et lexcution du march. La nouvelle loi relative aux marchs publics163 prcise, quant elle, que en cas de march conjoint pour le compte de pouvoirs adjudicateurs diffrents et, le cas chant, de personnes de droit priv, les personnes intresses dsignent lautorit ou lorgane qui interviendra, en leur nom collectif, en qualit de pouvoir adjudicateur. Les conditions du march peuvent prvoir un paiement spar pour chacune de ces personnes. 206.La technique du march conjoint est peu utilise dans la pratique, ce qui est probablement d au fait que les dispositions lgislatives la dcrivant restent lacunaires. Nonobstant le fait quil soit mconnu, le systme prsente certains avantages, comme en tmoigne la possibilit laisse aux pouvoirs adjudicateurs de prvoir un paiement spar.
162
L. du 24 dc. 1993 relative aux marchs publics et certains marchs de travaux, de fourniture et de services, M.B., 22 janv. 1994. 163 L. du 15 juin 2006 relative aux marchs publics et certains marchs de travaux, de fourniture et de services, M.B., 15 fvr. 2007.
76
Lors du droulement du projet portail des marchs publics , la Rgion wallonne et la Communaut franaise ont, dans un premier temps, pens recourir la technique du march conjoint. Cependant, la procdure tant trs peu connue lheure actuelle, les administrations ont prfr recourir momentanment la solution plus scuritaire du march unique, nimpliquant quun seul pouvoir adjudicateur164.
207.La circonstance quun seul pouvoir adjudicateur soit mandat par les autres pour les reprsenter dans les diffrents actes affrents la passation et lexcution du march nexclut pas que ces mandants participent aux processus de prise de dcisions, en collaborant, par exemple, llaboration et la rdaction du cahier spcial des charges, lanalyse des candidatures et des offres ou encore aux travaux des structures daccompagnement, qui conditionneront les dcisions dapprobation des prestations effectues. En fait, les modalits dorganisation du march, en tant quelles touchent limplication des diffrentes entits publiques165, doivent tre conventionnellement arrtes par les diffrents pouvoirs adjudicateurs. Elles seront, le cas chant mais pas ncessairement, intgres dans la convention de collaboration. Elles peuvent galement faire lobjet dune convention distincte ne rgissant que ce seul objet. 208.Par ailleurs, les droits patrimoniaux sur le logiciel sont en principe cds automatiquement tous les pouvoirs adjudicateurs (du reste prsents comme tels dans le cahier spcial des charges et les avis de march) qui en deviennent ainsi co-titulaires, puisque le march est pass pour leurs comptes respectifs. Afin dviter toute incertitude, les clauses relatives ces droits patrimoniaux en feront explicitement tat. 2)La gestion des droits patrimoniaux cds par le prestataire est rgie par la convention de collaboration : 209.Ds lors que les pouvoirs adjudicateurs sont co-titulaires des droits, ils se trouvent dans une situation dindivision quil leur convient damnager. En raisonnant par analogie, lon peut appliquer cette situation larticle 4 de la loi relative au droit dauteur et aux droits voisins166 et qui ne vise normalement que les situations dindivision de droits entre les auteurs, personnes physiques ayant cr luvre. La disposition prvoit que lorsque le droit dauteur est indivis, son exercice devra tre rgl par des conventions. Si tel nest pas le cas, aucun des auteurs ne pourra lexercer isolment. Les Cours et tribunaux sont amens se prononcer en cas de dsaccord. Lon peut ds lors estimer que les pouvoirs adjudicateurs, mme si ils ne sont pas les auteurs originaires de luvre, doivent prvoir expressment dans une convention de collaboration que chacun sera habilit dsigner dautres utilisateurs. Si tel nest pas le cas, toute dsignation dun nouvel utilisateur ne se fera que de commun accord des pouvoirs adjudicateurs, faute de quoi les Cours et tribunaux seront amens trancher. IX. Mode de diffusion de lapplication informatique 210.Les administrations sont vigilantes, ds le stade de lancement du processus, la manire dont sera distribue lapplication informatique : en mode libre ou en mode propritaire.
164 165
Cf. annexe, n I. A savoir, par exemple, leur participation aux diverses phases prcites, ainsi que les modalits de paiement. 166 L. du 30 juin 1994 relative au droit dauteur et aux droits voisins.
77
Ainsi, le projet e-Catalogue prvoyait le dveloppement dun logiciel vou tre distribu dans le cadre dune licence Open source, garantissant de la sorte la perspective dune mutualisation en aval167.
211.Un logiciel distribu sous mode libre garantit une trs large diffusion de lapplication. Par contre, lorsque les administrations envisagent de requrir une rtribution financire des nouveaux utilisateurs en contrepartie dune licence dutilisation, elles optent pour la diffusion du programme en mode propritaire. En effet, si la logique est celle de l'obtention d'une rmunration en contrepartie de la licence dutilisation, cela conduit d'office une orientation propritaire168. Les diffrentes modalits de la diffusion dun programme feront lobjet de nos proccupations dans la deuxime partie de ltude ( la solution existe dj ) 169.
X. Convention de collaboration : traduction juridique de la mthodologie et importance de saccorder sur les modalits de la collaboration 212.Lopportunit de rencontrer les contraintes daction inhrentes au partenariat dans une convention de collaboration a t voque prcdemment170 ; les caractristiques de ces contrats et les clauses quils sont susceptibles de contenir ont galement t suggres. Les considrations qui ont alors t mises restent pertinentes dans le cas despce et on sy rfrera. Tel est, par exemple, le cas de ce qui a t expos propos de la possibilit de conclure plusieurs conventions successives, affichant chacune des degrs de contrainte et de prcision variables171.
Dans le projet e-Catalogue, les parties ont opt pour la rdaction de deux contrats, le premier plus gnral devait tre sign par les autorits politiques des entits concernes et le deuxime, plus spcifique et contraignant, devait tre conclu entre les services administratifs172.
213.En complment de ce qui a dj t expos, on formulera les deux observations suivantes : - Dans lhypothse actuellement examine, lun des points qui devra tre rgl par le biais de la convention de collaboration concerne les modalits de passation des marchs publics lis au projet de mutualisation (choix dun pouvoir adjudicateur unique, march conjoint, )173. Les modalits de passation et dexcution dun march conjoint pourront tre dfinies ds le dpart dans la convention gnrale de collaboration ou faire lobjet dune convention spcifique ;
167 168
Cf. annexe, n II et suiv.. Cf. supra, n VI et suiv.. 169 Cf. infra, n I et suiv.. 170 Cf. supra, nVII et suiv.. 171 Cf. supra, n VII. 172 Cf. annexe, n II. 173 Cf. supra, n VIII et suiv.
78 - Limportance que sont censs revtir les marchs publics dans cette hypothse conditionnera la manire dont les charges financires et en personnel seront values, quantitativement (volume de travail) et qualitativement (choix des comptences appropries).
79
Illustration de la quatrime hypothse : tableau rcapitulatif

OBJECTIFS : DEVELOPPER LE LOGICIEL ET ANTICIPER SON OUVERTURE
Figure institutionnelle de mutualisation

Facteurs de russite 1. Analyser lopportunit du recours une structure institutionnelle 2. Dterminer la forme de la structure la plus adapte au projet 3. Prvoir les modalits de fonctionnement 4. Prvoir une collaboration convention de Prcautions particulires
-Dterminer les reprsentants des organes politiques concerns -Cration de comits technique ou de pilotage -Dterminer les modalits dadhsion et de retrait des membres -Dterminer la manire dobtenir un droit dutilisation sur le logiciel
5. Ncessit de besoins fonctionnels proches entre les administrations 6. Identifier les besoins similaires ou complmentaires dautres administrations 7. Sassurer que la taille et la composition du groupe sont adaptes au projet
-Favoriser une taille modre du groupe au stade du dveloppement -Dterminer la composition du groupe en fonction de la situation (impliquer les utilisateurs, mettre en place un comit de pilotage etc.)
8. Dfinir prcisment le calendrier de travail 9. Sassurer de la clart des langages utiliss 10. Prvoir des outillages favorisant la collaboration 11. Sassurer de dtenir les ressources humaines et financires ncessaires pour le dveloppement, le suivi et ouverture du logiciel 12. Assurer les droits dutilisation ultrieure sur le logiciel
-Dterminer une mthode de travail et prvoir des outils de collaboration
-Insrer une clause de dsignation des futurs utilisateurs, une clause douverture
80 des droits au profit du pouvoir adjudicateur ou une stipulation pour autrui dans le cahier spcial des charges -Indiquer expressment la cession de tout ou partie des droits patrimoniaux dans le cahier spcial des charges -Insrer une clause de garantie dviction dans le cahier spcial des charges -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts ) -Dterminer prcisment les prestations qui seront assures par le prestataire de services dans le cahier spcial des charges -Obtenir laccs juridique aux codes -Dtenir une documentation approprie (exigences l'origine du dveloppement, documents d'architecture, documents de gestion de projets, document d'aides au dveloppeur, document d'aide l'installation, manuel utilisateur, etc.) -Procder la certification du code -Obtenir les commentaires appropris (astuces de programmation, signification de variables, rle de fonction, etc.) -Dterminer les contours dune ventuelle rsiliation dans le cahier spcial des charges -Prvoir une clause de garantie dans le cahier spcial des charges -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts )
17. Sassurer de la clart des langages utiliss 18. Dterminer la responsabilit du prestataire de services et prciser les modalits de sanction pour inexcution 19. Identifier le mode de diffusion et sassurer de sa faisabilit
Figure contractuelle de mutualisation

Facteurs de russite 1. Ncessit de besoins fonctionnels proches entre les administrations 2. Identifier les besoins similaires ou complmentaires dautres administrations 3. Sassurer que la taille et la composition du groupe sont adaptes au processus de dveloppement Prcautions particulires
-Favoriser une taille modre du groupe au stade du dveloppement -Dterminer la composition du groupe en fonction de la situation (impliquer les
81 utilisateurs, mettre en place un comit de pilotage etc.) 4. Dfinir prcisment le calendrier de travail 5. Sassurer de la clart des langages utiliss 6. Prvoir des outillages favorisant la collaboration 7. Sassurer de dtenir les ressources humaines et financires ncessaires pour le dveloppement, le suivi et ouverture du logiciel 8. Organiser le leadership 9. Sassurer la cession des droits de la proprit intellectuelle sur le logiciel au profit du ou des pouvoirs adjudicateurs
-Dterminer une mthode de travail et prvoir des outils de collaboration
10. Assurer les droits dutilisation ultrieure sur le logiciel
14. Dterminer la responsabilit prestataire de services
du
-Crer une structure de pilotage -Dsigner un animateur de projet -Indiquer expressment la cession de tout ou partie des droits patrimoniaux dans le cahier spcial des charges -Insrer une clause de garantie dviction dans le cahier spcial des charges -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts ) -Insrer une clause de dsignation des futurs utilisateurs, une clause douverture des droits au profit du ou des pouvoir(s) adjudicateur(s) ou une stipulation pour autrui dans le cahier spcial des charges -Dterminer prcisment les prestations qui seront assures par le prestataire de services dans le cahier spcial des charges -Obtenir laccs juridique aux codes -Dtenir une documentation approprie (exigences l'origine du dveloppement, documents d'architecture, documents de gestion de projets, document d'aides au dveloppeur, document d'aide l'installation, manuel utilisateur, etc.) -Procder la certification du code -Obtenir les commentaires appropris (astuces de programmation, signification de variables, rle de fonction, etc.) -Dterminer les contours dune ventuelle rsiliation dans le cahier spcial des charges -Prvoir une clause de garantie dans le cahier spcial des charges -Faire attention aux licences des composants logiciels utiliss (p. ex. aux lments dits copylefts )
82 16. Rdiger une collaboration convention de -Dterminer laffectation des ressources humaines et/ou financires, la dfinition des objectifs et dun calendrier commun, lamnagement des droits patrimoniaux, les modalits de passation des marchs publics lis au projet de mutualisation (choix dun pouvoir adjudicateur unique, march conjoint) etc.
Illustration des quatre premires hypothses : tableau synoptique

Facteurs de russite Identifier les besoins similaires complmentaires dautres administrations ou Hypothse n 1 x Hypoths e n 2 x x x x x x x x x x x Hypoths e n 3 x Hypothse n 4 4.1 4.2 x x x x x x x x x x x
Ncessit de besoins fonctionnels proches entre les administrations Sassurer que la taille et la composition du groupe sont adaptes au projet Dfinir prcisment le calendrier de travail Organiser le leadership Prvoir des outillages favorisant la collaboration Sassurer de dtenir les ressources humaines et/ ou financires ncessaires pour le dveloppement, le suivi et/ou louverture du logiciel Sassurer laccs aux codes sources Sassurer de la lisibilit du code Sassurer de la clart des langages utiliss Identifier le mode de diffusion et sassurer de sa faisabilit Sassurer la cession des droits de la proprit intellectuelle sur le logiciel son profit Rdiger une convention de collaboration Assurer les droits dutilisation ultrieure sur le logiciel Dterminer la manire dont seront assures les prestations de maintenance sur le logiciel Dterminer la responsabilit du prestataire de services Analyser lopportunit du recours une structure institutionnelle Dterminer la forme de la structure la plus adapte au projet Prvoir les modalits de fonctionnement de la structure
x x x x x
x x x x x x
x x x x x
x x x x x x
x x x x x x x x
x x
x x
x x x x
La solution existe - Comment en profiter ?
214.La situation envisage est celle o une ou plusieurs administration(s), , titulaire(s) des droits patrimoniaux sur une application informatique dveloppe en interne ou par un prestataire extrieur174, octroie(nt) une licence dutilisation dautres entits publiques dans un objectif de mutualisation en aval. Cette hypothse suppose, par ailleurs, que la solution informatique soit dtenue par un pouvoir public ; sinon, il existe un risque de mutualisation par loffre .
174
Cf. les quatre hypothses examines dans la premire partie.
85
1. Qualification du contrat de licence

I. Dfinition de la licence dutilisation 215.La licence dutilisation dun logiciel est un contrat par lequel le titulaire des droits dauteur patrimoniaux sur un logiciel que ce soit lauteur ou encore le cessionnaire de ces droits (employeur des auteurs, diteur, acqureur du logiciel) autorise un tiers, le client final, se servir du logiciel pour une ou plusieurs utilisations dfinies175. II. Enjeux de la qualification de la licence 216.La qualification reconnue au contrat de licence dutilisation dterminera le rgime juridique qui lui sera applicable. En outre, de la qualification dpendra dans une certaine mesure la qualit de march public, susceptible dtre reconnue cet octroi de licence. Il est ds lors essentiel, dans le chef du preneur, de se soucier de la qualification juridique de la licence quil contracte. III. Amnagement contractuel dun droit patrimonial 217.On peut considrer la licence dutilisation comme tant lamnagement contractuel de droits patrimoniaux sur le logiciel, et ce, mme si aucune qualification juridique prcise ne semble lui correspondre parfaitement. En effet, ni la qualification de contrat de vente, ni celle de contrat de louage de chose ou douvrage ne rencontrent exactement les caractristiques de la licence176. Par consquent, bien plus que de lapparentement lune de ces figures du droit commun, le rgime juridique de la licence dpendra dans une large mesure de la volont contractuelle des parties. Ce sont en effet les clauses de la licence qui dtermineront les modalits dutilisation de lapplication informatique. 218.En tout tat de cause, puisque la licence dutilisation est considre comme lamnagement contractuel dun droit patrimonial, la qualification de marchs de travaux et de services est carte. 219.Reste se poser la question dune ventuelle application de la qualification de march de fourniture (ou vente). Comme prcis auparavant, la qualification de vente npouse pas les caractristiques de la licence dutilisation. En effet, la licence nopre pas un transfert total de la proprit (contrairement au contrat de vente). Cette raison a conduit la doctrine belge177 rejeter la qualification de fourniture de biens en matire de logiciel.
Notons cependant que dans lhypothse particulire o ladministration dsire obtenir un nombre important de licences sur des progiciels largement utiliss (telle la suite Microsoft Office), elle procdera une mise en concurrence pralable des diffrents fournisseurs potentiels. Lon pourrait dans ce cas de figure estimer
175 176
P. Gelly, La continuation des contrats en cours portant sur les logiciels , D.I.T., 1996/2, p. 86. Dans certaines hypothses toutefois lorsquune redevance successive est due par lutilisateur en contrepartie de son droit dutilisation la qualification de contrat de louage de chose peut sembler approprie. 177 E. MONTERO, Les contrats informatiques de lInternet, Bruxelles, Larcier, 2005, p. 73.
86
applicable, par analogie, la lgislation relative aux marchs publics. Quoi quil en soit, cette situation parat trangre au contexte de mutualisation, exclusif de lide de grande diffusion .
220.Ds lors, lon peut soutenir que loctroi dune licence dutilisation, quelle soit propritaire ou Open source, ne rencontre pas les conditions de lapplicabilit de la lgislation relative aux marchs publics et certains marchs de travaux, de fourniture et de services178.
Ainsi, lorsque Qualicit accorde une licence dutilisation sur le logiciel ses membres, linstitution et les administrations sont tenues par un contrat qui ne tombe pas sous le champ dapplication de la lgislation relative aux marchs publics.
IV. Incidence des prestations annexes sur la qualification A. La qualification des prestations annexes 221.La qualification des prestations annexes se rvle, quant elle, plus dlicate : elle peut varier selon lobjet des prestations et le contexte dans lequel elles sont assures. Lexemple de la maintenance offre une intressante illustration de la complexit de la question. Celle-ci ne peut cependant tre rgle quau vu de chaque cas despce et requiert en chaque situation lexercice dun pouvoir dapprciation. 222.Il nest pas toujours ais de dterminer sans ambigut les types de maintenance (corrective, volutive) ds lors que la terminologie utilise peut tre comprise diffremment dun acteur lautre. Le modle auquel nous avons eu recours dans ce rapport, nest, par consquent, quun exemple parmi dautres. B. Maintenance corrective (et prestations assimiles) 223.En raison de lincidence quelles peuvent avoir sur lobjet de la licence ( savoir lutilisation du logiciel), les prestations de maintenance corrective et de mise jour du logiciel peuvent tre considres comme inhrentes la licence, dont elles adoptent alors la qualification et le rgime juridiques ; il en va gnralement de mme, de la maintenance impose par la veille rglementaire. Ces prestations incombent normalement179 au donneur de licence, au titre de son obligation de mettre disposition un logiciel susceptible de faire lobjet dune utilisation paisible et commode. On peut dailleurs, dans une certaine mesure, soutenir quelle ressortit lobligation de garantie qui pse sur ce donneur180. 224.Lorsquelle relve des obligations du donneur, la circonstance que celui-ci lassure directement ou fasse intervenir un prestataire de service quil aura dsign, est indiffrente pour le preneur. En revanche, si celui-ci doit lassurer181 et fait appel, pour ce faire, un prestataire de service tiers, il y aura bien un contrat portant sur ces prestations de maintenance et il sera soumis lapplication de la lgislation relative aux marchs publics.
178 179
L. du 24 dc. 1993 relative aux marchs publics et certains marchs de travaux, de fourniture et de services. Sans prjudice de la possibilit de lexclure conventionnellement. 180 Cf. supra, n III. 181 Parce quelle est exclue par la licence.
87
C. Maintenance volutive (et prestations assimiles) 225.La maintenance volutive ou toute autre prestation tendant configurer, en y apportant des modifications substantielles, le logiciel aux besoins du preneur, sera gnralement considre comme une prestation de services distincte de la licence, et fera, le cas chant, lobjet dun march public de services. Le preneur de services qui fait appel un prestataire tiers devra respecter la lgislation relative aux marchs publics et, ce titre, assurer une mise en concurrence pralable. Cette qualification de march public ne sera pas exclue par le fait que le donneur assure lui-mme les prestations182, sauf si une relation de type in house183 est tablie entre le preneur et le donneur. Par ailleurs, si le logiciel avait t dvelopp par un prestataire de services tiers, celui-ci ne pourrait tre automatiquement dsign par le preneur ; ce ne pourrait tre le cas que sil apparaissait incontournable et tait choisi dans le cadre dune procdure ngocie. Cela tant, on rappellera quau titre des prcautions requises dans la passation de tout march de dveloppement de logiciel, il est recommand de prvenir, par des mesures appropries184, toute situation en laquelle un prestataire fait figure de personne incontournable . V. Influence des oprations in house sur la qualification 226.La licence dutilisation dun logiciel nest qualifie ni de contrat de prestation de services, ni de contrat de fourniture de biens (sous certaines rserves185) et nimplique ds lors pas lapplicabilit de la lgislation relative aux marchs publics. 227.Si toutefois cette analyse ntait pas suivie et sil y avait lieu de considrer malgr tout que loctroi dune licence constitue bien une prestation de services, cet octroi par une structure institutionnelle de mutualisation ses membres adhrents ne pourrait tre qualifi de march public lorsque la situation envisage rencontre les caractristiques des oprations in house . La thorie des marchs in house a vu le jour en 1999, loccasion de larrt Teckal de la Cour de Justice des Communauts Europennes. Il ressort de larrt que, pour quun contrat puisse tre qualifi de march public, il suffit, en principe, que le march ait t conclu entre, dune part, une collectivit territoriale et, dautre part, une personne juridiquement distincte de cette dernire. Il ne peut en aller autrement que dans lhypothse o, la fois, la collectivit territoriale exerce sur la personne en cause un contrle analogue celui quelle exerce sur ses propres services et o cette personne ralise lessentiel de son activit avec la ou les collectivits qui la dtiennent186. Lhypothse dont il est question est prcisment celle qui sera qualifie de march in house lorsque les deux conditions prcites sont remplies : 1) La collectivit territoriale exerce sur la personne en cause un contrle analogue celui quelle exerce sur ses propres services ;
182 183
Ce qui pourrait fort bien tre le cas lorsque le logiciel a t dvelopp en interne, par ses propres agents. Sur cette notion, cf. infra, nV et suiv.. 184 Accs un code-source lisible et bien document, amnagement des droits de proprit intellectuelle, 185 Sur cette notion, cf. supra, n III. 186 C.J.C.E., 18 nov. 1999, (arrt TECKAL), C-107/98, Rec. C.J.C.E., p. I-8121, point 50.
88 2) Cette personne ralise lessentiel de son activit avec la ou les collectivits qui la dtiennent. En dautres termes, le march public est un contrat, ce qui suppose que deux parties rellement distinctes puissent tre identifies, dfaut de quoi les relations contractuelles sont inexistantes. Dans le cadre dun march in house187, il nexiste pas vraiment de contrat parce que le pouvoir adjudicateur confie des prestations une entit, certes juridiquement distincte de la sienne, mais qui ne dispose pas son gard dune autonomie de fonctionnement suffisante.
Si lon prend un exemple concret, la qualification de march in house pourrait tre reconnue des prestations de maintenance ou de formation quassurerait Qualicit188 au bnfice de ses membres adhrents. Pour ce faire, les communes doivent exercer sur Qualicit un contrle analogue celui quelles exercent sur leurs propres services. Qualicit doit en outre raliser lessentiel de son activit avec les communes qui la dtiennent. Si tel est le cas, le contrat pass entre linstitution et ses membres sera qualifi de march in house , dnomination qui engendre linapplicabilit de la lgislation relative aux marchs publics et certains marchs de travaux, de fourniture et de services.
228.Il y a lieu de relever que la jurisprudence des Communauts Europennes ne permet pas de dfinir prcisment la porte et les limites de ces deux conditions ; elles doivent ds lors tre manies et interprtes avec prudence. Lon peut toutefois retenir de lenseignement des juges europens certains lments:
- Il a ainsi t reconnu que la condition du contrle analogue ne peut tre remplie si le capital du prestataire est ouvert un actionnariat priv. - Le fait quun nombre important de collectivits publiques soit lorigine de la cration de linstitution ne semble pas incompatible avec la condition du contrle exerc sur celle-ci. - Enfin, ce sont les prestations assures pour lensemble des collectivits territoriales (et non pour chacune delles, sparment) qui sont prises en considration pour interprter la condition requise du prestataire dassurer lessentiel de son activit pour les pouvoirs adjudicateurs.
187
Nous utilisons la terminologie march in house (gnralement rpandue), tout en tant conscients de ce quelle nest naturellement pas approprie, puisque lopration in house est, par dfinition, exclusive de la notion de march. 188 Cf. annexe, n II et suiv..
89
2.
Licence propritaire et Open source

I. Introduction
229.Deux possibilits soffrent ladministration, titulaire des droits patrimoniaux sur lapplication informatique, qui envisage le lancement dun processus de mutualisation en aval : soit elle opte pour la diffusion de lapplication informatique en mode propritaire, soit elle prfre avoir recours au modle de distribution dit libre . Pour ce faire, ladministration octroie respectivement dautres entits, des licences dites propritaires , garantissant son contrle sur la distribution du logiciel, et des licences dites Open source , engendrant une diffusion quasi-illimite. Notons quune licence, quelle soit Open source ou propritaire, est toujours un contrat, au sens juridique du terme. Le transfert des droits patrimoniaux du donneur au preneur dpendra du type de licence envisag : libre ou propritaire. La premire hypothse permettra au preneur de la licence de jouir de lensemble des droits patrimoniaux de la proprit intellectuelle, alors que la deuxime ne lui assurera gnralement quun droit dusage. Notons que le recours la licence propritaire ne signifie pas que ladministration doive ncessairement tre propritaire de tous les lments du logiciel !
On peut, par exemple, imaginer que le cahier spcial des charges dsigne dautres utilisateurs du logiciel que le seul pouvoir adjudicateur. Mme si ce dernier nobtient pas lensemble des droits patrimoniaux sur le logiciel, il pourra accorder une licence aux entits identifies dans le cahier spcial des charges. La licence dont bnficieront ces entits est dite propritaire puisquelle naura pas comme consquence de transfrer les droits patrimoniaux sur le logiciel aux administrations utilisatrices.
230.Il est relevant de prciser que, en pratique, la distinction entre les deux modes de diffusion nest pas toujours aise oprer, ds lors quune licence propritaire peut revtir des conditions souples dutilisation (transfert du code source, possibilit de distribution ultrieure), et quune licence hybride peut contenir des dispositions contraignantes dexploitation (distribution limite, modification du code sous conditions).
Une administration qui obtient une licence propritaire sur un logiciel peut ngocier avec le donneur de cette licence afin de bnficier dautres droits quuniquement celui dusage. Elle pourrait par exemple obtenir laccs au code source et le droit de lutiliser des fins de maintenance informatique ou encore le droit de dsigner dautres utilisateurs du logiciel189.
189
Cf. infra, n I et suiv..
90
II. Hypothse de distribution du logiciel en mode propritaire 231.La licence dite propritaire rfre au fait que lauteur originaire ou driv190 de lapplication informatique reste titulaire des droits patrimoniaux de la proprit intellectuelle. Gnralement, ladministration preneuse de ce type de licence ne bnficiera que dun droit dusage sur un exemplaire unique du programme. La modification, la distribution, le prt ou encore la copie (sauf des fins de back up), ne seront autoriss qu la faveur dune clause les accordant expressment ; il se peut par ailleurs quils soient formellement prohibs par le contrat de licence. III. Hypothse de distribution du logiciel en mode libre 232.Lapplication informatique dont lutilisation est voue la mutualisation, peut tre diffuse sous un mode dit libre ou Open source . Notons que les deux termes sont utiliss indistinctement dans le cadre de ce rapport. A. Licence libre 233.Une licence est considre comme libre par la Free Software Fundation lorsque quatre liberts fondamentales sont respectes191: la libert dutiliser le programme, pour tous les usages ; la libert dtudier le fonctionnement du programme et de ladapter aux besoins, ce qui ncessite laccs au code source ; la libert de redistribuer des copies ; la libert damliorer le programme et de publier les amliorations pour en faire profiter toute la communaut, ce qui ncessite laccs au code source.
B. Licence Open source

234.La licence Open source rpond dix critres tablis par lOpen source Initiative192: 190 191
la redistribution du programme libre et gratuit ; la livraison du code source avec le programme ; la distribution des travaux drivs dans les mmes termes que la licence du logiciel dorigine ; la prservation de lintgrit du code source de lauteur ; labsence de discrimination envers des personnes ou des groupes ; labsence de discrimination envers des domaines dactivit ; labsence dobligation de se conformer des termes de licences complmentaires ; labsence de licence spcifique un produit ;
Cf. supra, n III. Cf. le site Internet de la Free Software Foundation : http://www.fsf.org/licensing/essays/free-sw.html 192 Cf. le site Internet de lOpen source Initiative : http://www.opensource.org/docs/osd
91 labsence de licence imposant des restrictions sur dautres logiciels ; la neutralit technologique.
IV. Avantages et inconvnients des deux modes de diffusion A. Transfert des droits patrimoniaux 235.Lorsquune application informatique est diffuse en mode Open source, certaines questions, telles que celles concernant la titularit des droits patrimoniaux sur le logiciel 193, nont plus de raison dtre. En effet, dans le modle libre compris dans son sens le plus large les droits de la proprit intellectuelle sont partags entre tous les utilisateurs. Chacun est ds lors habilit modifier le programme et y insrer de nouvelles fonctionnalits selon ses besoins propres. La libert dont bnficie le preneur de licence est ds lors quasi-totale.
Ainsi, les administrations initiatrices des projets PloneGov, Tabellio et LiberAccs ont opt pour la diffusion des logiciels en mode Open source, modle qui favorise lutilisation du logiciel par une trs large communaut et dont la philosophie de partage des savoirs et de lexprience semble approprie aux objectifs de la mutualisation194.
236.Une application informatique distribue sous une licence propritaire ne transmet son preneur que des droits limits sur lapplication informatique. Gnralement, ladministration preneuse ne pourra bnficier que dun droit dusage sur le logiciel. Cependant, comme il la t expos prcdemment195, la licence peut contenir des dispositions garantissant loctroi de droits plus tendus pour le preneur. La libert de ladministration utilisatrice reste toutefois limite. B. Contrle sur la diffusion 237.Le recours un mode de diffusion Open source entrane limpossibilit pour ladministration donneuse de licences de contrler la diffusion du logiciel, ce qui peut savrer contraignant pour la gestion du processus de mutualisation en aval. En effet, la communaut dutilisateurs peut devenir extrmement importante, ce qui demandera des efforts trs lourds dans la gestion du projet. Notons que les licences acadmiques, du fait de leur caractre permissif, stimulent plus la diffusion que les licences gauches d'auteur. 238.De surcrot, ladministration qui nest pas en mesure de vrifier quels seront les futurs utilisateurs de son application informatique renonce toute rmunration ventuellement
193
Rappelons que les droits patrimoniaux de la proprit intellectuelle comportent la reproduction permanente ou provisoire, la distribution sous toute forme au public, ladaptation, larrangement, la location et le prt du logiciel (art. 5 L. 30 juin 1994 transposant en droit belge la directive europenne du 14 mai 1991 concernant la protection juridique des programmes d'ordinateur). 194 Cf. annexe, n II, II et II. 195 Cf. infra, n I et suiv..
92 due en contrepartie de loctroi dune licence196. Labsence de rtribution financire des droits dutilisation est dailleurs inhrente au modle libre. 239.Dans lhypothse o le processus de mutualisation est mis en uvre par le biais dune structure institutionnelle ou contractuelle, lon peut se demander juste titre quel serait lintrt pour une administration de rejoindre la structure, partir du moment o nimporte qui est mme de bnficier de lapplication informatique. Ladhsion peut, dans ce cas, tre motive par dautres considrations, telle la volont de ladministration dtre plus implique dans le fonctionnement de la structure. 240.Par contre, la diffusion dun logiciel en mode propritaire, implique lavantage non ngligeable pour ladministration donneuse de licences, de garder un contrle sur la distribution du programme. Les efforts de gestion du projet de mutualisation en seront ds lors amoindris. Ladministration sera en outre en mesure de requrir une contrepartie financire de lutilisation de lapplication informatique. C. Responsabilit du donneur de licence 241.Plus le preneur bnficie de droits dans lexploitation du logiciel, plus il est libre et indpendant face son cocontractant, moins le donneur de licence engage sa responsabilit en cas de dficience du programme. 242.La question de la responsabilit est particulirement pertinente dans lhypothse o la licence est de type Open source. Dans ce cas, le preneur dtient des droits trs tendus sur lapplication informatique, droits lui garantissant une libert dutilisation quasi-illimite : droits de modification, de distribution au public, de reproduction etc. Le donneur est cependant conscient que le logiciel a vocation tre trs largement diffus. Ds lors, il est frquent quil refuse dinclure dans la licence une clause de garantie contre la revendication dun tiers ou en cas de dysfonctionnement de lapplication informatique.
Ladministration pour le compte de qui a t dvelopp le logiciel (en interne ou par un prestataire extrieur) se rend compte que le contrle de la diffusion du programme risque de lui chapper dans le cadre de la mutualisation en aval. Elle insre alors une disposition dexemption de sa garantie. Cette situation peut savrer juridiquement dangereuse pour le preneur de licence qui sassure alors dobtenir une garantie auprs dun prestataire extrieur (par exemple celui qui installe le logiciel et qui assure la maintenance sur celui-ci).
243.A contrario, si le logiciel est distribu sous une licence propritaire, la libert daction du preneur sera limite, mais il sera beaucoup moins expos linscurit juridique. D. Accs au code source 244.Dans un modle libre, les codes sources sont transmis aux administrations utilisatrices. Le recours ce mode de diffusion est, dans une certaine mesure, une garantie de la qualit du code source qui est en permanence contrl et remani par les programmeurs utilisateurs.
196
Cf. supra, n VI.
93 En outre puisque que chacun a accs la technologie et que le logiciel largement utilis devient rapidement un standard lindpendance de ladministration face un prestataire particulier, est garantie. En effet, soit ladministration est en mesure dassurer elle-mme la maintenance informatique sur le logiciel, soit elle a recours un prestataire extrieur sans tre dpendante de celui-ci, puisque lapplication est largement reconnue et utilise. Rappelons cependant quune trop grande diffusion du programme peut constituer une contrainte pour le processus de mutualisation197. 245.Par contre, ladministration preneuse dune licence propritaire na en gnral pas accs au code source. Cette situation nexclut pas qu la faveur dun accord entre les parties, lentit utilisatrice puisse se voir rserver un accs au code des fins de maintenance corrective et dadaptation198, en incluant une disposition particulire ce titre dans la licence. De la sorte, elle sera forte dune certaine indpendance face aux prestataires extrieurs (ou, tout le moins, lgard de celui qui a assur le dveloppement du logiciel). Rappelons quil nexiste pas quun seul type de licence propritaire et que les parties au contrat amnagent les modalits dutilisation leur guise. 246.Que la licence soit libre ou propritaire, lorsque les administrations ont accs aux codes sources, lindpendance juridique lgard dun prestataire dtermin sera vaine si les codes ne sont pas lisibles199.
E. Problmatique des forks

247.Ladministration donneuse de licence est attentive valuer le risque davnement de forks internes (terme anglais signifiant bifurcations), qui pourraient affecter le processus de mutualisation. Daprs Robert Viseur200, il y a en effet lieu dviter les dveloppements sur mesure, par des administrations dont les besoins sont similaires. Les forks peuvent mener la scission dun projet commun, ce qui se rvle nuisible notamment lorsque lon considre laugmentation du cot de la maintenance. En outre, si les administrations dveloppent chacune des fonctionnalits diffrentes (des doublons ), alors les efforts de gestion du processus de mutualisation deviennent considrables. Notons toutefois que les forks peuvent savrer utiles sils permettent aux entits de prendre conscience de la diversit de leurs besoins et ds lors, de la ncessit de crer deux branches distinctes. 248.Le risque de forks est invitable dans un modle libre, puisque chacun peut apporter ses spcificits au programme et puisque la communaut dutilisateurs est en constante volution. Ds lors, les utilisateurs doivent adopter une attitude responsable lorsquils ont recours au modle libre.
Conscientes des risques lis au modle libre et de la ncessit de canaliser les initiatives individuelles, les administrations animatrices du projet LiberAccs organisent la mutualisation dans un cadre institutionnel afin de limiter les dbordements. Ds quun membre souhaite modifier ou adapter un logiciel en
197 198
Cf. supra, n IV et suiv.. Cf. infra, n I. 199 Cf. supra, n IV et suiv.. 200 R. VISEUR, Approche mthodologique de la mutualisation in Services publics et mutualisation informatique, de la thorie la pratique, compte rendu de la journe organise le 23 mars 2006 par la Communaut franaise de Belgique.
94
fonctions de ses spcificits, il en demandera la ncessaire autorisation au groupement201.
249.Dans le modle libre, la conclusion dune convention de collaboration entre la ou les administration(s) donneuse(s) de licences et les entits preneuses utilisatrices est conseille pour la bonne gestion du processus de mutualisation. En quelque sorte, plus les entits sont libres dans lutilisation de lapplication informatique, plus les besoins dun encadrement juridique se font ressentir. Ainsi fonctionne le fragile quilibre de la mutualisation. Lobjectif de la convention de collaboration nest certes pas de dnaturer les conditions et les spcificits de la licence Open source. Le modle libre nexclut pas que, paralllement, des rgles de comportements soient adoptes par les administrations pour les besoins de la mutualisation.
Une convention de collaboration peut prvoir une procdure daccord du comit de pilotage lorsquune administration, qui a programm une nouvelle fonctionnalit de lapplication informatique, dsire la diffuser au public. Une telle clause permet de matriser les risques de forks nuisibles.
La convention de collaboration est en outre requise du fait que les clauses du contrat de licence Open source ne sont en gnral pas suffisantes pour limiter efficacement les risques de forks nuisibles. En effet, le modle libre suppose que les distributeurs de lapplication informatique utilisent la mme licence que celle initialement choisie par lauteur, sans possibilit de modification202. Les clauses de la licence ne correspondront pas ncessairement aux besoins de la mutualisation.
Ainsi, les clauses 12. 2 et 12. 3 de la licence libre CeCILL203 prvoient expressment que le texte du contrat ne peut tre modifi que par lauteur de la licence : Afin d'en prserver la cohrence, le texte du Contrat est protg et ne peut tre modifi que par les auteurs de la licence, lesquels se rservent le droit de publier priodiquement des mises jour ou de nouvelles versions du Contrat, qui possderont chacune un numro distinct. Ces versions ultrieures seront susceptibles de prendre en compte de nouvelles problmatiques rencontres par les logiciels libres. Tout Logiciel diffus sous une version donne du Contrat ne pourra faire l'objet d'une diffusion ultrieure que sous la mme version du Contrat ou une version postrieure [...].
Il y a toutefois lieu de nuancer quelque peu nos propos eu gard lhypothse o une application informatique est dveloppe par ou pour ladministration animatrice du projet de mutualisation. Dans cette situation, lentit publique devient le titulaire driv des droits patrimoniaux sur le logiciel204. Elle sera matresse du choix du mode de diffusion en libre ou en propritaire et seule habilite dcider des termes de la licence, sauf si elle a intgr des lments copylefts dans lapplication informatique205. Elle sera mme dinsrer une clause limitant les risques de forks.
201 202
Cf. annexe, n II. Sauf qu'une application sous une licence donne peut parfois tre transforme sous une licence plus forte (ex.: une application BSD en LGPL ou en GPL). 203 Cf. http://www.cecill.info/licences/Licence_CeCILL_V2-fr.html 204 Cf. supra, n III et suiv. ; III et suiv.. 205 Cf. supra, n IV.
95
Nanmoins, dans la pratique, le recours des modles de licences Open source prexistantes est une pratique largement rpandue, ds lors quelle limite les risques dincompatibilit.
Larticle 5. 3. 4 de la licence libre CeCILL206 tablit le principe de la compatibilit avec la licence GPL : Le Licenci peut inclure un code soumis aux dispositions d'une des versions de la licence GNU GPL dans le Logiciel modifi ou non et distribuer l'ensemble sous les conditions de la mme version de la licence GNU GPL. Le Licenci peut inclure le Logiciel modifi ou non dans un code soumis aux dispositions d'une des versions de la licence GNU GPL et distribuer l'ensemble sous les conditions de la mme version de la licence GNU GPL.
A contrario, dans le modle propritaire, les risques de forks sont fortement diminus. En effet, les utilisateurs ne bnficient que dune libert trs limite et ne possdent que peu de droits. La licence dutilisation semble ds lors suffisante pour encadrer le processus de mutualisation en aval et il ne semble pas quune convention de collaboration savre indispensable. Dans le modle libre comme dans le modle propritaire, la convention de collaboration peut amnager efficacement les contributions respectives, humaines et techniques, des participants au processus de mutualisation207.
206 207
Cf. http://www.cecill.info/licences/Licence_CeCILL_V2-fr.html Cf. supra, n VII et suiv..
96
3. Clauses insrer dans la licence

I. Point de vue du preneur de licence 250.Les clauses sont ici envisages du point de vue du preneur de licence. Il sagit de dterminer les lments auxquels il se doit dtre attentif lors de la conclusion du contrat de licence. A. Transfert des codes sources 251.Le preneur de licence propritaire sassure de dtenir tous les supports et toute la documentation ncessaire une utilisation commode de lapplication informatique. Quant aux codes sources, ceux-ci ne sont laccoutume pas transmis sauf ventuellement des fins de maintenance corrective. Le champ daction de ladministration preneuse est ds lors indniablement limit. Toute modification du programme est rendue impossible. Notons cependant que la possibilit dassurer la maintenance corrective garantit une certaine indpendance du preneur face au donneur de la licence. 252.Par contre, le preneur dune licence Open source dtient des droits trs tendus sur lapplication informatique et notamment celui de disposer et de modifier le code source sa guise. B. Mises jour et dveloppements ultrieurs 253.Les mises jour et dveloppements ultrieurs sont intrinsquement lis lusage du logiciel. Le donneur de la licence intgre ds lors une clause garantissant leur communication aux administrations utilisatrices. Les mises jour et les dveloppements ultrieurs sont, dans le cadre dun programme Open source, librement accessibles pour les utilisateurs ds leur diffusion. C. Prestations annexes 254.La licence tant un contrat, la volont des parties est prdominante pour linterprtation des obligations du donneur en matire de maintenance. En toute hypothse, et quel que soit lamnagement des droits et obligations rciproques en cette matire, lorganisation de la maintenance gagnera tre expressment rgle, par linsertion de clauses adquates.
97
D. Droit de dsigner dautres utilisateurs 255.Gnralement, la licence propritaire naccorde au preneur quun simple droit dutilisation sur lapplication informatique sans possibilit de dsigner ultrieurement dautres entits utilisatrices. Le droit de reproduction nest en effet accord lordinaire qu des fins de sauvegarde (back-up). Nonobstant ce fait, lon pourrait imaginer quune administration dsireuse dlargir lusage du logiciel des fins de mutualisation require linsertion dune clause dsignant les utilisateurs futurs et potentiels. La liste sera ncessairement limitative, le donneur de la licence nayant aucun intrt ce que son logiciel soit largement utilis, ds lors quil garde la titularit des droits sur celui-ci. En outre, le cot de la licence risque dtre sensiblement plus lev.
Larticle 3 de la licence propritaire Skype208 garantit une possibilit douverture dautres utilisateurs, sous conditions : Vous n'tes pas autoris distribuer le logiciel Skype en vertu du prsent contrat. Pour obtenir un droit de redistribution, vous devrez accepter et respecter les Conditions gnrales de distribution publies sur le site Web de Skype . Parmi les conditions de la licence, lon retiendra lobligation dagir selon un objectif lgitime, linterdiction de distribuer la licence des fins commerciales (en ce compris les services annexes) et le fait que la licence Skype doit tre accepte par les futurs utilisateurs de lapplication informatique.
256.La problmatique susmentionne ne retient pas lattention lorsque le logiciel est distribu sous licence libre. Un des objectifs de ce type de licence est sans conteste que lapplication informatique soit mise disposition dune trs large communaut dutilisateurs. E. Responsabilit du donneur de la licence 1)Garantie en cas de dysfonctionnement de lapplication informatique 257.Comme nous lavons dit prcdemment209, les parties sont soumises en rgle gnrale au droit commun de la responsabilit contractuelle en cas dinexcution de leurs obligations. La volont des parties est sans conteste llment central de la responsabilit contractuelle. Nous recommandons ds lors de procder la rdaction minutieuse des clauses de la licence.
- Il peut tre dtermin prcisment dans la convention quelle sera la responsabilit du donneur de licence en cas de dysfonctionnement de lapplication informatique. Des indemnits peuvent tre contractuellement amnages. - Les licences Open source limitent gnralement la responsabilit du donneur de la licence. Ainsi, la clause 8. 2 de la licence libre CeCILL 210 est rdige de cette manire :
208 209
Cf. http://www.skype.com/intl/fr/company/legal/eula/ Cf. supra, n III. 210 Cf. http://www.cecill.info/licences/Licence_CeCILL_V2-fr.html
98
La responsabilit du Concdant est limite aux engagements pris en application du Contrat et ne saurait tre engage en raison notamment: (i) des dommages dus l'inexcution, totale ou partielle, de ses obligations par le Licenci, (ii) des dommages directs ou indirects dcoulant de l'utilisation ou des performances du Logiciel subis par le Licenci et (iii) plus gnralement d'un quelconque dommage indirect. En particulier, les Parties conviennent expressment que tout prjudice financier ou commercial (par exemple perte de donnes, perte de bnfices, perte d'exploitation, perte de clientle ou de commandes, manque gagner, trouble commercial quelconque) ou toute action dirige contre le Licenci par un tiers, constitue un dommage indirect et n'ouvre pas droit rparation par le Concdant.
Prcisons que les bugs et erreurs sont des dysfonctionnements normaux dune application informatique qui na dailleurs pas vocation tre immuable et qui volue au fil de son utilisation. La responsabilit du donneur de licence ne serait ds lors engage quen cas de dysfonctionnement particulirement grave qui obstruerait une utilisation normale du logiciel. 258.La garantie en cas de dysfonctionnement peut revtir la forme dune clause de maintenance corrective dans la licence dutilisation, la maintenance tant assure par les informaticiens de ladministration donneuse de la licence, ou par un prestataire agissant dans le cadre dun march de services pass avec cette administration. 259.Il se peut que le preneur de licence soit insatisfait des prestations de maintenance corrective. Il sera habilit contracter avec un autre fournisseur de services, sil arrive rsilier ou rsoudre le contrat initial211. Ces possibilits peuvent tre contractuellement amnages, do lintrt de rdiger la licence de manire non ambigu.
Il peut tre conventionnellement prvu dans le contrat dutilisation que le preneur est habilit changer de prestataire de maintenance sous certaines conditions telles que linexcution ou la mauvaise excution des obligations de celui-ci.
2) Garantie dviction : 260.Afin dviter tout trouble ultrieur dans lusage du logiciel, il est essentiel que le donneur de licences garantisse tre le titulaire des droits de la proprit intellectuelle quil cde ladministration utilisatrice et quil ne porte pas atteinte, de ce fait, aux droits dautrui. Il sengage en outre rcuprer ses frais les ventuels droits litigieux et, lorsque cela savre impossible, il propose une solution de rechange qui doit tre pralablement accepte par le preneur de licence212.
- Une administration obtient une licence Open source sur un logiciel dans lequel le donneur a intgr des lments propritaires sans en avoir obtenu la titularit du droit de distribution au public. Ladministration, forte de sa licence libre, se lance dans un processus de mutualisation en aval. Le tiers titulaire du droit de distribution sur les lments propritaires intente une action en dommages et intrts lencontre de ladministration preneuse de la licence. Lon comprend aisment dans cette hypothse lintrt quaurait eu ladministration dtre protge
211 212
Cf. supra, n III et suiv.. Cf. supra, n III.
99
par une clause de garantie dviction dans le contrat de licence, clause lui assurant que le donneur prendrait sa charge les dommages et intrts et proposerait une solution alternative. - Notons toutefois que dans la pratique, le donneur dune licence Open source est rticent intgrer une garantie dviction dans le contrat213, comme le dmontrent les termes utiliss dans la licence libre CeCILL214, article 9, 4 : Le Concdant ne garantit pas, de manire expresse ou tacite, que le Logiciel ne porte pas atteinte un quelconque droit de proprit intellectuelle d'un tiers portant sur un brevet, un logiciel ou sur tout autre droit de proprit. Ainsi, le Concdant exclut toute garantie au profit du Licenci contre les actions en contrefaon qui pourraient tre diligentes au titre de l'utilisation, de la modification, et de la redistribution du Logiciel. Nanmoins, si de telles actions sont exerces contre le Licenci, le Concdant lui apportera son aide technique et juridique pour sa dfense. Cette aide technique et juridique est dtermine au cas par cas entre le Concdant concern et le Licenci dans le cadre d'un protocole d'accord. Le Concdant dgage toute responsabilit quant l'utilisation de la dnomination du Logiciel par le Licenci. Aucune garantie n'est apporte quant l'existence de droits antrieurs sur le nom du Logiciel et sur l'existence d'une marque.
II. Point de vue du donneur de licence 261.Les questions ici analyses sont celles auxquelles se doit dtre attentif le donneur de licence. A. Droits transfrs 262.Sil dsire garder un contrle trs tendu sur lapplication informatique, le donneur de la licence sassure de ne transfrer quun droit dusage aux administrations. Celles-ci sengagent en outre ne pas cder le logiciel et ne pas communiquer dinformations relatives celui-ci.
La licence propritaire Adobe215 (article 2) ne transfre quun droit dusage sur le logiciel : Vous tes autoris installer et utiliser une copie du logiciel sur votre ordinateur compatible, concurrence du nombre autoris d'ordinateurs. Il est interdit de partager, dinstaller ou dutiliser le Logiciel sur plusieurs ordinateurs la fois [...]. De nombreuses limitations sont expressment mentionnes dans la troisime clause : Vous ntes pas autoris utiliser lun des Produits Internet sur un quipement autre quun PC ou sur toute version intgre ou embarque de tout systme d'exploitation quel quil soit [...].
213 214
Cf. supra, n IV. Cf. http://www.cecill.info/licences/Licence_CeCILL_V2-fr.html 215 Cf. http://www.adobe.com/fr/products/eulas/players/flash/
100
Vous ntes pas autoris copier le Logiciel [...] Il se peut que le Logiciel contienne des caractristiques et des fonctionnalits (les Caractristiques de Document ) qui sont dsactives ou "en gris". Ces Caractristiques de Document seront actives uniquement lors de l'ouverture dun fichier PDF cr l'aide de la technologie de validation correspondante disponible uniquement auprs d'Adobe (les "Cls") [...]. Vous ne pouvez pas louer, donner en crdit bail, sous-licencier, cder ou transfrer vos droits relatifs au Logiciel, ou autoriser la copie de tout ou partie du Logiciel sur l'Ordinateur d'un autre utilisateur sauf autorisation expresse [...]. [...] le prsent Contrat ne vous concde aucun droit de proprit intellectuelle sur le Logiciel, et Adobe et ses fournisseurs se rservent tous les droits qui ne sont pas expressment concds .
263.Une certaine souplesse est parfois souhaitable lgard du preneur et loctroi de droits un peu plus tendus telle la possibilit de dsigner dautres utilisateurs dans la licence216 peut se rvler compatible avec les objectifs de la mutualisation informatique. 264.Lorsque le donneur a recours la licence libre, il y a un partage de tous les droits de la proprit intellectuelle. Le contrle sur la diffusion de lapplication informatique est ici fortement amoindri217.
Le prambule de la licence libre CeCILL218 est parlant ce sujet : Ce contrat est une licence de logiciel libre dont l'objectif est de confrer aux utilisateurs la libert de modification et de redistribution du logiciel rgi par cette licence dans le cadre d'un modle de diffusion en logiciel libre.
265.Dans la pratique, de nombreuses formules intermdiaires sont envisageables. B. Accs aux codes sources 266.Laccs au code source est indispensable pour de nombreuses oprations ayant trait lapplication informatique : la modification du logiciel, son adaptation et ses corrections. Conscient de ce que la communication des codes peut avoir des consquences importantes sur le logiciel (telle que la survenance de forks), le donneur de licence peut dcider, soit de ne pas transmettre le code, soit den transmettre une copie uniquement des fins de maintenance. Cette dernire remarque implique que le donneur de licence soit le propritaire des codes, sinon il nest pas habilit en disposer sa guise. 267.Lorsque le programme est distribu sous une licence libre, les codes sources sont mis librement disposition des utilisateurs. Il peut tre judicieux de prvoir dans cette hypothse
216
Comme il la t prcis par ailleurs, cf. supra, n I, la liste des utilisateurs potentiels est ncessairement limitative. Le donneur de licence, ds lors quil garde la titularit des droits patrimoniaux, na aucun avantage favoriser un usage largi de son application informatique. 217 Cf. supra, n IV et suiv.. 218 Cf. http://www.cecill.info/licences/Licence_CeCILL_V2-fr.html
101 une procdure de notification au donneur de la licence en cas de modification des codes dans une convention de collaboration. Le risque de forks nuisibles peut ainsi tre utilement vit219. C. Rtribution financire du donneur de licence 1)La rtribution est directement lie ltendue des droits transmis : 268.Plus les droits patrimoniaux transfrs par le biais de la licence dutilisation sont tendus, plus le cot payer par lutilisateur sera important. En effet, le donneur de licence qui est titulaire des droits sur le logiciel, na conomiquement aucun intrt cder dautres droits sur le logiciel que ceux ncessaires son utilisation. Ds lors, chaque droit transmis en sus du droit dusage reprsentera une charge supplmentaire pour le preneur de la licence. 269.Le donneur dune licence Open source nest pas rmunr en contrepartie des droits quil partage avec la large communaut dutilisateurs. Cette situation nexclut pas que les prestations de maintenance assures au profit des administrations utilisatrices le soient titre onreux220. 2)Les modalits de paiement peuvent dpendre de la structure de mutualisation : 270.Gnralement, la ou les administrations utilisatrices du logiciel rtribue(nt) le donneur de licence en contrepartie directe du droit dutilisation. Toutefois, lorsque la structure de mutualisation est institutionnalise, il arrive que les administrations bnficient de lusage du logiciel aprs avoir acquitt un droit dentre.
Ainsi, les nouveaux membres de la structure GILS acquittent un droit dentre linstitution. Leur qualit de membre leur permettra par aprs dutiliser lapplication informatique221. Pareillement, les nouveaux adhrents la structure Qualicit effectuent pour le G.I.E. un apport numraire et sacquittent en outre dune redevance annuelle. Ils bnficient ds lors du droit de prendre connaissance de linformation relative chaque produit dvelopp linitiative du G.I.E. (en ce compris la documentation relative aux modlisations de processus) 222.
D. Responsabilit du donneur de licence 271.La responsabilit du donneur de licence est fonction du contenu de la licence. En effet, la responsabilit contractuelle de droit commun prvoit que chaque partie peut tre tenue responsable de linexcution de ses engagements. Le donneur de licence en tient compte lors de la rdaction ou du choix de la licence.
219 220
Cf. supra, n IV et suiv.. Cf. supra, n VI et VI. 221 Cf. annexe, n I. 222 Cf. annexe, n I.
102 Ds lors, ladministration donneuse de la licence peut dcider dinsrer ou de ne pas insrer une clause de garantie en cas de dfaillance du logiciel 223 ou en cas de revendication par un tiers de ses droits ventuels sur le programme224.
Ladministration qui sengage garantir le preneur de la licence contre les dysfonctionnements du programme enverra un informaticien en cas de bugs dune application. Si elle nexcute pas cette obligation, elle risque de voir engage sa responsabilit contractuelle.
272.Il a t prcis auparavant que plus la licence octroie des droits aux utilisateurs, moins le donneur est enclin assortir sa licence de clauses de garantie225.
Ainsi, le prambule de la licence libre CeCILL226 est stipul de la sorte : L'accessibilit au code source et les droits de copie, de modification et de redistribution qui en dcoulent ont pour contrepartie de n'offrir aux utilisateurs qu'une garantie limite et de ne faire peser sur l'auteur du logiciel, le titulaire des droits patrimoniaux et les concdants successifs qu'une responsabilit restreinte.
223 224
Cf. supra, n III. Cf. supra, n III et suiv.. 225 Cf. supra, n IV et suiv.. 226 Cf. http://www.cecill.info/licences/Licence_CeCILL_V2-fr.html
103
Conclusion gnrale
273.Il peut paratre prsomptueux de prtendre conclure un propos qui, au stade actuel de la recherche et des pratiques, reste ncessairement ouvert, laissant dpourvues de rponses (suffisantes) dinnombrables questions ; aborde dans la deuxime partie de ltude, la qualification juridique des licences dutilisation et prestations annexes, offre de ce constat une illustration trs rvlatrice. Cette apprciation mitige, premire vue, ne doit cependant pas occulter les rsultats auxquels ltude aboutit. Lapproche de la mutualisation par le prisme de quatre hypothses de dveloppement de logiciels, a permis didentifier les obstacles ou adjuvants qui, en chacune dentre elles, peuvent influencer la conduite de projets et la ralisation des objectifs assigns ceux-ci. Tantt communs plusieurs (voire toutes les hypothses), tantt spcifiques lune ou lautre seulement dentre elles, ces facteurs dchec ou de russite sont largement conditionns par les objectifs du processus de mutualisation, tels quils ont t recenss dans lintroduction ce rapport. Le caractre trs rcurrent de certains dentre eux peut faire douter de la pertinence dune approche fonde sur une typologie de situations diffrentes. Ainsi, les deux hypothses de mutualisation en amont (respectivement par une communaut de dveloppeurs et par un prestataire de services) ont rvl une troite proximit des proccupations relatives au fonctionnement du partenariat entre entits publiques. Cette proximit est riche denseignements : elle impose notamment de relativiser fortement la porte des dbats entre conceptions antagonistes relatives lusage des mthodes, modles et outils de lOpen source ou lintrt de la structuration des partenariats entre entits publiques. Mme si certains des lieux de la mutualisation font encore figure de zones inexplores et, partant, voues aux investigations, le prsent rapport devrait offrir aux praticiens quelques repres directement utiles la conduite de projets de mutualisation, ds lors quils ont t identifis au dpart des observations inspires par lanalyse dexpriences dont rend compte lannexe. Gageons que ce rapport puisse offrir aux artisans dexpriences de mutualisation quelques balises qui les guident dans leur parcours.
104
Annexe : description dexpriences rcentes
Introduction
1. Objectif
1.La volont de raliser une tude qui soit utile aux praticiens incite prendre en considration les ralits auxquelles ceux-ci sont (ou ont t) confronts la faveur dexpriences de mutualisation informatique rcentes ou en cours. Outre que ces expriences rvlent des pratiques qui seront approuves ou, au contraire, dconseilles et qui, pour lune ou lautre de ces raisons, gagnent tre observes, leur description suggre les questions quune tude relative la mutualisation informatique dans le secteur public ne peut ignorer. Bien plus quun relev de bonnes ou mauvaises pratiques, cette description de cas se voit donc assigner un objectif pdagogique : elle doit faire dcouvrir lintrt des problmatiques abordes dans la suite de ce rapport.
2. Mthode
2.Ainsi identifi, le but poursuivi au travers de cette tude de cas justifie la manire dont celle-ci a t apprhende et dont cette partie rend compte. 3.Dune part, les dveloppements consacrs chaque exprience ne rendent pas compte de lintgralit des enseignements que son analyse a livrs : ceux-ci ont t slectionns au regard de leur capacit suggrer ou illustrer les problmatiques traites par la suite. 4.Dautre part, la prsentation des enseignements repose gnralement sur des titres et soustitres qui faciliteront le rapprochement avec la partie thorique du prsent rapport ; ce rapprochement devrait galement tre favoris par lintgration systmatique227 de deux clairages auxquels est soumis chaque enseignement : au constat quincite poser lexprience (caractres normaux) fait suite lnonc, en termes plus gnraux, de la problmatique que rvle ce constat (caractres gras) et qui sera traite dans la partie thorique de ce rapport. Cette faon de procder permet une gnralisation progressive de notre propos, au dpart de la dmarche casuistique, naturellement inhrente toute tude de cas.
227
A tout le moins, lorsque les questions abordes le permettent, ce qui est trs frquemment le cas.
105
Projet Iriscom228
1. Introduction
5.La gestion des chantiers touchant la voirie rgionale imposait un constat alarmant en Rgion de Bruxelles-Capitale : programmation sans concertation, entranant les dsagrments causs par des ouvertures successives de chantiers aux mmes endroits ; insuffisance de localisation des rseaux ; gestion inefficace des itinraires de dviation, Cette situation attira lattention du lgislateur bruxellois, qui, en 1998, prit une ordonnance tendant une gestion plus efficace de ces chantiers. Lenjeu ntait pas ngligeable si lon a gard limportance de la voirie rgionale, estime 1500 km, et au nombre dimptrants susceptibles dtre concerns par de tels travaux, savoir trente-trois. La ralisation de cet objectif defficacit reposait sur divers piliers , parmi lesquels figuraient la coordination des initiatives, la concertation entre acteurs concerns et une diffusion optimale de linformation relative ces chantiers. Pour rencontrer de telles proccupations, le dveloppement dune application informatique fut prconis par le lgislateur lui-mme. 6.Le projet Iriscom ne reprsente pas vraiment un exemple de dveloppement mutualis dune application informatique, ds lors que, dune part, le dveloppement na pas t conu dans le cadre dune communaut dutilisateurs partageant un investissement, et que, dautre part, la perspective dune mutualisation en aval na pas t privilgie au lancement du projet, au point de lanticiper. Cela tant, cette exprience retient lattention, car la pluralit naturelle 229 dutilisateurs du dveloppement inspire demble certaines questions et/ou rflexions qui ponctuent frquemment les pratiques de mutualisation informatique. .
228 229
Integrated Regional Information Services for Coordination and Mobility. Puisque le logiciel a vocation coordonner les actions dacteurs nombreux et divers, lesquels en seront donc naturellement les utilisateurs.
106
2. Logiciel dvelopp en partie par des agents du C.I.R.B. et en partie par un prestataire de services la demande dune administration seule
7.Prospection du march : solutions disponibles et besoins dautres utilisateurs A lpoque de lancement du projet, la prospection na pas permis de dtecter lexistence de solutions rpondant lensemble des fonctionnalits identifies. La perspective daccder une solution existante, dont le bnfice et pu tre accord ladministration rgionale bruxelloise, ne pouvait donc tre esquisse. De mme, le caractre indit du projet na pas incit ses promoteurs examiner les besoins ventuels dautres administrations soucieuses dune gestion efficace et coordonne de leurs chantiers de voirie, ni anticiper louverture des droits dutilisation du logiciel (faire) dvelopper. Les dmarches pralables au dveloppement du logiciel doivent permettre ladministration concerne dexaminer, dune part, lexistence ventuelle dautres solutions dont elle pourrait tirer profit230 et, dautre part, la proximit avec les besoins similaires dautres entits, au bnfice desquelles pourrait tre engag ultrieurement un processus de mutualisation en aval231. En valuant la probabilit dengager un tel processus, ladministration peut lanticiper efficacement, en soignant certains aspects mthodologiques et juridiques. 8.Dveloppement du logiciel par le C.I.R.B., et lintervention dun prestataire de services Facult douverture dautres utilisateurs La ralisation du logiciel a t confie par lAdministration de lEquipement et des Dplacements (ci-aprs A.E.D.) au Centre dInformatique pour la Rgion bruxelloise (ciaprs C.I.R.B.), lequel sy est employ grce au concours dun prestataire de services ; si lon fait abstraction de la relation particulire entre lA.E.D. (promoteur du dveloppement du logiciel) et le C.I.R.B. (qui assure la ralisation du projet), le dveloppement a donc t assur en partie par des agents du C.I.R.B., et en partie par un prestataire de services la demande dune administration seule. On observera, par ailleurs, que le prestataire de services est celui que le C.I.R.B. a dsign, au titre dun contrat-cadre, pour lensemble des marchs informatiques de lorganisme. Il ny a donc pas eu de passation dun march public de services propre cette opration de mutualisation. On se demandera si une telle pratique du recours au contrat-cadre saccommode de la ncessaire individualisation des conditions de tout march public, particulirement lorsquil porte sur le dveloppement dun logiciel dont les modalits dutilisation doivent tre dfinies par rfrence aux caractristiques dune situation dtermine.
230 231
Cf. rapport, n I et suiv.. Cf. rapport, n II et suiv..
107
Le recours un prestataire de services commande au pouvoir adjudicateur de concevoir un march public de services dont les conditions dattribution et dexcution lui permettront de se mnager, lgard de ce prestataire, une facult douverture des droits dutilisation de ce logiciel, au bnfice dautres entits avec lesquelles pourrait tre engag un processus de mutualisation en aval. Ces proccupations seront notamment rencontres par une identification soigneuse des titulaires des droits dutilisation du logiciel et un amnagement appropri de ces droits (recouvrant notamment les modalits daccs au code-source) 232. Cest ce stade que sera notamment value lopportunit de faire dvelopper le logiciel sous une licence de type G.P.L. 233. 9.Dveloppement du logiciel par le C.I.R.B., et lintervention dun prestataire de services Garanties dindpendance du pouvoir adjudicateur lgard du prestataire Actuellement, le projet est toujours en cours de dveloppement, mme si le logiciel a t partiellement mis en service au dbut de lanne 2007. Il semble dores et dj tabli que, si les clauses du cahier spcial des charges ont t rdiges de manire garantir le droit dutilisation au maximum dacteurs bruxellois concerns par cette politique de coordination des chantiers de voirie, la possibilit dutilisation du logiciel (ventuellement adapt) par dautres institutions (autres rgions, par exemple) parat, en revanche, trs incertaine. La perspective dune mutualisation en aval, assure par le C.I.R.B., sans recours ncessaire un prestataire de services semble compromise. Dune part, et bien que le code-source appartienne au C.I.R.B., les outils de dveloppement de ce code sont propritaires et seul le prestataire en a la matrise. Lindpendance du C.I.R.B. et une ventuelle volont de mutualisation en aval ne sont donc pas servies par une disposition approprie du code-source. Dautre part, il apparat dj que le fournisseur des logiciels cartographiques de base utiliss dans l'application nassurera plus, brve chance, le support de certaines composantes quil est, par ailleurs, le seul pouvoir assumer actuellement, et ce, prcisment, raison de lutilisation doutils en mode propritaire. Ici encore, il y a lieu de craindre que les conditions dindpendance de lutilisateur public ne soient pas rencontres. Indpendamment des proccupations lies louverture (future et hypothtique) dautres utilisateurs, le pouvoir adjudicateur doit veiller sassurer une indpendance suffisante lgard du prestataire, sans laquelle lidal de prennit (auquel sidentifie, certains gards, la mutualisation informatique) ne pourra tre rencontr, ni mme utilement servi. Lutilit dexigences particulires, en matire daccs au code source, ainsi que de lisibilit et de documentation de celui-ci, parat vidente cet gard234.
232 233
Cf. rapport, n III et suiv.. Cf. rapport, n VI et suiv.. 234 Cf. rapport, n III et suiv..
108
10.Mthodologie de ralisation et contraintes organisationnelles La complexit du projet (que traduisent notamment la multitude et lenchevtrement des fonctionnalits requises) et la ncessit de linscrire dans un planning de ralisation raisonnable ont conduit, dans un premier temps, rpondre aux besoins spcifiques de lA.E.D., tout en attirant lattention des autres acteurs concerns, sur les ressources que pourrait leur offrir le logiciel en un tat intermdiaire de dveloppement ; la prise en considration, dans un premier temps, des intrts respectifs de tous les acteurs concerns pouvait avoir pour effet de compliquer et, partant, de ralentir la conduite dun projet risquant dafficher une taille dmesure. Slection des besoins pris en considration, taille de projet et ralisme des dlais de mise en uvre ont donc conditionn la mthodologie de ralisation. Il se confirme donc, de ce point de vue, que le projet Iriscom correspond moins une opration de mutualisation se traduisant dans un investissement commun, rpondant des besoins diffrents mais suffisamment proches les uns des autres, que une ouverture des droits dutilisation du logiciel des acteurs quune lgislation contraint se rapprocher. Cest donc dans lamnagement des droits et modalits dutilisation du logiciel par plusieurs acteurs institutionnels que rside lapport fondamental de cette exprience ltude de la mutualisation informatique dans le secteur public. La mthodologie de ralisation dun projet et la prise en considration de sa dimension communautaire peuvent tre influences, dans une large mesure, par les contraintes politiques et organisationnelles de lun des initiateurs, particulirement lorsque celui-ci apparat occuper une position vidente de leadership, voire mme fait figure dacteur unique. Cette situation ne le dispense toutefois pas dorganiser soigneusement les droits et modalits dutilisation du logiciel au profit des autres acteurs concerns par les fonctionnalits du logiciel. 11.Collaboration entre partenaires publics. Quelles modalits dorganisation ? Entre les acteurs susceptibles de bnficier du logiciel, il a t convenu, aux termes dun accord officieux, que le dveloppement serait financ par la Rgion de Bruxelles-Capitale, tandis que les gestionnaires de rseaux supporteraient les cots de maintenance, concurrence dun montant maximum de 250.000 pour la premire anne. Cet accord officieux na toutefois pas encore donn lieu une convention crite; il semble que des incertitudes sur le type et la consistance exacte des prestations de maintenance (corrective ? volutive ?) soient lorigine dune certaine rticence des gestionnaires de rseaux, ntant pas assez assurs des ressources que leur offrira cette maintenance (notamment en ce qui concerne lactualit et la mise jour des donnes cartographiques). La russite dun projet associant (ft-ce uniquement en certaines de ses composantes) plusieurs partenaires publics dpend de la manire dont ceux-ci auront convenu dorganiser leur collaboration. Lopportunit de dfinir avec soin les droits et obligations respectifs sera envisage ; les aspects sur lesquels portera une ventuelle convention de collaboration seront soigneusement identifis et slectionns par les partenaires (valuation, affectation et imputations des ressources humaines et financires, modalits dorganisation du travail, libert dassocier dautres utilisateurs, ..) 235.
235
Cf. rapport, n VII et suiv..
109
110
Projet PloneGov236
1. Introduction
12.PloneGov est une communaut dadministrations ayant comme objectif de programmer des applications informatiques largement diffuses parmi des entits publiques. A ce jour, lassociation est en cours de programmation du logiciel plone-meeting. La fonctionnalit de lapplication informatique est la gestion de lordre du jour dun organe dcisionnel, lgislatif ou excutif (collge chevinal, conseil communal, Gouvernement wallon, Gouvernement de la Communaut franaise, ). En dautres termes, lapplication informatique couvre le work-flow du processus dcisionnel.
2. Dveloppement par une communaut de dveloppeursutilisateurs, informaticiens des administrations concernes

I. Aspects mthodologiques 13.Prospection du march Afin dentamer le processus de mutualisation sur les meilleures bases, une prospection des diffrents outils libres a t ralise. Les logiciels ayant fait lobjet de lanalyse comparative sont ceux qui sont mis en uvre chez les divers partenaires de PloneGov, tels que lEGW, Palamde ou encore la solution eCollge de la Commission europenne. Lapplication informatique ayant obtenu la prfrence de PloneGov a t le module de CommunesPlones. Par le biais de dmarches pralables au dveloppement de lapplication informatique, ladministration ou lassociation dadministrations lorigine du projet de mutualisation peut valuer lintrt dautres solutions dj ralises237 et se renseigner sur lexistence de besoins similaires auprs dautres entits publiques238.
236
Cette description de cas est base sur les propos tenus par G. DELANNAY lors du colloque sur la mutualisation informatique organise par le CRID le 25 mai 2007. 237 Cf. rapport, n I et suiv.. 238 Cf. rapport, n II et suiv..
111
14.Projet bas sur le modle existant CommunesPlones Le dveloppement du logiciel est ralis en interne, par plusieurs administrations, avec une perspective douverture ultrieure des droits dutilisation sous licence GPL. PloneGov a obtenu laccs aux droits dutilisation dune solution dj dtenue par un groupe d'administrations, avec une possibilit de modification du logiciel. Le projet PloneGov est donc bas sur une communaut existante : CommunesPlones, qui rassemble 15 communes ainsi que lUnion des Villes et Communes de Wallonie. Cette association de communes dploie son action vers dautres entits publiques telles que la Rgion wallonne ou la Communaut franaise. Lobjectif de PloneGov est similaire, tant donn que les applications informatiques qui seront cres par la communaut de dveloppeurs ont vocation tre mutualises, cest--dire utilises le plus largement possible. Les utilisateurs potentiels des logiciels de PloneGov sont des entits publiques qui prouvent des besoins informatiques similaires. De mme, le logiciel plone-meeting, en cours de dveloppement par PloneGov, a comme modle une application informatique qui a dj fait ses preuves au sein de CommunesPlones. Lide est base sur la cration dun logiciel libre auquel chacun peut apporter ses spcificits. Ds lors, la mutualisation est ralise en aval vis--vis de CommunesPlones car le projet initial est dj cr par lassociation de communes. Cependant, vis--vis de nouveaux participants qui se runissent pour assurer le dveloppement du logiciel plone-meeting, il y a lieu de considrer la mutualisation comme tant effectue en amont. Ladministration, qui opte pour le dveloppement dun logiciel en interne, sassure de disposer des comptences et des ressources suffisantes cet effet. Se baser sur un modle de mutualisation et sur une solution prexistante offre ladministration certaines garanties sur la ralisation du projet et sur la qualit du logiciel en cours de dveloppement. A ce stade, ladministration sassure dtenir les droits suffisants lui permettant de modifier sa guise lapplication informatique qui lui sert de modle et dviter de ce fait une revendication ultrieure par des tiers titulaires de certains droits sur le prototype239. 15.Calendrier et gestion du temps Les calendriers des participants sont ncessairement diffrents. Prochainement, les participants du projet se runiront hebdomadairement. Lchance de mise disposition du logiciel pour le Gouvernement wallon est janvier 2008. Une technique utilise est celle des sprints . Le sprint240 peut tre dfini comme tant une courte priode de programmation dun logiciel. A cette fin, tous les participants de PloneGov se runissent un intervalle de temps rgulier pour programmer le systme. Les intrts de chaque partie sont alors mis en avant. Cette technique est devenue populaire par le
239 240
Cf. rapport, n II et suiv. ; IV et suiv.. Voir la dfinition propose par http://en.wikipedia.org/wiki/Hackathon.
112 biais de divers projets de dveloppement dapplications informatiques cres afin dtre distribues sous licence Open source . Une autre technique utilise par PloneGov est celle du peer-programming qui consiste en des runions plus rduites, rassemblant uniquement les acteurs les plus expriments. Le peer-programming241 , galement appel le pair-programming , est une mthode par laquelle chaque participant va vrifier de quelle manire le code est crit et de quelle manire celui-ci est modifi au cours de ces runions. Un lment fondamental de la russite dun projet de mutualisation rside dans une organisation claire du temps de travail, dune part des dveloppeurs informaticiens, et dautre part des reprsentants des administrations membres au processus. Des runions peuvent tre organises cet effet. Le nombre de participants est limit afin de garantir une certaine productivit. Ces mthodes de travail sont soit informelles, soit organises par des accords de collaboration242. 16.Langages et standards PloneGove a voulu utiliser un langage qui ne soit pas un frein au projet de mutualisation. Ils ont opt pour la technologie Python, qui est encore peu connue mais dont le recours a dj doubl dans le monde. Il est galement prvu de crer certains liens avec le systme Alfresco , actuellement utilis par la Communaut franaise. Les technologies Zope et Plone font galement partie des langages choisis par PlonesGov. Le langage et les standards informatiques sont choisis pour assurer un dveloppement optimal du logiciel. Il y a lieu de vrifier la compatibilit de ces standards avec une ouverture des droits dutilisation sur lapplication informatique. Enfin, si la technologie est suffisamment rpandue, des prestataires extrieurs pourront assurer le suivi de lutilisation du programme243. 17.Affectation des ressources humaines au stade du dveloppement et de lutilisation ultrieure du logiciel Pour son fonctionnement, PloneGov fait appel, en sus des administrations concernes, la participation du priv pour le dveloppement des applications informatiques. Les ressources humaines sont gres de manire informelle. Lon fait appel aux techniciens en fonction de leurs comptences. PloneGov rassemble un groupe de quatre dveloppeurs de logiciels. Ils se runissent lordinaire deux par deux, en fonction de leurs disponibilits horaires. Une troite collaboration entre les dveloppeurs et les administrations concernes est ncessaire pour cibler les besoins spcifiques des entits publiques. La disponibilit des ressources humaines doit galement tre suffisante pour assurer louverture du systme
241 242
Voir la description du site http://www.techweb.com/encyclopedia. Cf. rapport, n VII et suiv.. 243 Cf. rapport, n IV et suiv..
113 auprs dautres utilisateurs. A cette fin, les entits publiques peuvent sengager assurer la mise disposition de ces ressources244. Il peut encore arriver que ladministration soit amene requrir la participation du secteur priv pour lui apporter un soutien technique lors du dveloppement ou lors de la maintenance du logiciel. Un contrat de prestation de services sera alors conclu cette fin. Lidentification de la partie contractante peut susciter des difficults lorsque la communaut nest pas structure en une personne morale distincte des administrations qui la constituent, et quaucune dentre celles-ci nentend jouer le rle de pouvoir adjudicateur245. 18.Besoins fonctionnels actuels et futurs A premire vue, les besoins fonctionnels des participants actuels sont similaires. Les besoins des utilisateurs futurs doivent se rvler suffisamment proches. En effet, la distorsion peut constituer un obstacle la mutualisation246. 19.Outillages facilitant la collaboration Les sites Internet CommunesPlone.org et PloneGov.eu sont des outils de partage. De plus, un site avec les logiciels on-line dvelopps par PloneGov va bientt tre cr. Le procd agile247, utilis par PloneGov, permet un cycle de dveloppement trs court. A chaque runion, un nouveau logiciel est cr. Cette mthode pragmatique ncessite une implication tendue des entits pour le compte desquelles lapplication informatique est ralise. Lobjectif ultime d agile est de rencontrer les besoins rels du client . Quatre valeurs fondamentales forment la base de la mthodologie : 1) Lquipe est au centre du processus. 2) Lapplication doit fonctionner. 3) La collaboration, entre toutes les parties impliques, est essentielle. 4) Lacceptation du changement de la planification initiale et de la structure du logiciel est ncessaire. La collaboration entre les entits participant au projet de mutualisation peut tre facilite par le recours des outils de partage tels que, par exemple, la cration dun site Internet sur lequel chacun peut dposer ses nouveauts et par des mthodes de travail adaptes248. Les mthodes de dveloppement dun logiciel, ou les outillages de collaboration peuvent ventuellement tre formalises au sein dun accord de collaboration249.
244 245
Cf. rapport, n IV et V. Cf. rapport, n IV. 246 Cf. rapport, n I et I. 247 Voir la description propose ladresse http://fr.wikipedia.org/wiki/M%C3%A9thode_agile . 248 Cf. rapport, n VI et suiv.. 249 Cf. rapport, n VII et suiv..
114 Il est prudent de dterminer qui sera responsable de ces outils collaboratifs250.
250
Cf. rapport, n VI.
115
II. Aspects juridiques 20.Cadre juridique inexistant Si louverture ultrieure du logiciel dautres utilisateurs est envisage par rfrence aux ressources quoffre la licence GPL, en revanche le cadre juridique de programmation des logiciels et de collaboration entre les utilisateurs-dveloppeurs est inexistant. Il peut tre naturel pour une administration de redouter la rigidit des outils juridiques. On ne peut cependant perdre de vue que ceux-ci ont comme objectif essentiel de limiter les conflits. Ainsi, des instruments juridiques telle quune convention entre partenaires publics pour dfinir les modalits de la mutualisation (parmi lesquelles lorganisation dun ventuel leadership251) peuvent tre bnfiques au projet252. 21.Programmes dvelopps sous licence GPL Etant donn que les applications informatiques sont dveloppes sous licence libre GPL, certaines questions, telles que celles portant sur la titularit des droits sur le logiciel ou sur les possibilits dadaptation de celui-ci nont plus dobjet. Chacun peut dailleurs modifier le programme, ajouter un lment nouveau selon ses spcificits et ses besoins propres. Cet aspect est, dans une certaine mesure, une garantie de la qualit de lapplication informatique puisque les programmeurs peuvent tout moment ajouter de nouvelles fonctionnalits. De la mme manire, chaque nouvel utilisateur sera en mesure dapporter ses spcificits au systme. Un des objectifs essentiels du projet de mutualisation est lobtention dune indpendance vis-vis des fournisseurs. Cet objectif semble atteint ds lors que le logiciel est dvelopp en interne et que la technologie utilise est celle de l Open source. Plus lindpendance est grande, plus louverture dautres utilisateurs est garantie. De plus, la communaut dadministrations acquiert une certaine comptence sur la technologie du logiciel. Ce qui permettra de ladapter en fonction des besoins des membres ou des nouveaux membres sans devoir faire appel un fournisseur particulier. Les cots sont rduits. Lapplication informatique est publie sous licence libre GPL. Nimporte qui dans le monde est donc mme dutiliser le programme. Ainsi, lon retrouve des utilisateurs de la technologie de CommunesPlones en France et en Amrique du sud. Les connaissances et les comptences sont dveloppes en interne. La qualit du logiciel dpend du ressort des informaticiens des entits participantes. Le projet maximise la collaboration volontaire. Les dveloppements personnels sont viter. Linnovation est favorise vu que chaque socit peut amliorer lapplication informatique. Le recours une licence GPL offre de nombreux avantages. Il y a cependant lieu dvaluer le risque rel davnement de forks puisque chaque programmeur peut
251 252
Cf. rapport, n V et suiv.. Cf. rapport, n VII et suiv..
116 amener de nouvelles fonctionnalits tout moment et puisque le nombre dutilisateurs est en constante volution. De la mme manire, des garde-fous et un amnagement juridique peuvent tre envisags pour certaines hypothses particulires (par exemple si un nouveau membre modifie lapplication informatique sans respecter les objectifs de la mutualisation) 253. Il faudra encore prvoir comment les nouvelles entits, qui nont pas forcment les comptences requises en interne, vont grer lutilisation de lapplication informatique. 22.Certification de la qualit du code source La certification par un tiers de la qualit de lapplication informatique nest pas prvue. Il peut tre judicieux pour lentit publique de prvoir des exigences de lisibilit des codes sources afin de garantir une utilisation relativement large de lapplication informatique. Ainsi, ladministration ne sera pas prise au dpourvu en cas de dpart dune ou de plusieurs personnes ayant particip au dveloppement du logiciel. Un tiers peut dailleurs intervenir pour valuer la qualit du code source254 .
253 254
Cf. rapport, n IV et suiv.. Cf. rapport, n III.
117
Projets IAM PAM, E-PROC et "portail des marchs publics"255
1. Introduction
23.La description des projets IAM PAM, E-PROC et "portail des marchs publics" permet de mieux identifier certaines questions propres la conduite dun projet de mutualisation en aval au dpart d'une seule administration, en ce quelles ont notamment trait aux difficults que peut susciter un tel projet un nombre plus large d'utilisateurs. 24.Dans le cadre du projet IAM PAM (informatisation et publication des avis de marchs publics), le MET cherchait concevoir un logiciel permettant la dmatrialisation de certaines tapes de la conduite dun march public ; il a initi seul lopration, dans le cadre de lexclusivit accorde au G.I.E.I., ce dernier stant lui-mme adress un prestataire de services (CAP GEMINI) afin de dvelopper le projet IAM PAM (informatisation et publication des avis de marchs publics). IAM est un logiciel mis la disposition des services du MET pour aider leurs agents dans la rdaction des avis de marchs publics, selon un mode d'encodage assist respectant les dernires normes belges et europennes en vigueur en matire de passation de marchs. Le formulaire complt alimente un site de publication centralisant les avis de marchs dans le respect des normes de concurrence, de transparence et de publicit en la matire (PAM). Ces avis sont en outre directement envoys au bulletin des adjudications (BDA) et, le cas chant, au Journal officiel de l'Union europenne (JOUE) pour publication formelle. Cet outil d'informatisation et de publication des avis de march dvelopp par et pour le MET en 2003 a ensuite t mis la disposition du MRW en 2005, de la Socit wallonne de Logement ainsi qu'aux Organismes dIntrt public rgionaux en 2006. Dans le cadre du plan "e-communes", le Ministre des Affaires intrieures et de la Fonction publique a galement propos en 2006 gratuitement la mise disposition de l'outil IAM PAM aux pouvoirs locaux (communes, C.P.A.S. et intercommunales). L'application IAM PAM permet donc une informatisation de la phase de lancement des marchs publics. La dmatrialisation intervient galement dans les tapes successives de la passation des marchs publics : dans la phase de remise des offres, par la cration d'une plateforme de remise lectronique des offres (E-PROC) via le "portail des marchs publics", et dans la phase d'excution des marchs (suivi comptable, catalogues lectroniques, ). Le projet E-PROC (initialement EPI), lanc par le MET, visait la cration d'un module de rception et de traitement des offres lectroniques au sein de ce ministre. Le projet EPI fut ensuite largi en collaboration avec le Commissariat EASI-WAL et intgr dans le cadre, plus large, de dveloppement d'une plate-forme gnrique de rception des offres lectroniques (EPROC), selon un processus de mutualisation en amont.
255
Ces descriptions de cas sont bases sur l'expos d'Etienne DAVIO, Expert juriste au Commissariat EASIWAL, lors du colloque sur la mutualisation informatique organis par le CRID le 25 mai 2007 Namur.
118 25.Dans le cadre du second projet prsent, le "portail des marchs publics", la Rgion wallonne et la Communaut franaise dveloppent en commun un "portail des marchs publics" utile lensemble de leurs services respectifs. Le but est donc de crer un portail commun ces deux entits. Il s'agit dans un premier temps d'un processus de mutualisation en amont, lequel pourra ensuite, comme pour le premier projet, tre ouvert un nombre plus large d'utilisateurs selon un mode de mutualisation en aval.
2. Projets IAM PAM et E-PROC (initialement EPI)

I. Aspects mthodologiques 26.Organisation de la mutualisation au sein de l'administration entre les diffrents utilisateurs : le Comit d'accompagnement du MET Le Comit d'accompagnement au sein du MET est la charnire actuelle de la mutualisation des expriences IAM PAM. Le comit d'accompagnement se runit environ une fois par mois pour des objets techniques prcis (encodage, validation, ). Ce comit d'accompagnement est actuellement en pleine croissance suite l'ouverture progressive de l'utilisation du logiciel un cercle plus large d'utilisateurs. La taille et les modalits dorganisation des structures de pilotage dun projet de mutualisation requirent une attention importante256. 27.Recours des logiciels "hybrides" (composantes propritaires et composantes libres) ou "homognes" (tout propritaire ou tout libre) Le prestataire qui a dvelopp IAM pour le MET (CAP GEMINI) assure ce dveloppement en langage propritaire, en utilisant nanmoins certaines composantes disponibles sous licence libre. 28.Opportunit d'un transfert de tous les droits du prestataire au bnfice de l'administration Le logiciel est considr comme la proprit de la Rgion wallonne, mais le dveloppement en langage propritaire anantit (ou, tout le moins, rduit sensiblement) lintrt de disposer de droits apparemment aussi tendus sur le logiciel. Quelles conditions la Rgion wallonne peut-elle exiger par rapport au prestataire de dpart dans le cadre d'un nouveau march (E-PROC et marchs publics) afin de garantir une mise en concurrence la plus "totale" possible? Peut-elle exiger la remise
256
Cf. rapport, n V et suiv..
119 des codes sources (dans une forme utilisable par les nouveaux prestataires ventuels) tous les prestataires potentiels? Ceci ne pallie toutefois pas l'avantage dont bnficie dj le prestataire de dpart grce l'exprience acquise en la matire257. II. Aspects juridiques 29.Organisation de la mutualisation au sein de l'administration entre les diffrents utilisateurs : le Comit d'accompagnement IAM-PAM Son fonctionnement n'est pas (encore) formalis (absence de forme juridique, organe informel). Le besoin d'une organisation plus rigoureuse cohabite avec une certaine volont de maintenir en l'tat une formule, assez souple, mais qui a jusqu' prsent bien fonctionn. Il s'agira de concilier ces deux prises de position l'avenir. Davantage de structure permettrait sans doute le lancement de nouveaux projets selon un mode de mutualisation en amont. La ncessit d'une structure approprie au projet de mutualisation peut se faire sentir. Il existe diverses possibilits envisager lors de la cration d'une structure : celle-ci peut tre institue au sein dune des entits partenaires258 ou tre distincte de lensemble de celles-ci259. Dans cette dernire hypothse, un certain nombre de modalits supplmentaires doivent tre rgles (mode de fonctionnement, cots, reprsentation de chaque participant, lgitimit du coordinateur, forme juridique). Il est enfin utile d'examiner si cette (nouvelle) structure peut tre propritaire de l'application et comment une application de type propritaire se concilie encore avec un nombre plus large d'utilisateurs. 30.Accs au code source et garantie de sa qualit La Rgion wallonne sest garanti la mise disposition des codes sources. Elle ne serait ds lors pas dpendante du prestataire de services quant l'accs au code source et sa mise disposition ventuelle d'autres usagers ultrieurs. La disposition des codes sources est recherche pour chapper aux situations de monopoles de fait dont bnficient les prestataires lors de dveloppement en mode
257
Cette observation ne semble pas incompatible avec larticle 78 de lA.R. relatif aux marchs publics de travaux, de fournitures et de services et aux concessions de travaux publics du 8 janv. 1996, M.B., 26 janv. 1996 : 1er. Doit tre carte, la demande de participation ou l'offre introduite pour un march public de travaux, de fournitures ou de services, par toute personne qui a t charge de la recherche, de l'exprimentation, de l'tude ou du dveloppement de ces travaux, fournitures ou services, si du fait de ces prestations, cette personne bnficie d'un avantage de nature fausser les conditions normales de la concurrence [...]. 2. De mme, doit tre carte la demande de participation ou l'offre introduite pour un march public par une entreprise lie une personne vise au 1er lorsque cette dernire a t pralablement charge de la recherche, de l'exprimentation, de l'tude ou du dveloppement des travaux, des fournitures ou des services sur lesquels porte ce march, si du fait de ce lien, cette entreprise bnficie pour ce march d'un avantage de nature fausser les conditions normales de la concurrence [...]. 258 Cf. rapport, n V et suiv.. 259 Cf. rapport, n III et suiv..
120 propritaire260. Le code tant ouvert, le jeu de la concurrence jouera sans garantie dun avantage pour le prestataire initial. Il convient de modaliser les rapports avec le prestataire afin d'viter la dpendance de l'administration (absence de choix du prestataire, pas de proprit des codes sources) ou la "faillite" du prestataire dans le cadre de la cration d'une nouvelle structure. Ceci pose la question de l'quilibre contractuel entre le prestataire et le pouvoir adjudicateur dans le cadre dun march de dveloppement dun logiciel dans un contexte de mutualisation. Ce march sera-t-il conu au dtriment du prestataire, qui cde tous ses droits au pouvoir adjudicateur propritaire du logiciel ou au dtriment des pouvoirs adjudicateurs qui devraient payer plusieurs fois la mme prestation ("mutualisation par la demande"/"mutualisation par l'offre"). Dans une logique propritaire, le transfert de la proprit la Rgion va de pair avec une adaptation du prix (ncessairement plus lev). Le critre prix va jouer le rle d'quilibrage contractuel261. 31.Objet du contrat, tendue des droits transfrs d'autres utilisateurs et monopole du prestataire de services Le logiciel est considr comme la proprit de la Rgion wallonne Il s'agit principalement d'un type de mutualisation en aval. L'application informatique dveloppe (selon l'intervention du G.I.E.I.) par et pour le MET seul au dpart, a ensuite t largie gratuitement au MRW, la SWL, aux Organismes dIntrt public et aux pouvoirs locaux. Cette extension de la mise disposition de ce logiciel parmi les diffrents dpartements de la Rgion wallonne ne semble pas poser de problmes de concurrence dans la mesure o la Rgion est propritaire de ce logiciel. Il n'en va pas de mme quant l'utilisation de ce mme logiciel par les organismes dintrt public et par les pouvoirs locaux, personnalits juridiques distinctes, qui ne bnficient pas automatiquement des mmes droits patrimoniaux que la Rgion wallonne. La cration d'un portail international en la matire ( un stade ultrieur) s'avre toutefois, selon les intervenants, difficile en pratique (mutualisation en amont). La nature des droits de la Rgion wallonne sur le logiciel et leur mode de cession permet leur mise disposition soit gratuite soit onreuse un cercle plus large d'utilisateurs sans mise en concurrence pralable. Il en irait sans doute autrement si la Rgion n'tait pas propritaire de ce logiciel. Cette ouverture de nouveaux utilisateurs incite se demander si, en cas dadaptation aux besoins spcifiques dun nouvel utilisateur potentiel, celui-ci doit recourir exclusivement au prestataire dorigine (CAP GEMINI, en loccurrence) ou sil peut ouvrir le march dautres oprateurs conomiques262 ?
260 261
Cf. rapport, n III et suiv.. Cf. rapport, n III. 262 Cf. rapport, n I et suiv..
121 La question de la responsabilit de la Rgion wallonne peut enfin tre invoque si une procdure denvoi davis de marchs aux organes officiels choue raison dune dficience du logiciel263.
3. Projet de "portail des marchs publics" commun la Rgion wallonne et la Communaut franaise
I. Aspects mthodologiques 32.Opportunit d'un march public conjoint La Rgion wallonne et la Communaut franaise souhaitaient initialement recourir la forme du march public conjoint, lequel semblait le plus adquat au projet de mutualisation et le plus transparent l'gard des prestataires de services quant aux implications relles du march. En raison du peu d'exprience de cette procdure l'heure actuelle (dlais, matrise de ce type de march), une solution plus scuritaire fut adopte provisoirement, savoir le recours un march public traditionnel avec un seul pouvoir adjudicateur, la Rgion wallonne en l'espce. Le march public conjoint reprsente-t-il la solution la plus adapte (transparence, convention financire, diminution des cots) 264? II. Aspects juridiques 33.Cadre juridique pralable un dveloppement commun La Rgion wallonne et la Communaut franaise ne sont lies que par la volont de collaborer ensemble. Il n'existe pas d'accord proprement dit de coopration entre elles ou d'autres structures juridiques communes qui servirait de base la passation d'un march conjoint en l'espce. Il semblerait toutefois quune dcision issue d'un gouvernement conjoint Communaut-Rgion retenait le principe d'une collaboration dans la matire des marchs publics. Le march est gr et financ par le Commissariat EASI-WAL de la Rgion wallonne, propritaire du logiciel, avec la possibilit d'en cder l'usage la Communaut franaise dans le cahier des charges. Cette mention dans le cahier des charges favorise un maximum de transparence de la procdure vis--vis des prestataires et leur permet de mettre en balance l'investissement et les dbouchs commerciaux que l'obtention d'un tel march impliquerait pour eux. En contrepartie, la Communaut franaise prend en charge, dans un esprit de bonne
263 264
Cf. rapport, n I et suiv.. Cf. rapport, n VIII et suiv..
122 collaboration, dautres dpenses lies lopration, mais ne relevant pas ncessairement du march sensu stricto (telles que les marchs relatifs la certification du notaire, au graphisme du portail, la ralisation d'un guide des marchs publics, ). Il peut tre envisag que le prochain march soit financ par la Communaut franaise, charge pour la Rgion wallonne d'en assumer certaines dpenses priphriques. Ceci permet ainsi de se rpartir le travail et les cots en alternance entre pouvoirs adjudicateurs. La Rgion wallonne peut cder ses droits ou en cder l'usage en cas de proprit du logiciel. La solution peut tre plus dlicate en cas de droit d'usage (partiel) sur le logiciel. Il convient, comme dans le cas du premier projet, de garantir l'quilibre contractuel entre les administrations et les prestataires de service (indpendance et risque financier moindre des parties). Comment enfin assurer la mise disposition effective du logiciel (code source) dans le cadre de la mutualisation en aval265?
265
Cf. rapport, n I et suiv. ; et suiv..
123
Projet GILS
1. Introduction
34.Le projet GILS (Gestion Informatique du Logement Social) a vu le jour au dbut des annes 1990, lorsque les prestataires de services informatiques, actifs dans le secteur du logement social (essentiellement compos de petites socits), dcident les uns aprs les autres de se retirer. Les socits de logement social expriment un sentiment dabandon et une prise de conscience de la fragilit de leur situation, compte tenu de leur dpendance lgard des prestataires. Certaines socits de logement social avaient dvelopp leur propre systme informatique, dautres avaient fait appel divers prestataires privs. Face aux difficults dues cet abandon, les socits de logement social dcident de se regrouper pour crer GILS afin de dvelopper et maintenir un logiciel spcifique. En 1994, quinze socits de logement social (sur les 33 actives en rgion bruxelloise) se joignent au projet.
2. Dveloppement par un prestataire de services la demande de plusieurs administrations

I. Aspects mthodologiques 35.Forme et structure du partenariat GILS a pris la forme dune ASBL. Les structures de GILS veillent impliquer les utilisateurs dans la gestion du projet. Plusieurs groupes de travail (Ples Expertise Mtier) dterminent les orientations de dveloppement du logiciel. Les utilisateurs y sont reprsents, ce qui garantit une adquation des dveloppements par rapport aux besoins fonctionnels. Des parrains sont dsigns par rapport chaque mtier dans chaque socit de logement, ce qui permet de soulager les informaticiens de GILS (en offrant un premier niveau de maintenance et en permettant de rsoudre sans GILS des problmes dj rencontrs). Mutualisation informatique dans le secteur public
124
Llaboration dun projet de mutualisation incite valuer lopportunit doffrir celui-ci le support que reprsenterait une structure institutionnelle et examiner comment les modalits de fonctionnement de celle-ci permettent au travers de modalits de collaboration, concertation et participation, le cas chant de rencontrer les attentes des utilisateurs de logiciels dvelopps dans le cadre de lexprience de mutualisation266. 36.Dveloppement du logiciel Jrme Le logiciel Jrme , dvelopp par GILS, la t par le recours partiel aux services dun prestataire externe priv. Trois informaticiens employs de GILS ont collabor avec trois consultants, qui dirigeaient le travail. Le logiciel a t oprationnel en 1997. Le recours un prestataire extrieur, dans le cadre dun march public de services peut tre envisag selon des modalits de collaboration avec le pouvoir adjudicateur, modalits qui permettent celui-ci de soffrir des garanties dindpendance lgard du prestataire267. 37.Financement Les cots du projet sont rpartis entre les membres selon une cl de rpartition assurant une certaine solidarit entre les socits de logement, le but tant de permettre une informatisation des petites socits de logement un cot raisonnable. La cl de rpartition est la suivante : 15% des cots sont rpartis de manire gale ; le surplus est rparti en fonction dune cl de rpartition base sur le nombre de postes de travail et le nombre de logements sociaux grs.
Lexprience a montr que cette formule de rpartition fragilise le systme en cas de dpart dune grosse socit de logement, car cela dsquilibre la rpartition des cots. Les nouveaux membres doivent en outre acquitter un droit dentre. La conception dun projet de mutualisation ayant vocation sinscrire dans le long terme incite avoir gard la viabilit financire de lexprience et, par le biais des contributions financires des partenaires publics, la dfinition des engagements que ces partenaires publics accepteront dassumer. Lopportunit dun cadre de collaboration est ainsi rvle268.
266 267
Cf. rapport, n II et suiv.. Cf. rapport, n III et suiv.. 268 Cf. rapport, n VII et suiv..
125 38.Evolution du projet Le logiciel Jrme 1 (bas sur Power Builder) prsente des faiblesses quant la stabilit du code par rapport aux adaptations rendues ncessaires par les changements de rglementation dans le logement social. Un consultant externe prne un changement de langage pour Jrme 2 , ce qui pose des difficults vu le manque de ressources internes disposant de comptences sur ce nouveau langage. Il est donc dcid de retourner la formule initiale de ralisation de Jrme 1 : lquipe interne est rduite et il est davantage fait appel des prestataires externes. La ncessit dapprhender un projet dans sa globalit se traduit notamment dans la prise en considration des lments suivants : attention accorde la veille rglementaire ; valuation des ressources humaines internes pour le support du logiciel269; opportunit et critres du choix entre prestations en rgie et recours aux marchs publics.
II. Aspects juridiques 39.Droits sur le logiciel La question des droits sur le logiciel est videmment cruciale. A cet gard, la convention avec le prestataire externe ( Jrme 1 ) prvoyait un partage de droits entre GILS et le prestataire. Cette rpartition na pos aucun problme, chacune des parties tant libre dexploiter sa guise le logiciel dvelopp. Tout contrat (ou march, en loccurrence) doit mnager, pour le pouvoir adjudicateur, des ressources permettant celui-ci de jouir de droits relatifs la proprit intellectuelle appropris aux perspectives de mutualisation270. 40.Relations entre membres Lexprience a montr que labsence de dispositions conventionnelles rglant la question du dpart de membres posait problme quant aux modalits dun tel dpart (dlai de pravis, etc.). La prvention de situations inimaginables au stade de la formation de la communaut et de la conception du (des) projet(s) requiert-elle une dfinition
269 270
Cf. rapport, n VII et VII. Cf. rapport, n VIII.
126 contractuelle des solutions applicables ? Le recours la structure contractuelle de mutualisation fait donc dbat.
127
Projet LiberAccs271
1. Prsentation du projet
41.Le projet LiberAccs est n du besoin grandissant pour les pouvoirs locaux en France d'une modernisation de l'informatisation permettant de mieux communiquer l'intrieur de la collectivit pour mieux communiquer l'extrieur et permettre de meilleurs changes de donnes entre les diffrentes applications informatiques disperses suivant les diffrents mtiers, et de favoriser ainsi plus d'interoprabilit. Consciente de cette ncessit, la Communaut dAgglomration de La Rochelle a entam un processus de mutualisation informatique, avec dautres communauts de la Rgion Poitou-Charentes ayant des besoins indiscutablement similaires. A cette fin, toute une panoplie de logiciels, existant dj sous licence libre ou devant tre dvelopps par un prestataire extrieur, sera mise la disposition des pouvoirs locaux. Le principe est fond sur une base dapplications informatiques communes, laquelle chaque entit va rajouter des lments fonctionnels en tenant compte de ses besoins rels. La mutualisation envisage est en amont pour les entits lorigine du projet et en aval pour les futures communes utilisatrices des logiciels.
2. Dveloppement par des prestataires de services la demande de plusieurs administrations partageant linvestissement ou utilisation dune solution dj existante :
42.L o aucune solution informatique nexiste, il sagit de faire appel, dans le cadre dun march public, un prestataire de services tranger la structure de mutualisation, pour le dveloppement dun logiciel. En revanche, si de telles solutions existent et apparaissent satisfaisantes aux yeux des animateurs de LiberAccs, il peut tre envisag dy recourir, ce qui sera dautant plus commode si elles sont distribues sous licence libre (= Open source). Enfin, la promotion de logiciels propritaires peut tre envisage par LiberAccs, pour autant quils rpondent certaines exigences relatives leur intgration dans la suite bureautique LiberAccs et leur articulation avec les autres composantes de cette suite. A terme, toute application doit tre distribue sous licence Open source. A cette fin, les cahiers de charges tablis dans le cadre de marchs de services de dveloppement de logiciels prvoient la diffusion de ceux-ci selon le modle libre. Le dveloppement seffectue dans le cadre dune structure institutionnelle par le biais dun G.I.E. (groupement dintrt conomique).
271
Nous remercions Madame Peudupin et Messieurs Rocq et Soulier pour leur clairante prsentation du projet et les intressants changes qui ont eu lieu au cours de notre rencontre du 1er juin 2007 La Rochelle.
128
Chaque membre du G.I.E. peut dvelopper un programme et le mettre la disposition de la communaut. I. Aspects mthodologiques 43.Proximit des besoins fonctionnels Les fondateurs du projet ont voulu dvelopper le processus de mutualisation parce que des besoins identiques ont vu simultanment le jour au sein de diverses entits publiques. Le projet est ainsi fond sur la prise en considration de ces besoins et de leur proximit, la mutualisation informatique tant alors considre comme une solution approprie au problme pos272. 44.Mthodologie dvolution Afin de garantir la russite du projet et de proposer des logiciels techniquement performants, les fondateurs optent pour un dveloppement du processus en chelle. Ainsi, les techniques offertes par lintranet seront ouvertes tous lorsquelles seront dune qualit irrprochable. De la mme manire, ce nest que lorsque le bureau virtuel sera performant que lon songera lvolution vers le guichet virtuel. Le recours une mthode progressive permet dassurer une matrise de louvrage. Procder de manire prudente est certainement une bonne mthode de ralisation dun projet de mutualisation. Elle impose cependant de sassurer que les besoins futurs sont pris en compte ds la mise en route du projet et, pour ce faire, dvaluer ces besoins 273. Cela fait effectivement partie de la dmarche de LiberAccs. 45.Logiciels libres et logiciels propritaires A lorigine, le projet est n de lobservation de logiciels libres, distribus sous licence G.P.L. et dont les qualits techniques et la philosophie base sur le partage, ont plu aux initiateurs du projet de mutualisation. Lintrt suscit par le modle libre nexclut pas que le modle propritaire soit cart demble : lutilisation dun logiciel libre prexistant ne sera prconise que sil est plus avantageux quun logiciel comparable, diffus suivant le modle propritaire . La qualit est ds lors prpondrante et prioritaire sur le mode de distribution. Cette abstention dadopter rsolument un mode de diffusion, lgard de solutions dj diffuses sur le march nexclut pas ainsi que cela a t relev prcdemment que le dveloppement, linitiative de LiberAccs, de logiciels nouveaux soit exclusivement conu dans une perspective de diffusion sous licence libre.
272 273
Cf. rapport, n I et I. Ibid.
129
Les questions lies au choix entre modles libre et propritaire de diffusion feront naturellement lobjet de traitements spcifiques selon quelles sont poses propos de solutions qui existent dj 274 ou, au contraire, quelles doivent seulement tre dveloppes 275. 46.Affectation et disponibilit des ressources humaines au stade du dveloppement et pour assurer louverture Une communaut de programmeurs sest dveloppe au sein de lagglomration de communes. Dabord informelle, cette communaut est en phase de structuration. Un des objectifs de la mutualisation est que la mise jour des logiciels et la formation leur utilisation puissent tre assures en interne. En revanche, le dveloppement en interne nest pas envisag au stade actuel du projet ; des marchs doivent donc tre passs afin de bnficier de lassistance de prestataires extrieurs la structure de mutualisation. Lorsquun contrat est pass avec un prestataire tranger la structure de mutualisation, un risque de dpendance technique est toujours craindre. Ce risque peut tre rduit lorsque la structure dispose, en interne, de ressources lui permettant notamment dassurer le support du logiciel276. 47.Taille du groupe au stade du dveloppement Au dpart, la mutualisation informatique est ne de linitiative dune agglomration de communes du dpartement de la Charente-Maritime. Une communaut dutilisateurs potentiels intgrant dautres entits sest alors constitue ; cest cette communaut qui a ensuite dfini les projets pour lesquels la mutualisation peut tre envisage. En une phase ultrieure, ces entits ont peru la ncessit de formaliser la collaboration et de donner celleci un support durable ; ce support apparat comme une condition essentielle de louverture dautres acteurs. Sagissant de la communaut dutilisateurs, elle est indtermine, puisque les logiciels dvelopps sont librement accessibles sur forge277. 48.Mode de financement Le projet de mutualisation est financ par des subventions nationales et europennes, dune part, et par les futures cotisations des membres affilis au G.I.E., dautre part. Ces ressources ont vocation rmunrer le personnel qualifi en interne et couvrir les frais exposs dans le cadre des contrats avec les prestataires extrieurs dassistance technique. Le libre nest en effet pas gratuit.
274 275
Cf. rapport, n X et suiv.. Cf. rapport, n IV et suiv.. 276 Cf. rapport, n III et suiv.. 277 Cf. rapport, n IV.
130 Les animateurs de LiberAccs sont galement conscients de la ncessit de dfinir, moyen terme, un mode dvaluation des contributions (notamment en ressources humaines) assures par certains membres, dans la conduite des projets. Un plan financier dtaill est essentiel pour lvaluation du projet de mutualisation. Il conditionne la viabilit et la prennit de la structure de mutualisation, et peut constituer un indicateur des contributions assures par certains membres de manire ce que la dimension collaborative de la dmarche de mutualisation soit rencontre de faon quitable ou, tout le moins, transparente. 49.Exigence de lisibilit du code source Lorsque la solution existe dj et quelle est distribue sous une licence libre de type G.P.L., laccs aux codes sources est garanti. Les entits participant au projet de mutualisation sont conscientes de limportance dune bonne lisibilit des codes sources et de la documentation y affrent. Il est relativement frquent que les codes soient dune grande complexit technique et que seuls des informaticiens hautement qualifis soient en mesure de les lire et de les modifier. Les pouvoirs locaux doivent alors veiller dtenir ces comptences en interne ou contracter avec un prestataire extrieur, capable de lire les codes en question. Si le prestataire en cause est le dveloppeur programmeur de lapplication informatique, un problme de dpendance des pouvoirs locaux risque de se poser. Sassurer une bonne lisibilit du code est ncessaire pour se garantir une vritable indpendance technique. La documentation concernant le code est, cet gard, prpondrante278. 50.Choix des langages et standards en fonction du dveloppement et de louverture La mutualisation portant sur diffrents programmes, plusieurs standards sont utiliss. Un document reprenant les diffrents standards est distribu aux diffrentes communes participant au processus de mutualisation. Chaque entit opte alors pour les solutions qui lui conviennent. II. Aspects juridiques 51.Marchs publics Les entits publiques font appel des oprateurs conomiques pour le dveloppement dapplications informatiques. Un contrat de prestation de services est conclu. La lgislation sur les marchs publics est applicable. Pour la maintenance du logiciel, les entits publiques recourent dans certains cas aux prestataires ayant dvelopp le programme, mme si les responsables de LiberAccs veillent ce que ces tches puissent tre assures en rgie pour limiter le risque de dpendance.
278
Cf. rapport, n IV et suiv..
131 Si le prestataire en charge de la maintenance est galement celui qui a programm lapplication informatique, un risque de dpendance existe pour les entits publiques. 52.Cration dun G.I.E. : traduction juridique de la mthodologie Les responsables de LiberAccs ont opt pour le dveloppement du projet de mutualisation par le biais dune structure institutionnelle, qui leur parat ncessaire pour garantir la stabilit de la mutualisation et la permanence des supports dans un environnement libre ayant naturellement vocation voluer. Dans cette perspective, un G.I.E. est en voie de cration. Le travail se voulant collectif, lobjectif est de solidifier les liens entre les divers partenaires. Trois types de membres sont prvus au sein du G.I.E. : les membres affilis paient une cotisation et jouissent de certains droits que leur confre cette qualit (15% des droits de vote et accs linformation relative aux projets en chantier) ; les membres actifs fondateurs disposent de 60% des droits de vote ; enfin, la quotit de vote restante est attribue aux membres actifs. Une tude pralable par un cabinet davocats a t ralise avant dopter pour la structure dun G.I.E. Celle-ci sest rvle tre la plus adapte aux besoins de la mutualisation. Elle permettait aussi, et surtout, dviter les inconvnients que dautres formes de structures laissaient apparatre. Tel est, par exemple, le cas du syndicat mixte , qui tait exclu en lespce, ds lors que la lgislation interdit la participation dun syndicat mixte dans un autre syndicat mixte et que, prcisment, un syndicat mixte (SMIC17) est dj membre de LiberAccs. Puisque les membres affilis doivent payer une cotisation, lon pourrait se demander si celle-ci ne constitue pas la rtribution dguise de lutilisation dun logiciel dvelopp linitiative de LiberAccs et si, raison de ce qui apparatrait ainsi comme rvlant un caractre onreux, lon ne doit pas procder la passation dun march public. Outre que la licence dutilisation dun logiciel doit tre considre comme reprsentant lamnagement contractuel dun droit patrimonial et non pas comme un contrat de prestation de services279, il y a lieu de rappeler que les logiciels sont librement accessibles sur la forge, et ce, indpendamment de la qualit de membre du G.I.E.. Le paiement dune cotisation est donc, en lespce, sans incidence sur lapplication de la lgislation relative aux marchs publics. Une autre problmatique est celle du choix de linstitution. Avant dopter pour lune ou lautre structure, il est requis de procder une tude pralable des possibilits en fonction des besoins et des objectifs de la mutualisation280. 53.Utilisation de logiciels libres et structure institutionnelle de mutualisation Lobjectif est de sassurer une matrise de louvrage. Or, tant donn que la licence libre garantit laccs aux codes sources, la possibilit de modification de lapplication informatique et sa maintenance sont assures.
279 280
Cf. rapport, n I et suiv.. Cf. rapport, n III et suiv..
132 Conscients de certains risques que peut reprsenter le recours un modle libre et de la ncessit de canaliser les initiatives individuelles des utilisateurs, les animateurs de LiberAccs dsirent, par le biais de la structure institutionnelle, limiter les dbordements dun tel modle. Ainsi, lorsquune municipalit souhaitera dvelopper ou modifier un logiciel dans le cadre du projet de mutualisation, elle devra ncessairement en demander lautorisation au G.I.E. Si le travail en Open source offre une grande libert aux utilisateurs, ceux-ci doivent adopter une attitude plus responsable face au projet de mutualisation. Le recours au modle du libre entrane invitablement certains risques, tels que les forks281, lincompatibilit de certaines licences, ou le recours des lments copylefts 282. De plus, le dveloppeur sest gnralement rserv une exonration de garantie relativement large. Des mesures doivent ds lors tre prises afin de contrer effectivement ces risques, par exemple en limitant une utilisation et une modification effrne de lapplication informatique. 54.Si la solution existe dj : qualification de la relation en cas doctroi de licence : march public ou autre ? Lorsquils contractent dans le cadre dune licence, les utilisateurs ne doivent pas, en dpit de leur qualit de pouvoir adjudicateur, appliquer la lgislation sur les marchs publics car la licence est considre comme lamnagement contractuel dun droit patrimonial et non pas comme un contrat de prestation de services283. 55.Clauses et modalits de dsignation des utilisateurs La Communaut dAgglomration souhaite que les logiciels faisant lobjet de la mutualisation, puissent tre distribus sous licence libre. Le recours une telle licence dispense de dsigner formellement les utilisateurs dun logiciel que LiberAccs fait dvelopper. La communaut dutilisateurs a vocation tre la plus large possible. Les entits publiques souhaitant participer activement au projet de mutualisation devront cependant devenir membres du G.I.E. La ncessit de dsigner les utilisateurs dun logiciel dont le dveloppement fait lobjet dun march public de services nest pas rencontre lorsquil rsulte du cahier des charges que le logiciel sera diffus sous licence libre284.
281 282
Cf. rapport, n IV et suiv.. Cf. rapport, n IV. 283 Cf. rapport, n IV. 284 Cf. rapport, n IV.
133
Projet e-Catalogue285
1. Introduction
56.Le projet e-Catalogue a t conu comme une exprience de mutualisation dans le domaine de le-Procurement (dmatrialisation des procdures lies la passation et lexcution des marchs publics). 57.Il sagissait de faire dvelopper, dans le cadre dun march public de services, un logiciel de gestion dun catalogue lectronique de fournitures courantes. La perspective de voir prochainement un tel produit rpondre aux besoins dun trs grand nombre dutilisateurs ( savoir tous les pouvoirs adjudicateurs) incitait naturellement concevoir pareil projet dans le cadre dune pratique de mutualisation permettant notamment un partage des cots dinvestissements et la mise disposition de petits pouvoirs adjudicateurs pour lesquels le dveloppement isol de telles solutions logicielles parat fastidieux (tant pour la charge financire que pour ce qui concerne la conduite du projet). Inspir par lidentification de besoins communs de nombreux pouvoirs adjudicateurs, un projet de mutualisation informatique peut se voir assigner plusieurs objectifs. 58.Le souci de mener lexprience progressivement a incit ses initiateurs (deux pouvoirs adjudicateurs relevant respectivement des administrations centrales belge et franaise) faire dvelopper le logiciel linitiative de deux pouvoirs adjudicateurs, en anticipant la perspective douverture des droits dutilisation du logiciel dautres entits relevant de tous les Etats-membres de lUnion europenne. Ce projet e-Catalogue sanalyse ainsi en une hypothse de dveloppement dun logiciel par un prestataire de services la demande de plusieurs administrations partageant linvestissement286. 59.Initi lors de la confrence e-Government de Manchester (fin 2005), le projet e-Catalogue na pu aboutir en tant que pratique de mutualisation en amont (cest--dire pour ce qui concerne le dveloppement linitiative de plusieurs administrations). Le march a t pass linitiative du seul pouvoir adjudicateur belge. Le logiciel est dvelopp dans le cadre dune licence Open source qui permet denvisager une perspective de mutualisation en aval.
285
Cette description de cas est base sur lexpos prsent par J.-P. Gennotte (S.P.F. P-O BELGIQUE) lors dun sminaire organis par le CRID le 14 mars 2007, et sur divers changes tenus entre septembre 2006 et janvier 2007 avec J.-P. Gennotte et E. Lanaspa (D.G.M.E. France). 286 Cf. rapport, n III et suiv..
134
2. Dveloppement dun logiciel par un prestataire de services la demande de plusieurs administrations partageant linvestissement
I. Aspects mthodologiques
60.Identification des besoins La similarit des droits et pratiques dachat public dans les diffrents Etats-membres de lUnion europenne a rapidement conduit identifier des besoins fonctionnels proches pour la gestion de catalogues lectroniques de fournitures. Cette similarit explique que les deux administrations belge et franaise concernes aient pu rapidement procder cette identification et conclure lopportunit dune exprience de mutualisation. La perspective de gnralisation prochaine de lusage dun tel outil suggre ds le lancement du projet de mutualisation limportance du nombre dutilisateurs futurs. La prise en considration des besoins actuels et futurs auxquels le dveloppement dun logiciel aura vocation satisfaire est ncessaire tant pour organiser le dveloppement linitiative de plusieurs entits (mutualisation en amont) que pour anticiper louverture ultrieure dautres utilisateurs287. 61.Communauts de langages, concepts et systmes juridiques Dans llaboration du projet de mutualisation, les administrations concernes ont t confrontes aux difficults que suscitent les diffrences entre les droits nationaux et les systmes juridiques : chaque partenaire doit tenir compte des impratifs inhrents au fonctionnement de son administration, lesquels impratifs ne sont pas ncessairement compatibles avec ceux de lautre entit. En lespce, les difficults taient notamment suscites par les diffrences entre les procdures de paiement qui ont respectivement cours en France et en Belgique. Un contexte dans lequel les profils respectifs des diffrents partenaires ne peuvent saccorder suffisamment nest pas propice la russite de lexprience de mutualisation. Ce constat vaut pour la langue de travail, les mthodes et langages de dveloppement, les systmes administratifs, les cadres normatifs, Si un tel obstacle parat vident dans un partenariat international (tel celui dans lequel sest inscrit le projet e-Catalogue), il ne peut tre nglig dans un projet regroupant, au sein dun seul Etat, des administrations de niveaux et statuts diffrents (tel un dpartement de ladministration centrale et un organisme dcentralis).
287
Cf. rapport, n I et suiv..
135
62.Affectation et rpartition des ressources humaines et financires Conscients de la question et de la ncessit de laborder ds le lancement du projet, les partenaires publics nont nanmoins pas pu saccorder sur leurs contributions respectives tant financires quen ressources humaines. Laffectation de ressources humaines concernait tant la phase dacquisition du logiciel que celle de son exploitation ; la prise en charge financire du dveloppement du logiciel (et de services auxiliaires) devait tre envisage tant pour linvestissement initial (par les deux administrations) que pour une couverture partielle de cet investissement par les contributions de nouveaux utilisateurs. La dfinition de modles contributifs doit tre envisage ds la conception du projet et tenir compte des perspectives que suggrent dventuelles phases ultrieures288. 63.Calendrier et gestion du temps Des contraintes budgtaires (ncessit dengager, dans un dlai dtermin, les crdits affrents au march de dveloppement du logiciel) ntaient pas compatibles avec le temps requis pour la dfinition du cadre juridique et organisationnel du projet. De nombreuses questions suscitaient un examen approfondi qui ne pouvait cependant tre envisag dans les limites du calendrier budgtaire impos. Cette situation a reprsent un des freins la conduite de lexprience de mutualisation. Lorganisation de tout projet de mutualisation informatique est complexe et ne saccommode pas ncessairement des contraintes juridiques, politiques et organisationnelles (budgtaires, en ce compris) que posent les procdures lies aux pratiques ordinaires dachat public. 64.Anticipation de louverture dautres utilisateurs Dj envisage pour lidentification des besoins, laffectation des ressources et le financement, lanticipation de louverture dautres utilisateurs a suscit des interrogations pour ce qui concerne la dfinition des rgles dentre de nouveaux membres dans le partenariat. Mme si une exprience de mutualisation doit tre conduite progressivement, il sagit didentifier les aspects relatifs louverture ultrieure des droits dutilisation qui doivent tre rgls ds le lancement du projet, et de les distinguer de ceux qui peuvent tre traits ultrieurement.
288
Cf. rapport, n V et suiv..
136
II. Aspects juridiques 65.Structure contractuelle de collaboration La ncessit dinscrire le partenariat franco-belge dans un cadre juridique lmentaire a t rapidement perue. Le choix des partenaires sest port sur une structure contractuelle de collaboration. Cette structure devait reposer essentiellement sur deux contrats : Une convention entre autorits politiques des deux Etats, dfinissant les objectifs de la coopration et les grands principes de participation : objet du partenariat, affectation des ressources humaines et financires, opportunit dinitier des procdures de marchs publics, modalits de collaboration entre partenaires, droit applicable, modes de rglement des litiges Un accord de coopration entre les administrations dtaillant plus prcisment le fonctionnement de la coopration.
Le caractre (partiellement) politique de telles collaborations peut justifier que diffrents contrats soient conclus, impliquant, les uns, les autorits politiques, les autres, les agents et services concerns par la mise en uvre des accords politiques. Outre que ces contrats peuvent se diffrencier par des portes et des degrs de prcision sensiblement diffrents, leur conclusion peut schelonner au travers dune certaine dure et permettre ainsi une mise en place progressive du partenariat : un accord gnral et de principe peut amorcer la conclusion de conventions de collaboration beaucoup plus prcises289. Dans le cadre de ce projet, le fait que les accords naient finalement pu tre conclus tenait moins une mise en cause de lopportunit de recourir un tel type de cadre de collaboration, qu la difficult, pour les partenaires, de saccorder sur les contributions respectives et modalits de collaboration. Le recours une structure contractuelle de collaboration suppose un accord tant sur lopportunit de recourir un tel cadre que sur les contraintes daction que les clauses contractuelles auront pour objet de dterminer. 66.Organes de concertation La convention organisait la mise en place dun comit directeur et dun comit technique, composs de reprsentants des administrations concernes (chacune dentre elles assurant la prsidence suivant un rle prdtermin) et investis de pouvoirs et missions particuliers, dans la conduite du projet.
289
Cf. rapport n VII.
137 La circonstance quil ne soit pas recouru une structure institutionnelle de mutualisation nexclut nullement la mise en place, par voie contractuelle, dorganes de concertation entre les partenaires. Au sein du comit technique, devaient siger des praticiens de diffrents mtiers (marchs publics, juristes, informaticiens, ). Le caractre htrogne des structures de concertation permet de favoriser, dune part, un bon partage de comptences entre les entits publiques (mutualisation de bonnes pratiques) et, dautre part, la prise en compte de la sensibilit des utilisateurs finaux des applications informatiques, et pas uniquement de celle des informaticiens des administrations concernes. 67.Choix de linstrument contractuel de dveloppement et dutilisation du logiciel En labsence de structure institutionnelle de mutualisation (laquelle aurait pu passer un march classique , cest--dire dont elle aurait t le seul pouvoir adjudicateur), le recours au march conjoint pouvait videmment tre envisag. Lunicit dun tel type de march saccommode cependant difficilement de la diversit des systmes et rgimes juridiques des administrations partenaires. Cette diversit peut savrer dlicate, notamment dans la conduite des procdures lies au paiement des prestations. Une scission du march au stade de lexcution (avec tablissement dun double lien contractuel entre le prestataire et chacune des deux administrations concernes) permet dobvier ces inconvnients, mais ne savre pas trs raliste dans le cadre dun march dont lobjet ne permet pas facilement une scission des prestations ( la diffrence, par exemple, de marchs ayant pour objet la fourniture de biens corporels, tels fournitures classiques, mobilier urbain, voitures de transport en commun, vtements, ). Une autre solution permettant de scinder lopration, de manire inscrire les contributions de chaque administration dans leurs cadres administratifs respectifs et consist conclure deux licences dutilisation entre le prestataire (concdant de droits dutilisation en lespce) et chaque administration. Cette solution nest cependant pas pleinement satisfaisante, ds lors, notamment, que le recours la figure de la licence dutilisation ne parat pas vraiment approprie au cas despce o se rencontre un vritable contrat de services portant sur le dveloppement dun logiciel. Les difficults lies aux contraintes respectives de chaque partenaire public commandent dexaminer soigneusement les diffrents instruments juridiques de dveloppement et dutilisation de logiciels, de manire choisir le plus appropri290.
290
Cf. rapport n VIII et suiv..
138
Projet Tabellio291
1. Prsentation du projet
68.Le projet Tabellio consiste en la mutualisation, par mise en commun, des solutions informatiques dveloppes linitiative de deux assembles parlementaires : pour le Parlement de la Communaut franaise un logiciel de gestion du travail parlementaire (Tabellio), pour le Parlement francophone bruxellois une application de Gestion lectronique de documents (Libellium). Ce partage de ressources sinscrit dans le dveloppement dune suite logicielle Tabellio , intgrant les fonctionnalits des deux outils au bnfice des deux Assembles mais aussi accessible au terme du dploiement du projet une communaut dutilisateurs aux profils similaires (assembles parlementaires de divers tats). 69.Au stade actuel, lexprience Tabellio ne sinscrit pas dans une structure institutionnelle de mutualisation en tant que telle, mais repose davantage sur un mode contractuel de partenariat entre les deux assembles. 70.La conduite de cette exprience de mutualisation a t prcde et assortie dtudes tendant favoriser la mise en uvre dune mthodologie de travail performante, prenant en compte les diffrents obstacles aux (ou facteurs de russite des) pratiques de mutualisation informatique dans le secteur public292. La prise en considration de cette importante phase pralable dtude aurait sans doute d inciter proposer une description linaire (ou chronologique) du projet, depuis sa gense jusqu son tat davancement la date de prsentation (phase de remise des offres dans le cadre du march public tendant la libration de la suite logicielle Tabellio). Les objectifs assigns, dans le cadre de ce rapport, la description dexpriences de mutualisation et la ncessit dassurer la transition entre le cas et les cas de figure dont ltude systmatique est propose dans la partie thorique du rapport, commandent dassocier le projet Tabellio lhypothse dun dveloppement de logiciel par des prestataires de services la demande de plusieurs administrations partageant linvestissement. Cest donc principalement par rfrence la passation de ce march public que sera ordonnance la description du projet, ce qui nempchera nullement dvoquer certains aspects de lexprience qui naffichent quune proximit trs relative lgard de ce march.
291
Cette description repose essentiellement sur les interventions de Messieurs G. Deberdt (P.C.F.) et J. Tournemenne (P.F.B.) lors du sminaire organis par le CRID le 14 mars 2007, ainsi que sur lexpos prsent par R. Viseur (CETIC-F.P.Ms) loccasion du colloque Services publics et mutualisation informatique : de la thorie la pratique organis le 23 mars 2006 par le Parlement de la Communaut franaise (compte rendu accessible ladresse www.pcf.be). 292 Sur ces tudes, cf. R. Viseur, Lapplication parlementaire Tabellio, une exprience belge de mutualisation , Services publics et mutualisation informatique : de la thorie la pratique. Compte rendu de la Journe organise le 23 mars 2006, Bruxelles, Parlement de la Communaut franaise, 2006, pp.69-75 (accessible ladresse www.pcf.be).
139
2. Dveloppement par des prestataires de services la demande de plusieurs administrations partageant linvestissement
I. Aspects mthodologiques 71.Proximit des besoins fonctionnels Une des tudes pralables, tendant dcrire les profils et modalits de fonctionnements respectifs des deux entits publiques lorigine du projet (assembles parlementaires), a permis dtablir la similarit de ces profils et, partant, de dgager une logique mtier homogne, attestant de la proximit des besoins fonctionnels auxquels les dveloppements informatiques existants ou futurs ont vocation rpondre. Par ailleurs, le choix de mthodologies de dveloppements flexibles permet denvisager, moyen terme, louverture des droits dutilisation dautres assembles parlementaires qui, prouvant des besoins fonctionnels proches, ne sont pas moins susceptibles de rvler des diffrences importantes (de type institutionnel, par exemple). Lidentification de besoins fonctionnels suffisamment proches favorise la rencontre dutilisateurs susceptibles de sengager dans un investissement commun, et laisse augurer des perspectives ultrieures de mutualisation en aval293. 72.Contexte de rapprochement entre partenaires publics La conception et la naissance du projet Tabellio ont pu bnficier dun contexte favorable lexprimentation de nouvelles pratiques dachat et de gestion publique, telle la mutualisation. Ce contexte tenait notamment une volont politique forte de collaboration entre assembles parlementaires et, plus gnralement, une curiosit294 lgard de phnomnes bouleversant les modes traditionnels de gestion des moyens informatiques (tels le dveloppement et la diffusion de logiciels en Open source). La faisabilit dexpriences de mutualisation tient pour beaucoup au contexte dans lequel elles sinscrivent ; le caractre innovant de telles pratiques et les difficults dont, pour cette raison, se trouve assortie leur mise en uvre requirent notamment, dans le chef des agents concerns, un important soutien de leur hirarchie.
293 294
Cf. rapport, n I et suiv.. Curiosit exprime et alimente notamment au travers de journes dtudes consacres lutilisation de lOpen source et la mutualisation informatique dans le secteur public.
140
73.Taille du groupe au stade du dveloppement et en cas douverture ultrieure Le souci de raliser un systme rapidement oprationnel a conduit concevoir le dveloppement dans le cadre dun partenariat ne regroupant, dans un premier temps, que deux assembles parlementaires. A moyen terme, lobjectif est de mettre la suite logicielle disposition dun nombre important dassembles, parlementaires ou institues auprs de collectivits territoriales (ex. conseils communaux). Le rayonnement international de cette diffusion est envisag. Ds lors quun produit de base sera dj disponible, llargissement de la communaut dutilisateurs et de contributeurs sera probablement moins difficile grer que sil avait t initi avant le dveloppement de la suite logicielle. La taille des communauts dutilisateurs et/ou de contributeurs dpend des phases du projet de mutualisation. 74.Logiciels libres et logiciels propritaires Lun des enjeux essentiels de lexprience est prcisment la libration des solutions informatiques lies Tabellio : une des phases consiste prcisment en la passation et lexcution dun march public de services tendant la rcriture de la suite logicielle Tabellio ; ainsi rcrite, cette suite sera diffuse sous licence libre, alors que, jusqu prsent, seuls quelques lments taient bass sur des technologies Open source. Les initiateurs du projet Tabellio voient, dans le recours au modle libre deux avantages : dune part, les modalits de diffusion dun logiciel en Open source favorisent louverture ultrieure de la communaut dutilisateurs un nombre beaucoup plus lev que les deux seules entits publiques qui ont lanc lexprience ; dautre part, limage de lOpen source est souvent associe des modles collaboratifs de dveloppement communautaire qui peuvent paratre appropris aux techniques de mutualisation, lesquelles reposent notamment sur le partage de savoirs et dexpriences. La rfrence lOpen source peut tre envisage tant comme mode de diffusion du logiciel que comme mthode de dveloppement communautaire avec contribution des utilisateurs. 75.Exigence de lisibilit du code source Les tudes pralables ont permis de souligner limportance quil y a lieu daccorder la qualit du code source et aux mthodes permettant dvaluer cette qualit. Lancien code source rvlait quelques faiblesses relatives sa documentation, ou dduites de la complexit de certaines de ses composantes. Lattention des entits concernes a t attire par la ncessit de dfinir le degr de prcision de cette documentation, dune part, et de purifier le code-source, en le rendant attrayant par des rgles de style constantes295, dautre part.
295
R. Viseur, op.cit., p.74.
141 La qualit du code-source influencera, dans une large mesure, la maintenance du logiciel296 et les opportunits de travail en commun.
76.Dveloppement collaboratif La circonstance quil soit fait appel un prestataire de services tiers, dans le cadre dun march public, nexclut pas une implication forte des reprsentants des entits concernes dans le suivi des travaux, rappelant les modles de dveloppement communautaire caractristiques des communauts Open source. Cette implication se traduit par la mise en place dun comit de pilotage (auquel participent les diffrents partenaires)297, ainsi que par linsertion, dans le cahier spcial des charges, de clauses imposant des formalits dinformation et de concertation favorisant cette implication des partenaires. Inhrente la mthodologie du projet de mutualisation, la rfrence lide de dveloppement collaboratif gagne tre traduite dans la structure de mutualisation et dans les documents relatifs aux marchs passs dans ce cadre. 77.Choix des langages et standards en fonction du dveloppement et de loption de logiciels libres Le cahier spcial des charges tabli pour le march de libration de la suite Tabellio, impose lusage exclusif de protocoles et standards ouverts. Les exigences de prennit et dinteroprabilit incitent recommander lusage de standards ouverts. II. Aspects juridiques 78.Choix dune structure contractuelle de mutualisation, de prfrence une structure institutionnelle Le partenariat entre les deux assembles parlementaires ne sest pas traduit dans la constitution dune entit distincte et dote de la personnalit juridique, offrant au projet de mutualisation une structure institutionnelle. La constitution dune telle entit ne parat pas ncessairement approprie et pourrait dailleurs se traduire dans un bilan cots-bnfices peu avantageux, l o seuls deux partenaires publics sont impliqus dans lexprience. Les charges (financires, administratives, ) inhrentes la constitution dune structure institutionnelle peuvent inciter renoncer ce mode de collaboration si le nombre de partenaires, la taille du projet ou dautres facteurs nen laissent pas apparatre un important avantage.
296 297
Cf. rapport, n IV et suiv.. Cf. rapport, n V et suiv..
142 La collaboration entre les deux assembles parlementaires sinscrit dans une structure contractuelle, dont tmoigne la conclusion daccords de collaboration et le recours des instruments juridiques appropris, tel le march conjoint298. Non formalise dans la cration dune institution, la collaboration entre entits publiques peut sinscrire dans un cadre contractuel. 79.Absence de structure institutionnelle Incidence sur les processus dcisionnels En labsence de structure institutionnelle, dote dune personnalit juridique distincte de celles des entits qui la constituent, et investie dun pouvoir de dcision, lvolution du projet de mutualisation est assure par des dcisions conjointes, prises en parallle par les organes de dcision des deux assembles parlementaires : prpares en concertation, par les agents en charge de la gestion du projet, ces dcisions sont alors adoptes formellement par les bureaux. Manifestement efficace, ce processus dcisionnel ne se conoit probablement que l o, comme en lespce, le nombre de partenaires est peu lev. Ladoption conjointe de dcisions identiques par les diffrents partenaires (publics) permet, en labsence de structure institutionnelle individualise de poser les actes que requiert la conduite du projet de mutualisation. 80.Absence de structure institutionnelle Ouverture de lieux de collaboration Le comit de pilotage regroupe les diffrents partenaires invits se joindre au projet (reprsentants des assembles parlementaires, du prestataire et, ventuellement, experts) et permet dassurer la dimension collaborative inhrente de nombreuses pratiques de mutualisation. Il a t prconis dlargir ce comit aux contributeurs importants 299 lorsque la communaut dutilisateurs sera ouverte aprs le dveloppement de la suite logicielle. Labsence de structure institutionnelle distincte des partenaires publics nexclut pas louverture de lieux de collaboration dont les modalits damnagement peuvent tre informelles ou, au contraire, formalises dans le cadre dun accord de collaboration entre partenaires, par exemple300. 81.Choix dune structure contractuelle de mutualisation Dfinition du cadre de collaboration Le cadre de collaboration est dfini la faveur de conventions successives dont le degr de prcision et le caractre contraignant saccentuent progressivement. Une premire convention arrte le principe dune collaboration dont elle dfinit lobjet et les modalits en termes gnraux (objectifs, obligation de moyen, devoirs de collaboration et dinformation, confidentialit).
298 299
Cf. rapport, n VIII et suiv.. A savoir ceux qui font preuve dune implication forte dans le projet. 300 Cf. rapport, n VII et suiv..
143
Cette convention en annonce une seconde, ayant vocation dfinir plus prcisment et au terme des dmarches inities sur la base de la premire, les modalits de collaboration, telles la rpartition des investissements financiers et la dfinition dun calendrier. La conclusion de plusieurs accords successifs permet la dfinition progressive des termes de la collaboration. Ces instruments contractuels peuvent, le cas chant, tre prolongs par (ou se conjuguer avec) le processus prcdemment voqu dadoption conjointe de dcisions identiques301. 82.Incidence des rfrences au modle Open source Le cahier spcial des charges tabli dans le cadre du march de libration encourage lutilisation de briques, technologies et mthodes de travail rpandues dans la communaut Open source. Il est cependant paradoxal de constater quaux termes de ce mme cahier spcial des charges (art.17), la totalit des dveloppements effectus par le soumissionnaire devient la proprit exclusive du Parlement de la Communaut franaise et du Parlement francophone bruxellois . Si un transfert des droits de proprit intellectuelle en faveur du pouvoir adjudicateur nest pas incompatible avec la diffusion ultrieure du logiciel sous licence libre, il est, en revanche, difficile de comprendre quun dveloppement conu (par hypothse) laide de nombreuses composantes diffuses sous licence libre puisse faire lobjet dune appropriation exclusive. La clause prcite napparatra compatible avec lencouragement utiliser des composantes libres que si elle est interprte en ce sens quelle ne vise que les composantes qui, spcialement dveloppes par le prestataire dans le cadre de ce march, ne pourraient tre diffuses dans une suite Open source, si le transfert de proprit ntait pralablement assur au bnfice des pouvoirs adjudicateurs. La porte et lincidence dune rfrence lOpen source diffrent selon quelle a trait aux composantes de la solution dveloppe ou la diffusion de celle-ci. 83.Recours un prestataire de services Passation dun march conjoint La libration de la suite logicielle Tabellio repose sur des prestations de services pour lesquelles la collaboration dun tiers est sollicite. Dans un contexte o il ny a pas de structure institutionnelle individualise, mais deux partenaires distincts, ceux-ci ayant opt pour la technique du march conjoint dont ils sont tous les deux pouvoirs adjudicateurs tandis que le Parlement de la Communaut franaise les reprsente. Le march conjoint est une des techniques permettant de passer deux marchs dont lavantage conomique (utilisation dune suite logicielle et services annexes,) bnficie plusieurs entits publiques distinctes302.
301 302
Cf. rapport, n VII. Cf. rapport, n VIII et suiv..
144 84.March public de services et mutualisation Bien quil ne diffre pas fondamentalement de tout autre march public informatique, le march de libration de la suite Tabellio affiche des caractristiques sans lesquelles il ne pourrait sinscrire dans un projet de mutualisation. Tel est, par exemple, le cas de lassociation troite des pouvoirs adjudicateurs au processus de dveloppement (dans le cadre du comit de pilotage) ou des exigences relatives au choix des langages technologies et des composantes. Ces caractristiques doivent faire lobjet de clauses appropries dans le cahier spcial des charges. De mme, les critres de slection qualitative des candidats et dexamen des offres peuvent-ils intgrer lattention accorde cette perspective de mutualisation ; ainsi, en est-il, par exemple, de la ncessit de faire tat dexpriences similaires dans dautres marchs. Le profil du march public de services doit tre adapt aux caractristiques dun projet de mutualisation.
145
Projet Qualicit303
1. Prsentation du projet :
85.Lorigine de la dmarche de mutualisation informatique est base sur des partenariats existant entre les cinq communes de Ans, Arlon, La Louvire, Marche en Famenne et Mons. Le projet se veut terme ouvert aux autres communes, CPAS et Provinces. La finalit du projet de mutualisation est daccrotre la qualit du service public pour le citoyen tout en matrisant les cots engendrs pour arriver cet objectif. 86.Pour ce faire, les communes ont opt pour une structure institutionnelle sous forme dun groupement dintrt conomique (par aprs G.I.E.) compos de diffrents organes de fonctionnement (une assemble gnrale, un Collge des grants, un comit technique, des conseils de projets). 87.Outre la facilitation de la relation aux usagers (front office), le projet se voit assigner, comme objectifs : - La matrise des processus internes (back office), - Lvolution des systmes de gestion de linformation (TIC interoprabilit), - La gestion des cadres communaux (effectifs et comptences). Pour rencontrer ces objectifs, la mutualisation ne porte pas uniquement sur les solutions informatiques, mais galement sur les bonnes pratiques administratives : partage des pratiques, expriences et mthodes de travail en vue de les amliorer, modlisations de processus. Ce souci des bonnes pratiques administratives sexprime tant lgard des procdures mtiers dont la modlisation et linformatisation sont envisages, quen ce qui concerne lattribution et lexcution des procdures lies aux marchs publics. 88.En son volet informatique , lenjeu principal est la manire dont les droits dutilisation seront ouverts dautres entits publiques. Des instruments juridiques de collaboration entre les partenaires publics ont t mis en place :
303
La prsente description est base sur les propos tenus par Ingrid Briot lors du sminaire du 14 mars 2007 organis par le CRID ; sur les statuts, le rglement dordre intrieur, lacte dadhsion, la convention de projet et le cahier spcial des charges du groupement dintrt conomique Qualicit.
146
89.Lacte dadhsion au G.I.E., les statuts du G.I.E. et son rglement dordre intrieur Ds lors que ladhsion au G.I.E. et ses modalits de fonctionnement reprsente une condition essentielle la participation au projet de mutualisation informatique, lacte dadhsion, les statuts et le rglement dordre intrieur sont des engagements ncessaires au bon fonctionnement du projet. Les entits publiques lorigine du projet ont opt pour la cration dun G.I.E. Celles-ci sont appeles les membres fondateurs de linstitution. Les statuts et le rglement dordre intrieur sont rdigs. Un acte dadhsion garantit laccs linstitution et ses projets informatiques dautres entits publiques, qualifies de membres adhrents. 90.La convention de projet La convention de projet se situe dans le cadre dune mutualisation informatique en amont. Ainsi, les projets du G.I.E., tel que le processus de mutualisation informatique, sont dcrits dans une convention ouverte aux membres intresss par un investissement partag. La convention de projet propose une description complte du projet comprenant notamment, laffectation des ressources humaines et financires. Il est ainsi prvu que chaque partenaire sacquitte dune contribution en fonction du projet choisi qui est calcule en fonction du nombre dhabitants pour lusage de lapplication informatique. Les cots de maintenance sont mutualiss entre tous les membres.
91.La convention dutilisation La convention dutilisation garantit louverture des droits sur le logiciel et se situe dans un schma de mutualisation en aval.
147

I. Aspects mthodologiques 92.Dfinition des besoins fonctionnels : sont-ils suffisamment proches? La mutualisation informatique a vocation perdurer dans le temps, ce qui pousse les entits publiques sassurer, ds les prmisses du projet, de rencontrer les besoins fonctionnels des entits, quelle que soit leur taille304. 93.Calendrier et gestion du temps Ces aspects sont traits par le biais dune convention305. Il est utile, pour viter les blocages, que les diffrents partenaires tablissent un calendrier prcis des tapes du processus de mutualisation306. 94.Affectation des ressources financires Les charges engendres par le processus de mutualisation (dveloppement ou acquisition du logiciel, formation, maintenance etc.) sont finances par des ressources lies ladhsion au G.I.E. et par des contributions lies aux diffrents projets. Il y a lieu dassurer la viabilit financire du projet en dterminant les contributions respectives des partenaires publics. Cette viabilit doit tre envisage tant pour la phase de lancement du projet que pour les tapes ultrieures (phase dexploitation du logiciel) 307 .
95.Organisation institutionnelle Les organes institutionnels de Qualicit se rpartissent les diffrentes tches quengendre le processus de mutualisation : une Assemble Gnrale, un Collge des Grants et des conseils de projets. Le Collge des grants est compos dun maximum de 9 mandataires dsigns par lassemble gnrale. Ce Collge peut lui-mme constituer ses cts un comit technique et
304 305
Cf. rapport, n I et suiv.. Convention de projet Qualicit. 306 Cf. rapport, n IV et suiv.. 307 Cf. rapport, n VII et suiv..
148 des conseils de projets, lesquels ne sont pas ncessairement constitus de mandataires. Deux commissaires de la D.G.P.L. peuvent assister aux runions du Collge. Les conseils de projets permettent au G.I.E. de grer la phase pilote du projet avant la mutualisation. Le projet est gr selon une mthodologie spcifique : dfinition, planification, ralisation, clture du projet et valuation. Un chef de projet manant dun des pouvoirs locaux membres du G.I.E. pilote le processus. Enfin, la convention de projet est tablie entre les communes et Qualicit. Cette convention propose une description complte du projet, comprenant lorganisation du Conseil de projet. La cration dune structure institutionnelle de mutualisation ncessite lamnagement de diffrents organes qui se rpartissent les charges de gestion du processus de mutualisation. Le recours ces comits techniques et/ou de projets permet dassocier des collaborateurs qui, sans tre habilits engager les communes et reprsenter celles-ci dans les organes de gestion, ne jouent pas moins un rle dterminant dans la dynamique de la mutualisation (informaticiens, utilisateurs, )308. 96.Taille du groupe au stade du dveloppement La taille initiale du groupement, 5 communes, est suffisante pour dterminer les besoins fonctionnels des entits publiques et pour dtecter ceux dautres partenaires potentiels. Par ailleurs, la gestion du projet par un conseil de projet permet dimpliquer quelques partenaires prts porter ce projet et sy investir, sans prjudice dune ouverture ultrieure du groupe dutilisateurs. Un trop grand nombre dinterlocuteurs au stade du lancement dun projet de mutualisation risque de bloquer le processus en lui-mme309. 97.Comprhension du code-source Les cahiers spciaux des charges prvoient que tous les documents indispensables la bonne comprhension du code sont transmis au G.I.E. par les soins de lditeur du logiciel. Le code source est un lment crucial pour lvolution du projet. Les entits publiques sassurent de pouvoir le comprendre. Pour ce faire, sa lisibilit doit tre excellente310.
308 309
Cf. rapport, n III. Cf. rapport, n III et III. 310 Cf. rapport, n IV et suiv..
149
II. Aspects juridiques 98.Structure institutionnelle Les membres fondateurs de Qualicit ont opt pour la structure dun G.I.E., cest--dire dune socit commerciale dote dune personnalit juridique propre qui requiert le respect de certaines rgles particulires telles que lobligation deffectuer un apport et linterdiction dattribuer le bnfice de la socit un seul de ses membres. Ce type de groupement apparat comme une structure souple qui lui permettra daccueillir un certain nombre de membres en constante fluctuation. Le lien existant entre le G.I.E. et chacun de ses membres est caractris par une relation intuitu personnae, ce qui renforce lobligation de loyaut des membres face au groupement. Il est important que le choix des partenaires publics porte sur une structure souple saccommodant des besoins particuliers que requiert le processus de mutualisation311. 99.Droits et obligations des membres Il est tabli un principe dgalit entre les membres fondateurs et les membres adhrents au G.I.E.. Il est ainsi prvu dans lacte dadhsion que les nouveaux adhrents jouissent des mmes droits que les membres fondateurs. Ils bnficient ainsi des droits dutilisation sur les logiciels et du droit de prendre connaissance de linformation relative chaque produit conduit par le G.I.E. (en ce comprise la documentation relative aux modlisations de processus) et de la possibilit dutiliser aux conditions et suivant les modalits dtermines par une convention dutilisation les logiciels dvelopps dans le cadre du G.I.E.. Chaque membre est encore habilit proposer et/ou participer la ralisation des projets du G.I.E. suivant les modalits que dfiniront des conventions de projet. La structure institutionnelle, en se rservant la possibilit doctroyer des droits dutilisation sur le logiciel tout nouveau membre du groupement, garantit la continuit du processus de mutualisation312. 100.March public Dans le cas de figure en cause, les partenaires publics, par le biais de linstitution, peuvent avoir recours un prestataire extrieur pour la ralisation et le suivi du logiciel. La relation entre le G.I.E. et le prestataire stablit dans le cadre dun march public, pour lequel un cahier des charges doit tre rdig et un appel doffres lanc. Les membres sont ainsi dispenss de refaire un march public dans le cadre des marchs publics dits in house.
311 312
Cf. rapport, n III et suiv.. Cf. rapport, n VIII.
150 Le recours linstitution juridique des marchs publics peut savrer contraignant, notamment au regard des rgles de concurrence, mais est invitable lorsquune entit publique fait appel un prestataire de services pour le dveloppement dun logiciel313. 101.Transfert des droits de la proprit intellectuelle Le G.I.E. est conscient de limportance que revt son profit la cession des droits patrimoniaux de la proprit intellectuelle sur le logiciel. Il est ds lors envisag par linstitution dinclure dans le cahier spcial des charges certaines clauses particulires prvoyant entre autre : Le transfert des droits de la proprit intellectuelle sur les rsultats ; La garantie contre lviction du pouvoir adjudicateur par un tiers dtenant des droits sur lapplication informatique ; Le droit exclusif de linstitution de dcider de lutilisation ultrieure des rsultats ; Limpossibilit pour le prestataire de publier les rsultats sans autorisation du pouvoir adjudicateur.
Il est relevant pour le pouvoir adjudicateur de se garantir la titularit drive314 des droits de la proprit intellectuelle qui lui seront ncessaires pour le processus de mutualisation. Les parties amnagent contractuellement (dans le cahier spcial des charges) la rpartition des droits sur lapplication informatique entre le pouvoir adjudicateur et le prestataire de services315.
102.Conditions dutilisation du logiciel Des conventions tablissent les conditions dutilisation du logiciel. Lutilisation du logiciel nest accorde quaux membres du groupement. Lon pourrait toutefois imaginer que les anciens membres peuvent avoir accs au logiciel des conditions dutilisation moins avantageuses que pour les partenaires actuels du G.I.E. Il ne faut en effet pas amoindrir lintrt de la qualit de membre du groupement. Il est encore prvu que la modification des statuts ninflue pas sur lutilisation du logiciel. De plus, en cas de dissolution du G.I.E., les entits sont habilites contracter directement avec lditeur du logiciel. Lamnagement des droits dutilisation sur le logiciel est un pr-requis indispensable tout processus de mutualisation informatique. Les modalits dexercice de ces droits doivent prserver les utilisateurs de tout risque li aux alas de lexistence du G.I.E.. 103.Obligation de non-concurrence
313 314
Cf. rapport, n II. Par opposition avec le titulaire originaire des droits, cest dire lditeur du logiciel. 315 Cf. rapport, n VIII.
151 Une clause de non-concurrence de lacte dadhsion a encore vocation dissuader un membre de poser tout acte ou dadopter tout comportement qui entrerait manifestement en concurrence avec le G.I.E. ou nuirait gravement la ralisation des objectifs poursuivis par celui-ci. Lobligation de non-concurrence laquelle doit souscrire le membre converge avec les caractristiques intrinsques de la mutualisation. 104.Conventions de collaboration : traduction juridique de la mthodologie Comme il la t relev tout au cours de cette description de cas, les entits publiques ont trs largement choisi le recours des conventions de collaboration pour lorganisation du processus. La structure institutionnelle ncessite dailleurs dans une large mesure un amnagement contractuel. Les administrations publiques peuvent amnager contractuellement et ce, que lon se situe, ou non, dans le cadre dune structure institutionnelle les modalits de fonctionnement du processus de mutualisation tels laffectation des ressources humaines et financires, lorganisation du travail, le processus de prise de dcisions ou encore les conditions daccs de nouveaux utilisateurs316. Toutefois, la prennit du processus de mutualisation ncessite une organisation structurelle.
316
Cf. rapport, n VII et suiv..
152
Table des matires

Introduction gnrale................................................................................................................ 2
1.La mutualisation informatique : une double acception...........................................................................2 2.La mutualisation informatique : divers objectifs.................................................................................... 3 I. Les conomies dchelle ___________________________________________________________ 3 ........................................................................................................................................................................ 3 II. La recherche dindpendance lgard des prestataires de services____________________________ 3 III. La mise en commun de bonnes pratiques_______________________________________________4 IV. La prennit et linteroprabilit des outils dvelopps____________________________________4 3.La mutualisation informatique : aspects mthodologiques et juridiques......................................................5 4.La mutualisation informatique : plusieurs modles......................................................................................6 5.La mutualisation informatique : aspects gnraux....................................................................................... 8
La solution doit tre dveloppe - Dveloppement avec perspective d'ouverture ultrieure.10

Introduction....................................................................................................................................................10 I. Prospection de lexistant_____________________________________________________________ 10 II. Importance des tudes pralables_____________________________________________________11 A.Etude des profils des utilisateurs et de leurs besoins fonctionnels.................................... 12 B.Etude de pr-requis techniques, mthodologiques ou juridiques louverture ultrieure des droits dutilisation du logiciel..........................................................................................12 C.Etude des forme juridique et modle conomique du processus de mutualisation............12 III. Degr de la contrainte danticipation en fonction du degr de volont douverture______________ 13 1.Dveloppement, en interne, par une administration "seule".......................................................................14 Enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper?............................................... 14 I. Identification des perspectives douverture ultrieure dautres utilisateurs____________________14 A.Besoins similaires ou complmentaires dautres administrations..................................... 14 B.Prcautions......................................................................................................................... 15 II. Ressources humaines ncessaires pour assurer le dveloppement et louverture du logiciel________ 15 A.Ressources pour le dveloppement et le suivi................................................................... 15 B.Ressources pour louverture...............................................................................................15 III. Cession des droits patrimoniaux sur le logiciel au profit de ladministration___________________ 16 A.Logiciel entirement dvelopp par les agents de ladministration...................................16 B.Logiciel dvelopp par les agents contractuels ou statutaires de ladministration avec laide dun prestataire extrieur............................................................................................. 17 IV. Code source_____________________________________________________________________ 18 A.Accs au code source.........................................................................................................18 B.Lisibilit du code ...............................................................................................................18 C.Utilisation dlments Open source : prcautions..............................................................19 V. Langage clair pour louverture du logiciel______________________________________________20 VI. Identification du mode ultrieur de diffusion___________________________________________20 A.Licence Open source..........................................................................................................21 B.Licence propritaire........................................................................................................... 21 Illustration de la premire hypothse : tableau rcapitulatif..........................................................................22 2.Dveloppement par une communaut de dveloppeurs-utilisateurs, informaticiens des administrations concernes......................................................................................................................................................23 2.1/ Premier enjeu : Dveloppement du logiciel en communaut (mutualisation en amont)........................23 I. Ncessit de besoins fonctionnels suffisamment proches___________________________________23 II. Groupe au stade du dveloppement___________________________________________________23 A.Taille du groupement......................................................................................................... 23 B.Composition du groupement..............................................................................................24 III. Calendrier et gestion du temps_______________________________________________________ 24 IV. Ressources humaines______________________________________________________________ 25 A.Ressources humaines propres aux administrations ...........................................................25 B.Appel un prestataire tiers.................................................................................................25 V. Organisation du leadership __________________________________________________________ 26
153
A.Cration dune structure de pilotage..................................................................................26 B.Dsignation dun animateur de projet ..........................................................................27 VI. Outillage facilitant la collaboration___________________________________________________ 27 A.Mthodes de travail ...........................................................................................................27 B.Outils de communication .................................................................................................. 28 VII. Conclusion dune convention de collaboration : traduction juridique de la mthodologie et importance de saccorder sur les modalits de la collaboration_________________________________ 28 A.Une convention de collaboration estelle absolument ncessaire ?.................................. 29 B.Quel formalisme dans la conclusion du contrat ?.............................................................. 29 C.Nature politique ou juridique de la convention et degr de prcision (et de contrainte) des engagements souscrits........................................................................................................... 29 D.Contenu de la convention de collaboration........................................................................30 2.2/ Deuxime enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper? (Mutualisation en aval) ..........................................................................................................................................................30 I. Identification des perspectives douverture ultrieure dautres utilisateurs____________________30 A.Besoins identiques ou complmentaires............................................................................ 30 B.Prcautions......................................................................................................................... 31 II. Droits patrimoniaux de la proprit intellectuelle_________________________________________ 31 A.Logiciel dvelopp en interne............................................................................................31 B.Co-titularit, uvre de collaboration et amnagement des droits entre les administrations ............................................................................................................................................... 31 C.Logiciel dvelopp en partie par un prestataire extrieur.................................................. 32 III. Code source_____________________________________________________________________33 A.Accs au code source.........................................................................................................33 B.Lisibilit du code et prestataire de certification................................................................. 34 IV. Langage clair pour louverture du logiciel_____________________________________________34 V. Disponibilit en ressources humaines et financires pour assurer l'ouverture___________________35 A.Ressources financires.......................................................................................................35 B.Ressources humaines ........................................................................................................ 35 VI. Identification du mode ultrieur de diffusion___________________________________________36 Illustration de la deuxime hypothse : tableau rcapitulatif........................................................................ 37 3.Dveloppement par un prestataire de services la demande d'une administration "seule"....................... 39 Enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper?............................................... 39 I. Identification des perspectives douverture ultrieure dautres utilisateurs____________________39 A.Besoins identiques ou complmentaires............................................................................ 39 B.Prcautions......................................................................................................................... 39 II. Contrat de louage douvrage, application de la lgislation relative aux marchs publics et cahier spcial des charges __________________________________________________________________40 A.Qualification du contrat .................................................................................................... 40 B.March public.................................................................................................................... 40 III. Clauses insrer dans le cahier spcial des charges______________________________________41 A.Utilisation ultrieure du logiciel........................................................................................ 41 B.Droits patrimoniaux de la proprit intellectuelle..............................................................42 C.Accs aux codes sources.................................................................................................... 45 D.Responsabilit du prestataire de services et dissolution du contrat................................... 47 E.Prestations annexes............................................................................................................ 51 Illustration de la troisime hypothse : tableau rcapitulatif......................................................................... 53 4.Dveloppement par un prestataire de services la demande de plusieurs administrations partageant linvestissement............................................................................................................................................. 55 Enjeux : dveloppement du logiciel en communaut et anticipation de louverture ventuelle du logiciel dvelopper......................................................................................................................................................55 4.1/ Figure institutionnelle.............................................................................................................................55 4.1.1/ La structure institutionnelle de mutualisation..................................................................................... 55 I. Avantages et inconvnients de la structure institutionnelle__________________________________ 55 A.Avantages...........................................................................................................................55 B.Inconvnients..................................................................................................................... 56 II. Opportunit du recours une structure institutionnelle de mutualisation_______________________ 57 III. Formes envisageables_____________________________________________________________57 A.Lassociation sans but lucratif ......................................................................................... 58 B.Le groupement dintrt conomique ............................................................................... 58
154
C.La socit cooprative........................................................................................................59 D.La socit en nom collectif................................................................................................ 59 E.La socit prive responsabilit limite.......................................................................... 60 F.La socit anonyme............................................................................................................ 60 IV. Modalits de fonctionnement_______________________________________________________61 V. Relations entre linstitution et ses membres_____________________________________________ 61 A.Adhsion............................................................................................................................ 62 B.Utilisation du logiciel.........................................................................................................62 C.Collaboration......................................................................................................................63 4.1.2/ Le dveloppement du logiciel linitiative de la structure institutionnelle de mutualisation............. 64 I. Proximit des besoins fonctionnels au stade du dveloppement______________________________64 II. Identification des perspectives douverture ultrieure dautres utilisateurs____________________ 64 A.Besoins identiques ou complmentaires............................................................................ 64 B.Prcautions......................................................................................................................... 65 III. Taille et composition du groupe au stade du dveloppement_______________________________65 A.Taille du groupe................................................................................................................. 65 B.Composition du groupe......................................................................................................66 IV. Calendrier et gestion du temps______________________________________________________66 V. Langage clair ____________________________________________________________________67 VI. Outillage facilitant la collaboration __________________________________________________67 VII. Ressources humaines et financires__________________________________________________ 67 A.Ressources humaines ........................................................................................................ 67 B.Ressources financires....................................................................................................... 68 VIII. Contrat de louage douvrage : applicabilit de la lgislation relative aux marchs publics_______ 68 A.Application de la lgislation relative aux marchs publics................................................69 B.Clauses du cahier spcial des charges................................................................................69 4.2/ Figure contractuelle................................................................................................................................ 71 I. Proximit des besoins fonctionnels au stade du dveloppement ______________________________ 71 II. Identification des perspectives douverture ultrieure dautres utilisateurs____________________ 71 A.Besoins identiques ou complmentaires............................................................................ 71 B.Prcautions......................................................................................................................... 72 III. Taille et composition du groupe au stade du dveloppement_______________________________72 IV. Calendrier et gestion du temps______________________________________________________73 V. Ressources humaines et financires ncessaires pour le dveloppement et louverture du logiciel___ 73 VI. Outillage facilitant la collaboration __________________________________________________74 VII. Amnagement dun leadership dans la convention de collaboration ________________________ 74 VIII. Contrat de louage douvrage : applicabilit de la lgislation relative aux marchs publics_______ 74 A.March pass par une seule administration ...................................................................... 74 B.March conjoint ................................................................................................................ 75 IX. Mode de diffusion de lapplication informatique________________________________________76 X. Convention de collaboration : traduction juridique de la mthodologie et importance de saccorder sur les modalits de la collaboration_____________________________________________________77 Illustration de la quatrime hypothse : tableau rcapitulatif........................................................................ 79 Illustration des quatre premires hypothses : tableau synoptique................................................................83
La solution existe - Comment en profiter ?............................................................................ 84

1.Qualification du contrat de licence............................................................................................................. 85 I. Dfinition de la licence dutilisation___________________________________________________85 II. Enjeux de la qualification de la licence_________________________________________________ 85 III. Amnagement contractuel dun droit patrimonial________________________________________ 85 IV. Incidence des prestations annexes sur la qualification ___________________________________86 A.La qualification des prestations annexes........................................................................... 86 B.Maintenance corrective (et prestations assimiles)............................................................86 C.Maintenance volutive (et prestations assimiles).............................................................87 V. Influence des oprations in house sur la qualification_____________________________________87 2.Licence propritaire et Open source........................................................................................................... 89 I. Introduction______________________________________________________________________ 89 II. Hypothse de distribution du logiciel en mode propritaire_________________________________ 90 III. Hypothse de distribution du logiciel en mode libre______________________________________ 90 A.Licence libre ..................................................................................................................... 90
155
B.Licence Open source ........................................................................................................90 IV. Avantages et inconvnients des deux modes de diffusion__________________________________ 91 A.Transfert des droits patrimoniaux ..................................................................................... 91 B.Contrle sur la diffusion ................................................................................................... 91 C.Responsabilit du donneur de licence ...............................................................................92 D.Accs au code source ........................................................................................................92 E.Problmatique des forks .............................................................................................. 93 3.Clauses insrer dans la licence.................................................................................................................96 I. Point de vue du preneur de licence_____________________________________________________ 96 A.Transfert des codes sources .............................................................................................. 96 B.Mises jour et dveloppements ultrieurs .......................................................................96 C.Prestations annexes .......................................................................................................... 96 D.Droit de dsigner dautres utilisateurs............................................................................... 97 E.Responsabilit du donneur de la licence............................................................................ 97 II. Point de vue du donneur de licence____________________________________________________ 99 A.Droits transfrs ................................................................................................................99 B.Accs aux codes sources ................................................................................................. 100 C.Rtribution financire du donneur de licence ................................................................. 101 D.Responsabilit du donneur de licence..............................................................................101
Conclusion gnrale.............................................................................................................. 103 Annexe : description dexpriences rcentes........................................................................104

Introduction.................................................................................................................................. 104
1.Objectif..................................................................................................................................................... 104 2.Mthode.................................................................................................................................................... 104
Projet Iriscom .............................................................................................................................. 105

1.Introduction ..............................................................................................................................................105 2.Logiciel dvelopp en partie par des agents du C.I.R.B. et en partie par un prestataire de services la demande dune administration seule........................................................................................................... 106 7.Prospection du march : solutions disponibles et besoins dautres utilisateurs ...............106 8.Dveloppement du logiciel par le C.I.R.B., et lintervention dun prestataire de services Facult douverture dautres utilisateurs .......................................................................106 9.Dveloppement du logiciel par le C.I.R.B., et lintervention dun prestataire de services Garanties dindpendance du pouvoir adjudicateur lgard du prestataire ...................107 10.Mthodologie de ralisation et contraintes organisationnelles ......................................108 11.Collaboration entre partenaires publics. Quelles modalits dorganisation ?.................108
Projet PloneGov........................................................................................................................... 110

1.Introduction ..............................................................................................................................................110 2.Dveloppement par une communaut de dveloppeurs-utilisateurs, informaticiens des administrations concernes ..................................................................................................................................................110 I. Aspects mthodologiques __________________________________________________________110 13.Prospection du march ...................................................................................................110 14.Projet bas sur le modle existant CommunesPlones ..............................................111 15.Calendrier et gestion du temps ...................................................................................... 111 16.Langages et standards .................................................................................................... 112 17.Affectation des ressources humaines au stade du dveloppement et de lutilisation ultrieure du logiciel ........................................................................................................... 112 18.Besoins fonctionnels actuels et futurs ............................................................................113 19.Outillages facilitant la collaboration ..............................................................................113 II. Aspects juridiques _______________________________________________________________115 20.Cadre juridique inexistant ..............................................................................................115 21.Programmes dvelopps sous licence GPL ................................................................... 115 22.Certification de la qualit du code source ......................................................................116
Projets IAM PAM, E-PROC et "portail des marchs publics"................................................ 117

1.Introduction ..............................................................................................................................................117 2.Projets IAM PAM et E-PROC (initialement EPI) ...................................................................................118 I. Aspects mthodologiques __________________________________________________________118
156
26.Organisation de la mutualisation au sein de l'administration entre les diffrents utilisateurs : le Comit d'accompagnement du MET ..........................................................118 27.Recours des logiciels "hybrides" (composantes propritaires et composantes libres) ou "homognes" (tout propritaire ou tout libre) .....................................................................118 28.Opportunit d'un transfert de tous les droits du prestataire au bnfice de l'administration ................................................................................................................... 118 II. Aspects juridiques _______________________________________________________________119 29.Organisation de la mutualisation au sein de l'administration entre les diffrents utilisateurs : le Comit d'accompagnement IAM-PAM...................................................... 119 30.Accs au code source et garantie de sa qualit .............................................................. 119 31.Objet du contrat, tendue des droits transfrs d'autres utilisateurs et monopole du prestataire de services ......................................................................................................... 120 3.Projet de "portail des marchs publics" commun la Rgion wallonne et la Communaut franaise..121 I. Aspects mthodologiques __________________________________________________________121 32.Opportunit d'un march public conjoint ...................................................................... 121 II. Aspects juridiques _______________________________________________________________121 33.Cadre juridique pralable un dveloppement commun .............................................. 121
Projet GILS.................................................................................................................................. 123

1.Introduction...............................................................................................................................................123 2.Dveloppement par un prestataire de services la demande de plusieurs administrations......................123 I. Aspects mthodologiques __________________________________________________________123 35.Forme et structure du partenariat ...................................................................................123 36.Dveloppement du logiciel Jrme ......................................................................... 124 37.Financement ...................................................................................................................124 38.Evolution du projet ........................................................................................................ 125 II. Aspects juridiques _______________________________________________________________125 39.Droits sur le logiciel .......................................................................................................125 40.Relations entre membres ................................................................................................125
Projet LiberAccs......................................................................................................................... 127

1.Prsentation du projet .............................................................................................................................. 127 2.Dveloppement par des prestataires de services la demande de plusieurs administrations partageant linvestissement ou utilisation dune solution dj existante :.................................................................... 127 I. Aspects mthodologiques __________________________________________________________128 43.Proximit des besoins fonctionnels ............................................................................... 128 44.Mthodologie dvolution ............................................................................................. 128 45.Logiciels libres et logiciels propritaires ...........................................................128 46.Affectation et disponibilit des ressources humaines au stade du dveloppement et pour assurer louverture .............................................................................................................. 129 47.Taille du groupe au stade du dveloppement ................................................................ 129 48.Mode de financement .................................................................................................... 129 49.Exigence de lisibilit du code source .............................................................................130 50.Choix des langages et standards en fonction du dveloppement et de louverture ....... 130 II. Aspects juridiques _______________________________________________________________130 51.Marchs publics ............................................................................................................. 130 52.Cration dun G.I.E. : traduction juridique de la mthodologie .................................... 131 53.Utilisation de logiciels libres et structure institutionnelle de mutualisation ..................131 54.Si la solution existe dj : qualification de la relation en cas doctroi de licence : march public ou autre ?...................................................................................................................132 55.Clauses et modalits de dsignation des utilisateurs ..................................................... 132
Projet e-Catalogue........................................................................................................................ 133

1.Introduction ..............................................................................................................................................133 2.Dveloppement dun logiciel par un prestataire de services la demande de plusieurs administrations partageant linvestissement .........................................................................................................................134 I. Aspects mthodologiques __________________________________________________________ 134 60.Identification des besoins .............................................................................................. 134 61.Communauts de langages, concepts et systmes juridiques ........................................ 134 62.Affectation et rpartition des ressources humaines et financires .................................135 63.Calendrier et gestion du temps ...................................................................................... 135
157
64.Anticipation de louverture dautres utilisateurs ........................................................135 II. Aspects juridiques _______________________________________________________________136 65.Structure contractuelle de collaboration ........................................................................ 136 66.Organes de concertation ................................................................................................ 136 67.Choix de linstrument contractuel de dveloppement et dutilisation du logiciel ......... 137
Projet Tabellio.............................................................................................................................. 138

1.Prsentation du projet .............................................................................................................................. 138 2.Dveloppement par des prestataires de services la demande de plusieurs administrations partageant linvestissement........................................................................................................................................... 139 I. Aspects mthodologiques __________________________________________________________139 71.Proximit des besoins fonctionnels ............................................................................... 139 72.Contexte de rapprochement entre partenaires publics ................................................... 139 73.Taille du groupe au stade du dveloppement et en cas douverture ultrieure ..............140 74.Logiciels libres et logiciels propritaires ...........................................................140 75.Exigence de lisibilit du code source .............................................................................140 76.Dveloppement collaboratif ...........................................................................................141 77.Choix des langages et standards en fonction du dveloppement et de loption de logiciels libres.................................................................................................................................... 141 II. Aspects juridiques _______________________________________________________________141 78.Choix dune structure contractuelle de mutualisation, de prfrence une structure institutionnelle .................................................................................................................... 141 79.Absence de structure institutionnelle Incidence sur les processus dcisionnels .........142 80.Absence de structure institutionnelle Ouverture de lieux de collaboration ..........142 81.Choix dune structure contractuelle de mutualisation Dfinition du cadre de collaboration ....................................................................................................................... 142 82.Incidence des rfrences au modle Open source ......................................................... 143 83.Recours un prestataire de services Passation dun march conjoint ........................143 84.March public de services et mutualisation ...................................................................144
Projet Qualicit............................................................................................................................. 145

1.Prsentation du projet :............................................................................................................................. 145 89.Lacte dadhsion au G.I.E., les statuts du G.I.E. et son rglement dordre intrieur .. 146 90.La convention de projet ................................................................................................. 146 91.La convention dutilisation ............................................................................................ 146 2.Dveloppement par un prestataire de services la demande de plusieurs administrations partageant linvestissement .......................................................................................................................................... 147 I. Aspects mthodologiques __________________________________________________________147 92.Dfinition des besoins fonctionnels : sont-ils suffisamment proches?...........................147 93.Calendrier et gestion du temps ...................................................................................... 147 94.Affectation des ressources financires ...........................................................................147 95.Organisation institutionnelle ..........................................................................................147 96.Taille du groupe au stade du dveloppement ................................................................ 148 97.Comprhension du code-source .....................................................................................148 II. Aspects juridiques _______________________________________________________________149 98.Structure institutionnelle ................................................................................................149 99.Droits et obligations des membres .................................................................................149 100.March public .............................................................................................................. 149 101.Transfert des droits de la proprit intellectuelle ........................................................ 150 102.Conditions dutilisation du logiciel ............................................................................. 150 103.Obligation de non-concurrence ....................................................................................150 104.Conventions de collaboration : traduction juridique de la mthodologie ....................151
Table des matires..................................................................................................................152

Aspects Généraux de La Mutual

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aspects Généraux de La Mutual

Enviado por

Direitos autorais:

Formatos disponíveis

Aspects gnraux de la mutualisation informatique dans le secteur public

Etant entendu que ltude sinscrit dans le cadre du secteur public.

Mutualisation informatique dans le secteur public

2. La mutualisation informatique : divers objectifs

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

3. La mutualisation informatique : aspects mthodologiques et juridiques

Mutualisation informatique dans le secteur public

4. La mutualisation informatique : plusieurs modles

1. Dveloppement, en interne, par une administration seule

2. Dveloppement par une communaut de dveloppeurs-utilisateurs, informaticiens des administrations concernes

3. Dveloppement par un prestataire de services la demande dune administration seule

4. Dveloppement par un prestataire de services la demande de plusieurs administrations partageant linvestissement

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

5. La mutualisation informatique : aspects gnraux

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

La solution doit tre dveloppe - Dveloppement avec perspective d'ouverture ultrieure

Puisquelles conditionnent toute perspective de lancement de march public.

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Ces exemples sont videmment dtaills et exploits dans la suite du rapport.

Mutualisation informatique dans le secteur public

1. Dveloppement, en interne, par une administration "seule"

Enjeu : Comment anticiper l'ouverture ventuelle du logiciel dvelopper?

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

III. Cession des droits ladministration

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Cf. supra, n III et suiv..

Mutualisation informatique dans le secteur public

C. Utilisation dlments Open source : prcautions

Mutualisation informatique dans le secteur public

Cf. infra, n I et suiv..

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Illustration de la premire hypothse : tableau rcapitulatif

-Faire ventuellement appel un prestataire extrieur pour un soutien technique

3. Sassurer laccs aux codes sources

4. Sassurer de la lisibilit du code

5. Sassurer de la clart des langages utiliss

6. Identifier le mode de diffusion et sassurer de sa faisabilit

Mutualisation informatique dans le secteur public

2. Dveloppement par une communaut de dveloppeursutilisateurs, informaticiens des administrations concernes

2.1/ Premier enjeu : Dveloppement du logiciel en communaut (mutualisation en amont)

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Cf. infra, n VIII et suiv.. Cf. infra, n VIII et suiv..

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Mutualisation informatique dans le secteur public

Cf. supra, n VI et suiv..