Estimation et calage des sous-modèles

La principale difficulté réside dans la construction des bases de données d’estimation ; c’est une tâche laborieuse et ingrate, peu recon- nue et très gourmande en temps de travail. Un second problème réside dans l’impossibilité d’implémenter des modèles trop sophistiqués dans URBANSIM. En fait, au départ, on a estimé les sous-modèles indé- pendamment les uns des autres, avec une démarche économétrique rigoureuse et autant de variables que possible, quitte à en modéliser de nouvelles pour satisfaire nos besoins. Ces estimations sont chronopha- ges, et au final quasiment impossibles à implémenter dans la structure pré-établie d’URBANSIM. De plus, on perd la vision globale du modèle intégré et les interactions existantes entre les différents modè- les. Une solution a alors consisté à passer à une méthode d’estimation plus systématique, en utilisant une base de variables commune à tous les sous-modèles, en nombre limité, dans le but d’aboutir à un modèle utilisable en prédiction et non plus un modèle explicatif. Parmi les variables exogènes testées, on a essayé de faire ressortir des variables transport (accessibilités locales et régionales en VP et en TC, temps d’accès au centre de Paris) mais la base de variables était incomplète en ce qui concerne les coûts de transport. Une troisième difficulté a concerné le modèle de choix de développement urbain. En 2005, nous avons estimé un modèle de transition conformément à la version d’URBANSIM 2. En 2007, la nouvelle version d’URBANSIM a modi- fié radicalement ce modèle en un modèle de choix de localisation de projet urbain. Nous avons choisi de conserver le premier modèle, quoique, dans la logique d’URBANSIM, le nouveau modèle est plus pertinent, car il permet de simuler des contraintes chiffrées de capacité pour les deux modèles de localisation et distingue le promoteur immo- bilier comme un nouvel agent économique. C’est en général ce modèle qui est le moins bien traité dans les modèles intégrés. Enfin, une quatrième difficulté a consisté à se prémunir des problèmes d’auto- corrélation spatiale (tests de Durbin et Watson, de Box-Pierce), d’endogénéité des variables, de colinéarité des variables et d’hétéros- cédasticité10 _{(tests de White, de Goldfeld et Quandt, de Breush et}

Pagan). La tâche de détection et de résolution de ces problèmes incombait au spécialiste en économétrie.

10. L’analyse des résidus en modélisation linéaire consiste à évaluer comment les résidus sont distribués en fonction des valeurs prédites de la variable dépendante. Si la dispersion des résidus n’est pas homogène, on parle d’hétéroscédasticité.

Le problème du calage repose quant à lui avant tout sur une ques- tion d’assemblage. En effet, les modules ont été estimés indépendam- ment les uns des autres. Il est ainsi possible de valoriser du point de vue de la recherche chaque estimation ; mais le but premier n’est pas ici de publier les résultats de chacun des sous-modèles. Il s’agit au contraire de réaliser un « calage global », tâche autrement plus difficile. En quoi consiste ce calage ? Dès juin 2003, lors de l’élaboration de la méthodo- logie du projet, nous avons eu l’intuition de l’importance de cette « phase de calage global ». Elle consiste, en pratique, en l’assemblage de tous les sous-modèles estimés et en l’exécution sur la période 1990- 1999 de l’ensemble dans une boucle de rétroaction annuelle (un an pour URBANSIM et trois ans pour le modèle de trafic), sachant que les sorties d’un sous-modèle une année peuvent être les entrées d’un autre sous-modèle la même année ou l’année suivante. L’objectif de ce calage global était alors de reconstituer la situation observée en 1999, c’est-à-dire la répartition géographique des populations et des emplois à un niveau infracommunal, le mode d’occupation du sol en trois postes agrégés et les prix moyen des logements au niveau communal.

Le deuxième aspect du calage global est l’interaction entre les diffé- rents modèles au sein d’URBANSIM. On s’est ici posé la question de savoir si cette interaction était déjà implémentée. On peut regretter que cet aspect pourtant fondamental soit très mal expliqué dans la documen- tation, voire pas du tout. C’est une approche empirique qui nous a permis de comprendre progressivement comment les sorties d’un modèle alimentent les entrées d’un autre et comment les variables de « gridcells » et les tables « households » et « jobs » sont mises à jour annuellement11_{. Formellement, le calage global consiste alors à résou-}

dre un problème d’optimisation : minimum [(observé – simulé)2_{]. On}

peut imaginer une procédure automatique de calage qui mettrait en œuvre une boucle de rétroaction avec un critère d’arrêt à partir du principe des moindres carrés ou à partir du maximum de vraisemblance. Concrètement, nous avons calé le modèle intégré au niveau dépar- temental (de même d’ailleurs que le modèle de demande de déplace- ments). Après analyse des premiers résultats, nous avons décidé de rajouter des constantes pour les indicatrices permettant de favoriser ou de défavoriser tel ou tel département. Par exemple, si nous observons

11. Il est également apparu en fin de projet qu’une compétence manquait à l’équipe : la maîtrise du langage Python. Autant les phases précédentes du projet demandaient des compéten- ces pluridisciplinaires (modélisation de trafic, économétrie, système d’information géographique, gestion de bases de données, connaissance du fonctionnement de la région Île-de-France), autant il s’avérait que cette phase de calage global dans la dernière version OPUS/URBANSIM requérait essentiellement des compétences en programmation en langage Python.

une surestimation de 4 % du nombre de ménages qui se localisent à Paris, nous ajoutons un coefficient négatif pour l’indicateur Paris, ce qui réduit l’attractivité de Paris. En d’autres termes, l’utilité calculée par le modèle de localisation des ménages était moindre. Nous avons procédé de cette manière pour les quatre sous-modèles d’URBAN- SIM. Avec cette méthode empirique, nous avons pu améliorer les résultats. Il faut savoir qu’une simulation de SIMAURIF sur la période 1990-1999 dure environ quatre heures sur un PC standard, et qu’un bon calage nécessite, selon nous, une centaine de simulations. Il était encore possible d’améliorer ces résultats mais pour des raisons de contrainte de délais, nous avons décidé de ne pas aller au-delà d’un certain niveau de précision.