Centre International de Recherche

sur l’Environnement et le Développement


Nos tutelles

CNRS Ecole des Ponts CIRAD EHESS AgroParisTech

Nos partenaires

R2DS MPDD FUTURS URBAINS LCS-R Net

Rechercher




Accueil > Rubrique de services > Projet site web - Sun Wu Kong > Historique

Cahiers des charges

publié le , mis à jour le

Nous cherchons à externaliser la réalisation et l’installation, en liaison avec l’équipe projet qui fera l’administration système, l’ajout du contenu, les maintenances et les mises à jour ensuite.

La partie réalisation porte attention à la dimension communautaire de la recherche. On pourra s’appuyer sur ce qu’on fait d’autres labos similaires avant. Elle devrait produire du code ouvert de qualité et documenté qui profitera à d’autres laboratoires de recherche dans notre situation.

L’installation comprend notament la réalisation des filtres pour récupérer les bases existantes, la mise en place du squelette, et une séance de formation des éditeurs de rubriques. Le travail de saisie, vérification des contenus, nettoyage des bases importées ne fait pas partie du lot, non plus que la localisation vers l’Anglais et le Portugais.

Tout doit être fait dans l’esprit SPIP, i.e. sans toucher au code du CMS lui même, mais dans le squelette ou avec du code séparé, et en logiciel Libre. On se basera sur la version courante de SPIP. Tout sera développé en Français mais internationalisé (i.e. tout UTF-8).

Le temps et les compétences d’administrateur sont les facteurs limitants, par contre le système sera hébergé sur un serveur Linux dédié, pas neuf. On peut supposer dans un premier temps qu’il s’agit d’une Mandrake. Ayant spécifié les fonctionnalités et la qualité, nous laissons le réalisateur proposer budget et calendrier.

La liste des tâches et deliverables qui suit est ordonnée par urgence. Notre demande est séparée en trois volets car nous ne savons pas encore jusqu’où nous voulons aller cette année.

Ayant assez tôt exclu l’idée que SPIP devienne Lotus Notes, pour la partie intranet 6 à 10 nous hésitons actuellement entre deux options : utiliser une application tout intégrée, ou alors l’approche "best of the breed" c’est à dire une série d’application spécialisées (genre squirrelMail, roloDAP, refDB, webCalendar, myExplorer) qui fonctionnent en réseau faiblement couplées en partageant :
- authentification
- header, footer, navigation de niveau zéro entre les applis, feuille de style globale
- données d’annuaire et de référence bibliographiques

La seconde approche a ma préférence actuelle compte tenu que e- et php-groupware sont en beta et ne contiennent pas de module de partage des références bibliographiques.

Le code du squelette sera relocalisable : sa bonne exécution ne dépendra pas du nom du sous-répertoire dans lequel il résidera. Le squelette sera thémable (par l’administrateur) : les feuilles de style, icônes, fonds, bandeaux et autre éléments graphiques résideront dans un sous-répertoire du squelette. Les options du squelette seront peu nombreuses, leur configuration sera centralisée dans un fichier texte, avec une interface PHP en ligne. Le squelette sera internationalisé, les chaines de caractères seront dans un fichier à part. Le design et le code seront documentés et revus par un expert qualifié différent du programmeur initial.

L’implémentation des champs supplémentaires exploitera les facilités existantes (mots-clés pour les descripteurs dans un vocabulaire contrôlé) et celles en développement (SPIP-XML et/ou champs EXTRA) dans un souci de compatibilité future. L’écran d’entrée des productions scientifiques sera non seulement fonctionnel mais attrayant.

I. Site de présentation

- 1. Récupérer le squelette SPIP du département de mathématiques et d’informatique de l’ENSICA (dmi.ensica.fr), j’ai l’autorisation du webmestre. Le mettre sous contrôle de version, puis l’implémenter au CIRED. Créer un style visuel par défaut neutre, implémenter le thème CNRS selon le kit graphique fourni, recopier le contenu du site CIRED existant.

Deliverables :

