Cahier des charges logiciel AFEST : modèle et critères

Un cahier des charges logiciel AFEST doit permettre aux fournisseurs de répondre sur le même périmètre et à l’équipe projet d’évaluer des usages réels. Trop général, il produit des promesses difficiles à comparer ; trop détaillé, il impose une solution avant d’avoir testé le besoin. Le bon document expose les objectifs, les acteurs, les parcours cibles, les contraintes et les résultats attendus. Il distingue les exigences obligatoires des options et demande une preuve pour chaque critère important.

Commencer par une synthèse du projet

La première page doit donner le contexte sans jargon interne : activité de l’organisation, populations concernées, répartition géographique, maturité AFEST, outils existants et problème à résoudre. Précisez le périmètre initial et la cible à douze ou vingt-quatre mois. Un pilote de trente personnes et un déploiement auprès de plusieurs milliers d’utilisateurs n’appellent pas les mêmes capacités d’administration.

Ajoutez des objectifs mesurables, sans promettre qu’un logiciel produira seul les résultats. Exemples : rendre l’étape suivante visible pour chaque binôme, réduire les ressaisies, harmoniser les grilles entre sites, suivre les retards ou exporter un dossier complet. Indiquez aussi ce qui est hors périmètre, comme la gestion du catalogue global si elle reste dans le LMS.

Décrire la méthode AFEST attendue

Le document doit rappeler votre conception pédagogique. L’article D. 6313-3-2 du Code du travail mentionne l’analyse de l’activité, la désignation d’un formateur pouvant exercer une fonction tutorale, des phases réflexives distinctes des mises en situation et des évaluations spécifiques. Traduisez ces éléments en processus, sans supposer que l’outil garantit à lui seul la qualité ou la conformité.

Joignez un schéma simple : conception du parcours, affectation, positionnement, préparation, mise en situation, réflexion, nouvel essai, évaluation et clôture. Pour chaque étape, nommez l’acteur, l’information d’entrée, l’action et le résultat. Cette représentation permet au fournisseur d’identifier les adaptations nécessaires et au comité de déceler une réponse centrée uniquement sur des modules.

Modèle de sommaire du cahier des charges

1. Présentation et objectifs : contexte, enjeux, périmètre, calendrier.
2. Utilisateurs : profils, volumes, implantations, équipements et accessibilité.
3. Parcours cibles : processus, rôles, règles et exemples.
4. Exigences fonctionnelles : conception, réalisation, suivi, évaluation, reporting.
5. Exigences techniques : architecture, authentification, intégrations, disponibilité.
6. Données et sécurité : catégories, accès, hébergement, sauvegarde, réversibilité.
7. Services : cadrage, paramétrage, formation, support et maintenance.
8. Déploiement : pilote, recette, migration, conduite du changement.
9. Réponse financière : hypothèses, unités, options et coûts récurrents.
10. Évaluation : critères pondérés, démonstration, pilote et décision.

Formuler les exigences fonctionnelles

Domaine	Exigence exemple	Priorité	Preuve demandée
Conception	Dupliquer un modèle et adapter situations et critères	Obligatoire	Manipulation en démonstration
Affectation	Associer plusieurs rôles et gérer un remplacement	Obligatoire	Scénario exécuté
Terrain	Saisir une observation sur mobile	Obligatoire	Test sur appareil
Réflexivité	Préparer séparément les réponses de l’apprenant	Obligatoire	Parcours de démonstration
Reporting	Filtrer par site, métier, statut et période	Utile	Export d’exemple
Ressources	Lier une fiche ou un module à une étape	Utile	Écran et formats pris en charge

Une exigence doit être testable. Remplacez « interface intuitive » par une tâche, un utilisateur et une condition. Évitez de prescrire chaque bouton : indiquez le résultat attendu. Réservez un identifiant unique à chaque exigence pour faciliter les réponses, les questions et la recette. Les fonctions d’une plateforme AFEST peuvent servir de point de départ, à adapter au processus.

Préciser les profils et les droits

Listez les rôles : administrateur, concepteur, référent, manager, tuteur, apprenant, évaluateur et lecteur. Pour chacun, précisez les actions et les informations accessibles. Le tuteur doit-il voir seulement ses binômes ? Le manager consulte-t-il le détail réflexif ou uniquement l’avancement ? Un évaluateur peut-il modifier l’observation d’un accompagnateur ? Ces choix ont des conséquences pédagogiques et sur la confidentialité.

