Pour que l'accès soit restreint, il ne faut donner l'accès qu'à une application qui contient l'interface homme/machine (des écrans de consultation et/ou de saisie).
Dans ce cas, il y aurait deux bases de données Access, par example ecrans.mdb et données.mdb, les élèves utilisant uniquement écrans.mdb. Dans cette base, il y aurait des formulaires qui iraient accéder aux données de la base soeur données.mdb via le système des "tables attachées". Et d'ailleurs la base ecrans.mdb serait en fait ecrans.mde, c'est-à-dire une version compilée qui ne laisse pas voir le code source. Ca marche, je l'ai fait. L'ennui, c'est qu'il faut programmer les formulaires et cela prend du temps.
Au lieu de la base ecrans.mde, on peut avor une application intranet développée en Apache+PHP+ODBC. J'ai aussi exprimenté cette solution. Personnellement, je la préfère, mais elle demande plus de connaissances et une installation un peu plus longue au départ. Mais ensuite, c'est plus agréable, parce que le VBA a un jeu d'instructions beaucoup moins étendu que le PHP, les formulaires ont des limites que n'ont pas les pages HTML, et parfois le code VBA rame beaucoup.
De toutes manières, si on ne veut quelque chose d'un peu blindé, et qui offre en même temps pas mal de possibilités, cela demande un travail préparatoire important. Une autre approche serait une informatique décentralisée où les élèves travaillent sur une base locale à leur poste, et ensuite les petites bases sont consolidées dans la base centrale au moyen de petits programmes batchs. C'est plus simple mais cela ne permet pas d'interactivité avec la base centrale en direct. C'est suffisant, par exemple si c'est pour que les élèves donnent des réponses à des quizz, ou remplissent des grilles de suivi d'activité.