1.1 Site fonctionnel. Qualité : sans régression par rapport à l’existant. Le labo se chargera de la mise à jour et des traductions ultérieurement. Le site sera accessible sous Lynx, Netscape 4, IE, Konqueror, Mozilla. Les pages et feuilles de style seront validées labelvue et W3C HTML 4.01.

1.2 Système de recherche en texte intégral dans le contenu des articles ainsi que des pièces jointes PDF et RTF (note : le moteur open source usuel est htdig). Nous ne prévoyons pas actuellement de mettre en place un vocabulaire de mot clés systématique.

1.3 Scripts d’aspiration de squelette qui implémente les heuristiques décrites dans spipage.
Qualité : Capable d’aspirer par http le squelette SPIP standard et le squelette à développer au 1.1. Script de packaging (tarball) du squelette aspiré.

- 2. Faire une distribution de squelette pour labos. Cette tâche est répétée au fur et à mesure de la réalisation des autres modules. La distribution doit fonctionner par défaut à l’installation avec des exemples auto-documentant les divers styles de pages disponibles. Le téléchargement de la distribution se fera à partir du site lui même.

Deliverables :

2.1 Scripts d’installation et de configuration automatique (en liaison avec 1.3).

2.2 Système de test. Il s’agit d’être capable de donner une assurance que le fonctionnement est conforme, en repartant d’une installation sur une Mandrake fraîche. Une partie sera automatique (par exemple des tests de régression pour certains scripts), une partie sera descriptive.

2.3 Documentation en français pour webmestre pressé et non spécialiste. README, INSTALL, note sur comment customiser le style, aide en ligne dans les squelettes.

2.4 Suite de tarballs et RPM de la distribution. Chaque brique logicielle open-source sera distribuée en trois parties. 1/ Le programme lui même (pour la plupart le RPM existe déjà mais pas pour tous) tel que distribué publiquement par ses auteurs. 2/ Les fichiers de configuration, la doc, les scripts et autre aides à l’installation, ainsi que le squelette et le style Libre. 3/ Les éléments d’image propres au CNRS seront distribués séparément sous la forme d’un thème (d’un kit graphique) utilisable uniquement par les labos sous tutelle. La frontière entre 2 et 3 devra être validée par la DSI du CNRS.

II. Système de publication scientifique

Le système de base de données qui tient la liste des productions scientifiques du labo assurera la consistence de la base quand à l’orthographe des noms de journaux et d’auteurs. Les textes intégraux en PDF seront stockés dans un système de fichiers organisé (i.e. pas tout en vrac dans le même répertoire) selon la structure actuellement en cours de définition.

- 3. Exporter les fiches résumé et rapports d’activité préremplis, en particulier les publications.

3.1 Squelette qui stocke, permet de modifier et d’afficher en ligne si désiré les données personnelles requises. Voir aussi 5.2.

