Le projet a été financé et accepté. Formagraph a recruté une partie des ressources humaines nécessaires (côté développement: 1 chef de projet + 1 développeur, 1 autre développeur est prévu).

Mon rôle qui semblait au départ limité (à l'aspect personnalisation) risque d'être plus important que prévu car:

1. le chef de projet n'est pas techniquement apte à rédiger le chier des charges sur les problématiques concernant la personnalisation et le portefeuille de compétence: ce seront très probablement Noa et moi qui le feront;
2. il faut convaincre Claroline, ce qui peut prendre du temps et nécessiter de l'investissement humain; l'avantage, c'est que ça m'oblige à présenter mes idées et à les défendre;
3. Formagraph sera le maître d'oeuvre de la prochaine version de Claroline

Point très positif: le développeur recruté est a priori bon.

Noa me demande donc de continuer mes spécifications, et d'identifier ce que je peux faire développeur par d'autres que moi (le développeur de Formagraph pour l'instant).

A priori, ça sera essentiellement tout ce qui concerne les interfaces graphiques hormis le module d'élaboration.

Je réalise donc les maquettes pour les interfaces

Je poursuis le développement et les spécifications de l'API de personnalisation

Je réalise des interfaces très (très) basiques : pas de contraintes esthétiques, pas d'implémentation dans claroline⇒ ce sera le développeur qui le fera

Le développement se passe bien, même si j'ai toujours du retard sur ce que j'avais prévu.

Toute la partie “sources de connaissance” est traitée. Ci-joint les derniers modèles établis:

Lien vers la documentation (en anglais) de l'API: http://bruno.mascret.fr/tests/apiPerso/doc/index.html

Lien vers le benchmark de l'API sur ce serveur (tout ne marche pas pour des raisons de droits que je ne vais pas régler tout de suite, ce n'est pas prioritaire): http://bruno.mascret.fr/tests/apiPerso/Test.php

Snapshots du benchmark complet réalisé sur mon instance locale (ma machine):

• benchmark complet
• benchmark profil donné par Blandine
• benchmark profile instance d'ipacome

J'en suis à l'implémentation de la grammaire de contraintes (qui inclus cPMDLe, mais qui sera plus générique). J'ai choisi d'utiliser un moteur d'interprétation de règles en xsl qui facilitera les opérations de transformation (personnalisation) des structures arborescentes.

Je n'ai plus de grosses difficultés techniques avec le langage (PHP), ce qui fait que j'avance vite.

Je n'ai pas non plus de blocage particulier pour le moment.

J'ai montré ce que j'ai fait à Noa qui est satisfait et m'encourage à continuer.

Je fournirai des interfaces très basiques qui seront améliorées et/ou intégrées dans claroline par le développeur rrecruté chez Formagraph.

Une de ces interface permettra notamment à Formagraph de créer/saisir des profils implémentant IPACOME (voir instance d'example sur les snapshots ci-dessus).

Après avoir discuté avec Blandine, il apparaît fondamental de mettre très au clair le schéma/dtd de PMDLe: Blandine l'utilise à sa sauce en fonction de ses besoins, elle l'a augmenté de différents éléments dont certain sont redondants (après coup) avec des propriétés que Carole n'avait pas très bien (ou du tout) documentées. Je pense que lorsque Carole a implémenté son modèle, elle a du faire face à des contraintes techniques qu'elle a évacué de manière adhoc (ce n'est pas une critique), car son objectif n'était pas de fournir à ce moment-là un modèle partageable mais de valider ses travaux.

La conséquence est que le modèle ainsi obtenu n'est pas un modèle dont on peut se servir comme référence pour une utilisation générique avec d'autres applications que celles utilisées jusqu'à présent.

Il est indispensable de se mettre d'accord sur ce schéma.

De même, il m'apparaît de plus en plus évident que les échelles doivent être modélisées dans un autre schéma, et référencées au bon niveau dans le schéma de PMDLe (i.e.: propriété ou attribut de l'évaluation, pas de la composante) ET de manière optionnelle.

J'ai besoin de pouvoir présenter un modèle générique et représentatif à Claroline, “nettoyé” de tout ce qui a été rajouté pour faciliter l'exploitation dans un contexte très particulier (bâtisseur).

Ce modèle doit également être utilisable en français ET en anglais. C'est techniquement réalisable et prévu avex xml schema.

Pour l'instant, voici où j'en suis: PMDLe XML schema

Blandine m'a envoyé ses fichiers XML pour les échelles, je vais faire un schéma séparé pour modéliser ces échelles (c'est rapide et simple, moins complexe que pour PMDLe).

Si ce travail n'est pas fait (rapidement), PMDLe restera un modèle utilisé uniquement dans les applis SILEX et ne sera pas diffusé… C'est quand même dommage!

J'ai passé beaucoup de temps sur l'article TICE. Ce n'était pas forcément ce que vous m'aviez demandé mais:

1. je ne sais pas bâcler, et je n'aime pas le faire surtout quand je suis en premier nom;
2. quoiqu'on puisse dire sur l'impact de cette conférence, la moindre des politesses est de fournir un travail qui rend honneur à la qualité des reviews dont nous avons bénéficié.

Pour éviter des incompréhensions/problèmes lors de nos prochaines collaborations, je vous propose d'adopter systématiquement la démarche suivante:

1. prévenir tout le monde (Stéphanie, Noa, Amélie, Bruno) lorsqu'on a l'intention de publier quelquechose qui concerne de près ou de loin ma thèse;
2. définir à l'avance qui écrit, qui ne souhaite pas participer, qui est le corresponding author, le premier auteur, etc.
3. faire un plan de publication avec ceux qui participent.
4. prévenir systématiquement les auteurs lorsqu'on modifie ne serait-ce qu'une virgule du texte soumis, suffisamment tôt pour permettre une relecture si nécessaire.

Cette organisation correspond à ce que nous avons décidé à l'oral.