Décrivez les mouvements : arrivée, mobilité, remplacement, absence et départ. Demandez comment l’historique est conservé lorsqu’un tuteur change. Prévoyez une revue régulière des habilitations et la capacité à exporter la liste des accès. Des droits granulaires sont inutiles si leur administration devient impossible à l’échelle visée.

Cadrer la technique et les intégrations

Fournissez l’architecture cible et les systèmes concernés : annuaire, SIRH, LMS, outil de reporting ou stockage documentaire. Pour chaque flux, indiquez la donnée, la direction, la fréquence, le propriétaire et le traitement des erreurs. Demandez les API documentées, formats supportés, mécanismes d’authentification et limites. Séparez le besoin immédiat des interfaces futures.

Précisez les navigateurs, appareils, conditions réseau et exigences d’accessibilité. Si le travail se déroule en zone mal couverte, décrivez le scénario hors connexion attendu. Fixez les environnements nécessaires, les règles de sauvegarde, les modalités de maintenance et d’information en cas d’incident. Ne recopiez pas un questionnaire technique disproportionné : faites valider ce chapitre par les équipes compétentes.

Encadrer les données et la réversibilité

Dressez les catégories de données réellement nécessaires : identité professionnelle, affectations, statuts, observations, évaluations et pièces. Limitez la collecte et spécifiez les durées selon vos finalités. Demandez la localisation d’hébergement, les sous-traitants, les mesures de sécurité, la journalisation et les procédures de suppression. Les vidéos au poste ou commentaires libres méritent une attention particulière car ils peuvent contenir davantage que l’information pédagogique utile.

La réversibilité doit être opérationnelle : formats, structure, pièces jointes, délai, coût, assistance et suppression après restitution. Exigez un échantillon d’export pendant la consultation. Un PDF lisible peut servir à consulter un dossier ; un format structuré est nécessaire pour migrer ou analyser les données. Les deux usages ne se confondent pas.

Définir les services et la conduite du changement

Le fournisseur doit préciser les responsabilités du cadrage au passage en production : atelier de conception, paramétrage, reprise, tests, formation, supports, assistance et bilan du pilote. Indiquez les populations à former et le format attendu. Un administrateur a besoin d’autonomie ; un tuteur préfère souvent une prise en main courte intégrée à un cas métier.

Demandez les horaires, canaux, délais cibles et niveaux d’escalade du support. Vérifiez ce qui relève du contrat standard et d’une prestation supplémentaire. Prévoyez un dispositif pour recueillir les retours et décider des évolutions. La conduite du changement doit aussi mobiliser managers et métiers : l’éditeur ne peut pas libérer le temps de mise en situation ou d’entretien réflexif.

Exemple de scénario de recette

Pour une entreprise de services, le scénario porte sur le traitement d’une réclamation. L’administrateur duplique un modèle, le manager affecte une salariée et un tuteur, puis programme deux situations. La salariée consulte les critères et prépare l’activité. Le tuteur observe sur mobile, l’entretien réflexif est réalisé le lendemain, puis l’évaluateur renseigne la seconde situation. Enfin, le responsable filtre les parcours du site et exporte le dossier.

La recette précise les résultats : droits respectés, notifications reçues, anciennes données inchangées, export lisible et statut correct. Elle inclut un remplacement de tuteur et une erreur de synchronisation. Ce scénario peut servir durant la démonstration, le pilote et la réception, ce qui maintient la continuité entre promesse et livraison.

Organiser la réponse et la notation

Fournissez un cadre de réponse avec « standard », « paramétrage », « développement », « feuille de route » ou « non disponible ». Demandez délais, coûts et dépendances pour chaque écart. Pondérez adéquation AFEST, expérience terrain, technique, sécurité, services et coût total. Un tableau de notation complète l’échange, mais ne remplace pas les références vérifiables, la démonstration scénarisée et le pilote.

Finaliser votre cahier des charges AFEST

Faites relire le document par un tuteur, un apprenant potentiel, la formation, le métier et le système d’information. Supprimez les exigences sans lien avec un objectif, rendez les autres testables et annoncez clairement le processus de décision. Pour challenger le périmètre ou confronter vos scénarios à une solution, vous pouvez contacter l’équipe Faire pour Apprendre.