3.2 Script et squelette produisant soit du LaTeX+bibtex, soit du RTF, préremplissant les gabarits fournis par le CNRS pour les rapports d’activité annuels et [d’évaluation http://www.sg.cnrs.fr/drhchercheurs/evaluation/default.htm] des chercheurs.

3.3 Pareil pour les rapports d’activités du labo.

- 4. Système de publication de documents de travail selon la pratique en économie : le laboratoire peut définir plusieurs collections de documents dont il publie en ligne les méta données lui même.

4.1 Script et squelette pour coller une page de couverture appropriée (numérotation, utilisation et renseignement des méta données) devant le PDF soumis dans une sous-rubrique spéciale.

4.2 Script et page d’export de la collection selon le protocole OAI-PMH statique , avec schéma de métadonnées Dublin Core non qualifié.

4.3 Script et page d’export de la collection selon le protocole RePEc avec schéma de métadonnées ReDIF.

- 5. Homepages des auteurs. Trois niveaux seront prévus. Les fonctionnalités seront documentées et il y aura des exemples.

5.1 Homepage minimale (données d’annuaire et liste des publis) ne nécessitant pas d’intervention.

5.2 Homepage présentant en plus un résumé de l’activité professionelle. Le squelettes utilisera les champs SPIP pour stocker les données nécessaires à la fois à la homepage et au rapport annuel visé au 3.1.

5.3 Interface avancée offrant l’édition du style et du squelette pour un contrôle total de la rubrique personnelle. Les auteurs doivent avoir autorisation administrative totale dans leur homepage (c’est en fait une rubrique au sens de SPIP) et peuvent créer des sous-site complets. La modification des fichiers peut se faire soit en ligne genre sitenkit, soit en passant directement par l’intranet (aux risques et périls de l’utilisateur).

III. Portail

III Développements préliminaires

- III.1 Document de travail articulant une vision de l’infrastructure et décrivant comment le CMS réalisé se place en relation avec le ou les autres applicatifs des points 6 à 9.

- III.2 Mise en place de la personalisation du contenu nécessaire pour que le public non authentifié ne voit pas les éléments de contenu qui ne le concerne pas.

- 6. La base LDAP comprend deux parties : les auteurs du CIRED et les contacts extérieurs. Les contacts sont gérés par un système de carnets d’addresse qui simplifie rolodap en autorisant un seul carnet d’addresse par user, avec contacts privés ou partageables. Le système permet mais n’oblige pas la séparation des personnes et des institutions.

6.0 Définir et documenter le schéma. A priori les chercheurs sont à la fois des inetOrgPerson et des eduPerson. Il faut être nominnalement compatible avec les normes françaises émergentes dans l’administration, au CNRS et aux universités puisqu’on voudra faire partie d’un système LDAP institutionnel/national/international de la recherche.

6.1 Installation du carnet d’addresse comme un service d’intranet autonome mais accessible par le portail principal et visuellement coordonné. Champs expliqués à l’écran. Documenter comment utiliser dans Eudora. Formation d’une gestionnaire.

6.2 Importer le carnet d’addresse existant dans la base LDAP. Le travail de nettoyage minutieux sera assuré par le CIRED.

6.3 Gestion des auteurs dans SPIP par LDAP.

- 7. Interface avec le CCSD

Le système de publications scientifiques au II. exploitera l’information du carnet d’adresses pour connaitre la relation d’appartenance (multiple) auteur / laboratoire de recherches / institutions.

7.1 Support par le serveur OAI-PMH du schéma de métadonnées XML défini par le CCSD [http://hal.ccsd.cnrs.fr/oai/elements/ccsd_hal.xsd].

7.2 Interface avec le système HAL : remontée des textes intégraux au CCSD, redescente des statistiques.

- 8. Webmail, Calendrier, Listes de diffusion, liste des tâches : avec évènements répétés et avertissement mail automatique pour les intéressés. Le système sera intégré avec le carnet d’addresse et le mail du CIRED . Il offrira l’authentification unique. Il sera intégré avec les fonctions calendrier de SPIP.

8.1 Installation, intégration, mise en place d’une navigation transversale entre applications

8.2 Développer un style visuel harmonisé

- 9. Gestionnaire de référence bibliographiques à la RefDB (encore beta) ou refbase (encore alpha). Ce système de gestion des références bibliographiques doit intégrer automatiquement les documents de travail et les publications des chercheurs. Relier les gens dans le carnet d’addresse aux auteurs des articles n’est pas fondamental. Le système assurera la consistence de la base quand à l’orthographe des noms de journaux et d’auteurs.

9.1 Installation d’une DB de références, import/export BibTeX et RIS. Test : roundtrip de hdm-main.bib et de la biblio endnotes (de JCH ?).

9.2 Synchronisation avec les documents publiés par le labo gérés dans SPIP. Ce point devra être pensé dès le début du II.

9.3 Intégration en consultation et modification des références.

Test : Les articles déjà sur le site apparaissent et peuvent être modifiés. Les documents de travail apparaissent. On peut ajouter des articles ainsi que des références.

- 10. Garantie et suivi 12 mois post-installation :
Les contributions seront directement versées par le prestataire sur le site public de développement du projet. Sauf accord préalable, la garantie ne concerne que les sources dans leur version livrée d’origine et non les développements ultérieurs.

10.1 Intervention 1/2 journée à un séminaire de lancement.

10.2 Maintien des packages avec qualité de service définie : mises à jour de sécurité sous 2 jours, correction des bugs confirmés sous 2 semaines, compatibilité avec les nouvelles versions de SPIP et Mandrake.