Points essentiels
- L’analyse statique vérifie les données seules ; l’analyse dynamique vérifie données et contraintes ensemble.
- Les problèmes critiques de chaque étape bloquent l’optimisation jusqu’à correction.
- Block build, combing charts et clash tables portent les contrôles de faisabilité de la planification jusque dans la validation.
- Une validation propre augmente les chances d’un emploi du temps faisable ; elle ne peut pas le promettre.
Étape un : l’analyse statique
L’analyse statique demande si les données brutes sont utilisables : des valeurs manquent-elles, des enregistrements sont-ils dupliqués, chaque cours est-il doté en personnel. Ce sont des problèmes de données, et ils ont des responsables de données. Aucune logique de placement n’entre encore en jeu.
Corrigez-les à cette étape parce que c’est là qu’ils coûtent le moins. Un type de salle manquant trouvé par l’analyse statique est un champ à remplir ; la même lacune trouvée en pleine génération est une exécution échouée à diagnostiquer.
Étape deux : l’analyse dynamique
L’analyse dynamique combine les données avec les contraintes actives. Elle peut révéler qu’un placement requis est impossible, que des contraintes se contredisent, ou qu’une structure ne peut pas tenir ses propres engagements. Rien de tout cela n’est visible pour les contrôles statiques, parce que chaque enregistrement semble correct pris isolément.
Les routines de faisabilité côté planification (block build, combing chart, clash table) appartiennent à cette étape dans l’esprit : elles testent si la structure prévue peut tenir avant que les cours soient placés. Si la planification montre déjà un clash, corrigez la structure plutôt que de demander au solveur de le redécouvrir.
Valider comme un contrôle d’accès, dans l’ordre
Chaque passe ouvre la suivante ; l’optimisation vient en dernier.
- Exécuter l’analyse statique sur les données de l’emploi du temps.
- Corriger à la source les valeurs manquantes, les doublons et les cours non dotés.
- Exécuter l’analyse dynamique par rapport aux contraintes actives.
- Résoudre chaque problème critique ; mettre le reste de côté avec une note.
- Revérifier les sorties structurelles (block build, clash table) si les contraintes ont changé.
- Ne lancer l’optimisation que lorsque les problèmes restants sont compris et acceptés.
Comment faire dans Smootables : des erreurs typées avant et après la résolution
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
La même répartition apparaît dans Smootables à deux endroits. Avant la génération, le plan de période est vérifié pour les problèmes de données : le bouton Voir les erreurs ouvre le panneau Erreurs de validation, où les constats sont typés (Enseignant manquant, Salle manquante, Heures d’enseignant dépassées, Pas assez de salles) et chacun renvoie à sa correction avec Voir le placement, Voir l’enseignant ou Aller aux salles.
Le côté contraintes est expliqué quand une résolution échoue : le rapport nomme la cause du conflit, par exemple un enseignant avec trop de cours pour les créneaux disponibles ou un parc de salles trop petit, et associe chaque cause à une action suggérée, comme réduire la charge d’un enseignant, changer de salles ou ajouter des créneaux horaires. Lisez-le comme une sortie d’analyse dynamique : il vous dit quelle structure changer.
Ce qu’un résultat de validation utile nomme
Un constat exploitable nomme quatre choses : s’il s’agit d’une erreur de données ou d’un conflit de contraintes, quel enseignant, quelle classe, quelle salle ou quel cours est concerné, s’il bloque la génération ou peut attendre, et quoi revérifier après la correction.
Les constats qui échouent à ce test vont sur une liste d’attente, pas dans le modèle. Les constats qui le passent trouvent leur chemin d’eux-mêmes : les erreurs de données vers les responsables de la préparation des données, les conflits de contraintes vers la taxonomie des contraintes dures.
Questions des planificateurs sur la validation
Pourquoi la génération a-t-elle échoué après une validation réussie ?
La validation rend la faisabilité plus probable, jamais certaine. Certains conflits n’apparaissent que lorsque le placement combine les contraintes d’une manière qu’aucun pré-contrôle n’énumère. Traitez le rapport d’échec comme la passe de validation suivante.
Que sont les block builds, combing charts et clash tables ?
Des routines de faisabilité antérieures au placement, héritées de la planification. Elles testent si la structure prévue peut tenir avant qu’aucun cours individuel ne soit placé, ce qui est la forme structurelle de la validation.
Qui corrige ce que la validation trouve ?
Cela se répartit par étape. Les constats statiques sont des corrections de données pour le responsable des enregistrements. Les constats dynamiques sont des décisions de planification : un conflit de contraintes signifie généralement qu’une structure ou un engagement doit changer.