83•145

L'open source et le travail collaboratif, réalisation d’un pgi pour l’enseignement supérieur

Par Jean-Marc CORIS

De la brique élémentaire à la constitution d'un PGI / ERP (Progiciel de Gestion Intégré) libre et Open Source pour l'enseignement

supérieur français public incrémental et évolutif : un exemple ? Cela concerne l’informatique « métier » et se situe entre une externalisation

qui peut se révéler aliénante et une internalisation qui a pu se révéler sclérosante. Notre troisième voie est-elle possible et viable?

Lecontexte

Le système d’information (SI) d’une université publique est un système complexe avec une situation au niveau du SI encore assez archaïque.

Son niveau d’intégration est faible, son urbanisation se faisant au coup par coup de manière très individualisée ou non coordonnée et dont le schéma d’interopérabilité interne ou externe se limite le plus souvent à un annuaire minimaliste (LDAP) !

Un cloisonnement fonctionnel « naturel » encouragé par des domaines « réservés » : l’Enseignement, la Recherche, la gestion associé à un individualisme certain débouchant sur une architec-ture multi-référentielle aux conséquences négatives.

L’approcheCocktail

Lesorigines

A la rentrée 1993 l’université de La Rochelle ouvre ses portes. C’est une nouvelle université (Plan universités 2000), une petite université sans histoire (sans passé), sans le poids des habitudes, sans moyen, sans “réserve” financière mais pas sans ambition et sans esprit de “pionnier”.

Toutes les conditions étaient alors réunies, coïncidant avec la matu-rité (trop précoce !) du système NeXStep (aussi excellent que rare) et le “big bang” de l’Internet, pour mettre en place une informatique globale d’établissement particulièrement simple et efficace et ce quel que soit le niveau : réseau, système, référentiel (annuaire), applica-tions / services.

84 •145

Les ressources humaines en développement en 1993 : 3 ETP (équivalent temps plein) de l'université de La Rochelle. En 2007 les ressources humaines en développement : 15 ETP (hors direction) officiels mais répartis entre La Rochelle (5), Paris Descartes (3), Mulhouse (1), Nlle Calédonie (1), ENS Cachan (1), Provence (0,5), Le Havre (0,5), Externalisation (3).En 1997 : le système comprenait 10 briques (applications) logi-cielles opérationnelles,

Aujourd'huien2007 : il y en a plus de 100 briques (applica-tions) logicielles, c’est le PGI Cocktail !

Toutes ces briques et leur référentiel unique constituent en effet un PGI spécifique enseignement supérieur, modulaire et développé avec des ressources propres / internes. Cinquante établissements d’enseignement supérieur géographiquement très répartis et de tailles très variables utilisent tout ou partie des modules applica-tifs (composants) de ce système.Ainsi à partir des solutions logicielles développées pour les couches référentiel (annuaire) et applications / services il s'est alors constitué par incréments successifs et cohérents ce qu’il est convenu d’appeler un véritable PGI spécifique dynamique et agile

s'adaptant par enrichissements successifs aux établissements aux situations les plus complexes.La couverture fonctionnelle se veut ainsi la plus large possible évoluant au plus près des besoins des établissements compte tenu même du modèle économique et collaboratif. Ce qui distingue ce PGI est certainement son référentiel unique véritable socle du système global d'informations sur lequel viennent se "pluger" (se loger) tous les modules applicatifs du consortium Cocktail sans exception mais sans exclusive ! Tout autre pouvant s'y intégrer (Open Source).Développées par des agents de l’Etat, avec des moyens de l’Etat et pour des établissements publics, ce sont donc des réalisations naturellement « publiques », ouvertes et libres. Leur licence d’uti-lisation et de développement est la licence CeCILL (Licence GPL (Gnu Public Licence) « francisée » par le CEA, le Cnrs et l’Inria pour les Logiciels Libres. Le modèle économique basé sur l'Open Source collaboratif en garantit la pérennité dès lors que le nombre d'utilisateurs devient suffisam-ment important. Il peut se trouver renforcé par l'adhésion de SSLL (Société de Services en Logiciels Libres), ce qui est aujourd’hui le cas. Ces SSLL certifiant et qualifiant ainsi les applications. Les équipes de développeurs du consortium ne reposant que sur des fonctionnaires pérennisent en quelque sorte les déve-loppements, mais ce doit être assorti d’un management moins traditionnel !

