Points essentiels
- Les erreurs critiques de données statiques bloquent tout résultat faisable ; corrigez-les avant toute génération.
- L’analyse dynamique vient après les contrôles statiques et avant l’optimisation.
- Les vérifications block build, combing chart et what-if prouvent que la structure peut se planifier.
- Menez deux migrations de test : la première trouve les manques, la seconde prouve qu’ils sont corrigés.
Corrigez d’abord les erreurs critiques
La validation a un ordre. Les erreurs critiques de données statiques viennent en premier parce qu’elles bloquent tout résultat faisable : tant qu’il en reste une, aucun passage du solveur ne peut réussir, quels que soient les réglages.
L’analyse dynamique suit. Ce n’est que lorsque les deux passent que l’optimisation vaut son temps de calcul. Cet ordre protège le temps du solveur, et il évite que l’équipe lise des erreurs de données comme des problèmes de conception d’emploi du temps.
Prouvez que la structure peut se planifier
Un jeu de données peut être propre et rester impossible à planifier. Les vérifications de faisabilité telles que le block build, le combing chart et les tests what-if existent pour prouver que la structure peut se planifier avant de faire confiance à une génération automatique.
Si ces vérifications révèlent des problèmes structurels, corrigez la structure. Les réglages d’optimisation ne peuvent pas compenser un modèle qui n’a aucune réponse faisable.
Ordonnez le point de contrôle
Déroulez le point de contrôle dans cet ordre ; chaque étape suppose que la précédente a tenu.
- Menez la première migration de test et listez chaque manque de correspondance et de qualité de données qu’elle révèle.
- Corrigez les manques à la source, dans les données ou dans la correspondance.
- Menez la seconde migration de test pour confirmer les corrections.
- Corrigez toutes les erreurs critiques de données statiques qu’elle signale.
- Lancez l’analyse dynamique et traitez ce qu’elle soulève.
- Lancez les vérifications de faisabilité, et ne démarrez l’optimisation que lorsque la structure passe.
Comment faire dans Smootables : la validation avant génération
Fall 2026
Recurring weeks18.8.2026 - 20.12.2026 / 18 weeks
Validation errors
Teacher hours exceeded (1)
Teacher "J. Rivera" has 28 hours/week assigned; maximum is 24 hours/week.
Reduce this teacher's workload or increase their weekly maximum hours.
View teacher
Insufficient rooms (1)
This period needs at least 3 room(s) for your student groups, but only 2 are available.
Add more rooms in Resources or reduce the number of student groups with lessons in this period.
Go to rooms
Smootables lance la validation avant de dépenser le moindre temps de solveur : Générer l’emploi du temps vérifie d’abord le plan de période et signale les problèmes au lieu de tenter un passage condamné. Le bouton Voir les erreurs ouvre le panneau Erreurs de validation, où chaque constat est typé (Enseignant manquant, Salle manquante, Heures d’enseignant dépassées, Salles insuffisantes) et mène à la correction : Voir le placement, Voir l’enseignant ou Aller aux salles.
Si la génération échoue quand même, le rapport qui suit explique pourquoi, avec des causes de conflit typées et des actions suggérées comme réduire la charge d’un enseignant ou ajouter des salles. Le point de contrôle épargne le passage ; le rapport explique le passage qui a tout de même échoué.
Pourquoi deux migrations de test
La première migration de test révèle les manques de correspondance et de qualité de données. La seconde confirme que les manques sont corrigés. Sautez la seconde et vous ne pouvez pas dire si les réparations ont tenu ou si vous avez eu de la chance.
Traitez la paire comme une seule unité de travail. Une migration qui a passé une fois a été testée ; une migration qui a passé deux fois a été vérifiée.
Quand une vérification échoue
Quand une vérification nomme un échec précis, allez droit à sa réparation : corriger un enseignant réservé deux fois ou résoudre un conflit de salle.
Les échecs structurels sont souvent des problèmes de contraintes déguisés. La frontière entre les deux est couverte dans contraintes dures.
Questions des planificateurs avant de générer
Une seule migration de test suffit-elle si elle passe ?
Le rôle du premier passage est d’exposer les manques de correspondance et de qualité de données, donc un premier passage propre est rare. Le second passage, après corrections, est la preuve que les réparations ont fonctionné.
Quelle est la différence entre contrôles statiques et vérifications de faisabilité ?
Les contrôles statiques demandent si les données sont valides en elles-mêmes : champs présents, références intactes. Les vérifications de faisabilité demandent si des données valides peuvent réellement produire un emploi du temps. Les deux peuvent échouer indépendamment.
Que sont les vérifications block build, combing chart et what-if ?
Des techniques de faisabilité issues de la pratique de la planification scolaire, utilisées pour prouver que la structure peut se planifier avant une génération automatique. Si votre outil n’utilise pas ces noms, cherchez les vérifications qui répondent à la même question : cette structure peut-elle se planifier tout court ?