Quelques éléments de réponse :
La partie oef2latex qui peut poser des
problèmes d'intégration :
- D'abord parce qu'elle mange énormément de ressources. (Certes, je suis
sûr que le code peut facilement être optimisé, mais là c'est très long.
Sur mon serveur, quand je l'utilise à des heures où aucun élève n'est
connecté, passe encore... Mais sur un serveur grand public, c'est
l'embouteillage assuré...)
- Ensuite, parce qu'elle nécessite des (très petites) modifications dans
le code de wims.
- Surtout parce qu'elle demande d'adapter (même si c'est léger) la
plupart des modules oef.

Explications :
Le module qui produit du latex utilise deux méthodes :
-La première, c'est le module qui traduit le code html généré par le "statement"
de l'oef en code latex (via un programme de traduction html-latex, que
j'ai emprunté sur le net (gpl mais je n'ai pas pu contacter l'auteur) et
que j'ai adapté aux spécificités de wims. Problème : Dès que la page
HTML est un peu complexe (tables, images...), le résultat produit est
assez mauvais.
-J'ai donc opté pour la possibilité d'utiliser une deuxième méthode :
Intégrer aux sources oef une entrée "latex", qui fonctionne comme le
statement, mais contient des codes latex au lieu du html. On ajoute
cette entrée dans le source des fichiers oef (dans modtool par exemple).
Exemple (à insérer dans un exercice)
\latex {
Pose et effectue l'opération :
\\begin{displaymath}
\x \\times \y = \\ldots
\\end{displaymath}
}
On remarque que les \ des codes latex sont doublés, et que l'utilisation
des $ pour les formules mathématiques posent problème. A part ça, toutes
les possibilités de latex sont utilisables.

J'essaie de trouver une solution pour l'intégrer à un serveur wims
classique, mais je bloque un peu...
-Demander à tous les auteurs de rajouter ce code latex ? Ca ne me semble pas très envisageable.
-Retravailler sur le programme de traduction HTML-Latex ? La syntaxe des tables est tellement différente dans les deux langages, c'est assez délicat. Pour ce qui est des graphismes, la traduction des figures flydraw devrait être envisageable (j'avais commencé à travailler dessus,
mais les résultats n'étaient pas parfaits), mais les intégrations d'images posent problème. Et surtout, cette méthode est très gourmande en ressources.
-Utiliser un serveur à part , qui ne ferait que ça... Ca demanderait une synchronisation avec les intégration des nouveaux modules, mises à jour, et des codes latex... Bref, un peu difficile...
-Autre possibilité que j'imagine : générer automatiquement lors de la création des exos oef ce code latex si celui-ci n'est pas présent dans le source. (Donc reprendre un peu l'idée du traducteur HTML-Latex, mais ne l'utiliser que lors de la création de l'exo, et non à chaque utilisation pour impression).
Pour l'instant, c'est cette dernière idée qui me semble la meilleure... Je vais essayer de voir si c'est faisable, et si ça améliore la "consommation de ressources" du module de "latexisation".

En ce qui concerne le module "Mathenpoche", c'est complètement autre
chose. C'est un module d'exercices comme tous les autres. Si ce n'est
qu'il est assez volumineux (car il contient une copie de tous les exos
mathenpoche : 200 Mo environ à première vue). Il n'y a à priori pas
d'autre contre-indication à son intégration à wims.
Si sa taille ne pose pas problème, je peux l'envoyer.

En ce qui concerne mon utilisation en classe, la fréquence et la modalité représentent une équation que je n'ai pas encore parfaitement résolue.
Les contraintes sont :
-Les élèves doivent avoir du travail à faire pendant tout le temps qui leur est donné. S'ils ont un peu trop de travail, ce n'est pas trop gênant dans la mesure où les exercices non faits seront proposés à l'évaluation suivante.
-Le temps de correction ne doit pas être trop excessif (Ca peut vite devenir infernal !)
-La consommation de papier doit être raisonnable (Ce qui n'est pas encore le cas).
-L'an dernier, je proposais à une demi-classe d'être évaluée entièrement sur papier, tandis que l'autre moitié de la classe était en séance "d'entrainement" sur micro (résultats non comptés dans l'évaluation). Le problème majeur était le "décalage" des évaluations.
-Cette année, j'ai ajouté au serveur la possibilité d'utiliser des "examens" pour comptabiliser les résultats des élèves qui travaillent sur micro. J'ai voulu tester au début un partage du temps 1/2 heure papier+1/2 heure ordinateur pour tous les élèves, mais je me suis vite rendu compte que la perte de temps était énorme, et que la progression des élèves était par conséquent très lente.

J'opte actuellement pour une solution hybride, en fonction du niveau de réussite des élèves :
-Les élèves qui ont réussi plus de 80% des exercices lors des précédents contrôles travaillent sur l'ordinateur. Ils n'ont pas beaucoup d'exercices à rattrapper, et ça ne leur prend pas toute l'heure, et peuvent profiter du temps qu'il leur reste pour expérimenter des exercices de chapitres à venir ou des exercices d'approfondissement.
-Les élèves qui ont réussi moins de 60% des exercices doivent travailler sur papier. Le nombre d'exercices à rattrapper leur prend généralement toute l'heure, tandis que s'ils travaillent sur ordinateur, ces élèves mettent beaucoup plus de temps : le problème "informatique" (où cliquer, que faut-il déplacer ?) prenant souvent le pas sur le contenu "mathématique" de l'exercice.
-Les élèves qui ont entre 60 et 80% de réussite ont le choix entre la version papier (qui permet d'assurer les acquis plus rapidement) et la version ordinateur (qui permet d'approfondir et d'explorer).

Christophe.