Ces caractéristiques assurent :Pune situation financière très saine car sans charge de personnel (les emplois de fonctionnaires n’ont pas été créés pour le consortium et n’ont pas été détournés de leur mission initiale d’exploitation d’application ou de référentiels. Paradoxalement ils pourraient même être en plus grand nombre dans le cas de PGI du commerce ! Paucun coût d'infrastructure supplémentaire puisque le travail collaboratif est totalement virtualisé (modèle Internet).PLes « économies » en ressources humaines et financières ainsi réalisées peuvent se révéler importantes et dégager indirectement de « nouvelles » ressources pour les activités principales (ensei-gnement et recherche) de nos établissements.PParmi les autres effets de bord particulièrement positifs de ce modèle participatif, une responsabilisation, une professionnalisa-tion, une double compétence et un maintien à très haut niveau des équipes techniques de fonctionnaires oeuvrant à ces développe-ments soit une valeur ajoutée s’ajoutant à celle déjà fournie par l’utilisation des applications.

Le PGI Cocktail est une solution opérationnelle toujours en évolution tant sur le plan fonctionnel, technologique qu’organisa-tionnel. Il présente aussi de nombreux autres avantages comme :PLa satisfaction des utilisateurs qui disposent d’une couverture fonctionnelle inégalée grâce à ce PGI spécifique modulaire d'une grande souplesse et grande facilité d'installation de par son para-métrage très faible puisque limité à l’enseignement supérieur public.PLa disponibilité d'un entrepôt global de données disponible à tout instant, ne nécessitant aucun accessoire supplémentaire et

85•145

offrant des moyens de pilotage et de gestion prévisionnelle ou analytique naturels.La souplesse et la grande réactivité des développeurs offrant aux applications une forte capacité d’adaptation aux besoins des établissements.L'ouverture des applications et leur capacité à l'interopérabilité donnant un degré de liberté aux établissements en matière de choix renforçant par la même occasion leur autonomie.Un catalogue riche d'applications adaptées à l'enseignement supé-rieur et toujours en Open Source.L'assistance de SSLL pour les besoins spécifiques propres à chaque établissement pouvant permettre de résoudre l'absence de compétences immédiates ou de répondre à des besoins ponctuels.

Le«modèle»économiqueest celui de l'Open Source, ces appli-cations ne sont pas vendues mais « distribuées » dans un esprit logiciel libre ou Open Source « aménagé ». L’objectif est de voir chaque établissement s’accaparer le(s) produit(s), d'apporter sa pierre à l'édifice, de participer explici-tement ou implicitement à un système d’information intégré paramétrable, modulaire et totalement maîtrisé pour les établis-sements universitaires.Remarque :Il ne s’agit pas ici de logiciels « plats », génériques ou « univer-sels » comme Linux, OpenOffice, Apache, MySQL, Spip, … mais de logiciels métier, nécessitant, en plus des informaticiens, des experts fonctionnels. Ces logiciels sont développés suivant une architecture n-tiers (n>2)

Les vrais « problèmes » à résoudre tiennent :P à l’organisation du travail collaboratif en réseau qui constitue dans un tel modèle (métier) un véritable challenge, Pau pilotage du développement, Pà la coordination et à la synchronisation des différents niveaux, Pà la gestion de la documentation, Pà la gestion de la maintenance corrective et évolutive, Pà la mise en place des formations, à l'animation, Pà la mobilisation des experts fonctionnels et à la réalisation de cahiers des charges précis.

L’organisation se veut souple et très « plate » (ou en râteau) à l’image des projets Open Source pour une responsabilisation forte et un accaparement de l’ensemble du projet par chaque établis-sement. La discipline des développeurs et leur coordination sont essentielles à la réussite des projets.

Lecadre formel est un un Consortium (Cocktail), sans person-nalité juridique, présidé aujourd'hui par l’Université de La Rochelle :Il a pour fonction d'organiser la mutualisation autour de ces réali-sations logicielles.Le consortium met GRATUITEMENT à la disposition de la communauté universitaire et des administrations la totalité des logiciels qu’il développe.Cette mise à disposition se fait suivant le modèle de l’Open Source encadré par la charte de co-développement que le consor-tium impose comme préalable à tout usage collaboratif de ses logiciels.

• L'architecture mono-référentieldonne : Cohérence, Fiabilité, Economie globale, Traçabilité, Agilité, Efficacité, Réactivité et ... le décloisonnement des domaines fonc-tionnels et des personnels qui s'oppose à :• l'architecture multi-référentieldominante encore aujourd'hui avec :Pson mode « batch » ou asynchrone des années 70, Pses incohérences produisant des indicateurs grossiers voire faux, Pson pilotage à vue et souvent au « feeling », Psa réactivité faible incompatible avec les exigences modernes, Pson cloisonnement des personnels y compris les informati-ciens, Pune dématérialisation faible ou inexistante (en gestion), Pses entrepôts de données « usine à gaz », Pses référentiels externes minimalistes (annuaires LDAP), Psescoûts«cachés»particulièrementimportants,P…

L'approche Cocktail se distingue aussi de la mutualisation institutionnalisée (GIP AMUE - Agence de Mutualisation des Universités) qui, c'est un constat, n'a pas vraiment joué le rôle d’outil facilitateur, fédérateur et mutualisant qu’on attendait. Enfin le récent choix de l'AMUE en faveur de SAP, limité à la sphère de la gestion financière et comptable (GFC), ne rassure pas sur ce point et pose plus de questions qu'il n'apporte de réponses non pas à la problématique de la GFC mais à celle du Système Global d'Informations à gestion intégrée.SAP repose sur les mêmes concepts de référentiel unique que Cocktail et le choix de SAP aurait du être fait comme celui d'un PGI du commerce pour l'enseignement supérieur bien que ce PGI (du commerce) n'existe pas (encore). Le PGI Cocktail existe quant à lui et de par sa présence maintient une alternative libre et ouverte pour notre communauté qui agit de fait comme un régu-lateur et une « référence » pour les établissements d'enseignement supérieur.Pour la circonstance on peut penser que c’est une véritable chance

86 •145

pour nos décideurs qui disposent ainsi avec Cocktail du moyen de comparer et de choisir !Alors, ce "système" (Cocktail) est-il viable ? On pose en effet souvent la question de la pérennité, de la garantie, etc. On pourrait trouver ces questions saugrenues car :PL'éditeur est un consortium d'établissements (institutions publi-ques) PLes développeurs sont des fonctionnaires titulairesPLes sources sont ouvertes et libres. (Licence CeCILL)PCela fait plus de 10 ans que ça marche !PLa latitude (liberté) est grande pour chaque établissement de participer au développement et à la maintenance et le retour sur investissement important. Il est à noter que contrairement au mode opératoire de l'Open Source la décision de contribuer n'est pas celle d'individus mais de personnes morales !

Mais alors, pourquoi ces questions ? Parce que les mêmes ne font pas confiance à leur propre capacité à manager ce genre de projets de "création" dans le contexte « fonction publique » qui, paradoxalement, pourrait paraître conçu pour !Ils n’ont pas tout à fait tort car la plus grande difficulté rencontrée se situe au niveau du management de ressources « publiques ».C’est effectivement le seul véritable obstacle à la pérennité et à l’efficacité permanente de ce modèle. Mais c’est aussi le vrai défi à relever par nos structures si elles veulent s’adapter à ce genre d’activité de création et non de pure gestion « suiveuse ». Cela nécessite : des compétences pointues à maintenir (formation permanente), une gestion du temps rénovée avec l’acceptation d’une part de télétravail ou de mode isolé qui pourrait davantage responsabiliser les personnels et s’affranchir d’une certaine forme « d’irresponsabilité collective », une valorisation réellement aux résultats, une gestion du turn-over, une remise en question perma-nente, un état esprit, une culture service public repensée, … La GRH « fonction publique » n’est pas, aujourd’hui, adaptée et se doit d’évoluer dans une logique de résultat, ce que la LOLF laisse entrevoir (?).

L'avenir pour Cocktail pourrait être prometteur notamment si le passage du cap de la commercialisation / accompagnement par les

SSLL est réussi. Les mois qui viennent sauront nous le dire. Le marché des collectivités pourrait être aussi un débouché particu-lièrement attirant pour les SSLL.Si nous voulons cependant conserver la maîtrise de l’édition des logiciels, il faudra que les mentalités évoluent surtout dans les classes dirigeantes et que la confiance dans les forces internes revienne pour que l’on passe du modèle « administrato-monar-chique » à celui de la complémentarité des compétences et du travail en équipe. Enfin « Small is ‘toujours’ beautiful » et cela s’applique à tout … y compris aux dépenses !Il y a en effet comme une spirale de la dépense qui conduit certains décideurs à penser que leur politique ou leur professionnalisme sera à la hauteur de leurs dépenses et les amène à mépriser ce qui est gratuit ou « free » !

Pour terminer et illustrer cela une petite anecdote (à méditer) :Un président d’université « rêvait » publiquement d’une campagne d’affichage dans les couloirs du métro : « Les Universités Françaises ont choisi SAP » à l’image de ce qu’il avait vu dans les salles d’attentes d’aéroports : « PORSCHE a choisi SAP » … presque pathétique, non ? n

Jean-Marc CorisestleDirecteurdelaDSI

del’UniversitédeParisDescartesetleDirecteurduConsortium

Cocktail.IlestIngénieurCNaMenInformatique