KURTOGLU
SINAN

Contexte du projet

Le travail a débuté en 1998 avec l’objectif de développer une infrastructure d’information commune et fiable pour les municipalités d’Eskişehir. Le périmètre allait de l’examen des applications municipales existantes au rattachement des données administratives, de l’information géographique, des données de terrain et de l’infrastructure nécessaire pour les soutenir.

À l’époque, les opérations municipales reposaient largement sur des applications distinctes basées sur COBOL, fournies par SAMPAŞ. Ces applications soutenaient leurs fonctions respectives, mais leurs structures de données sous-jacentes posaient des difficultés lorsque les enregistrements devaient être partagés entre municipalités et services.

Une même personne pouvait avoir plusieurs numéros d’enregistrement, créés par différents services, municipalités ou opérations au fil des années. Les doublons d’enregistrements de citoyens et de contribuables rendaient difficile l’établissement de relations fiables entre personnes, biens immobiliers, impositions et opérations municipales.

Le travail a aussi eu lieu avant que le rapprochement et la vérification par identité nationale ne soient devenus une composante courante des systèmes d’information municipaux. Établir une identité cohérente à travers les enregistrements existants a donc exigé une analyse et un rapprochement considérables.

Le point de départ était la relation entre identité, enregistrements, intégrité des données et partage de l’information. Cette relation est devenue le fondement du système d’information urbain plus large.

1. Évaluation des systèmes et des données existants

La première étape a consisté à examiner les applications municipales existantes, leurs structures de données et la manière dont les services les utilisaient.

Avant d’introduire un logiciel de remplacement, nous devions comprendre l’état des données existantes et repérer où les systèmes créaient des incohérences.

Les principaux problèmes comprenaient :

• Enregistrements multiples pour une même personne.
• Enregistrements distincts de citoyens et de contribuables tenus par différentes municipalités.
• Jeux de données propres à chaque service, organisés autour d’exigences opérationnelles individuelles.
• Enregistrements historiques stockés dans des formats incohérents.
• Relations peu fiables entre les personnes et les enregistrements de biens immobiliers.
• Partage d’information limité entre institutions.
• Absence de liens directs entre les éléments physiques de la ville et les enregistrements administratifs.
• Absence d’un inventaire à jour à l’échelle de la ville pouvant être confronté aux conditions du terrain.

L’évaluation a établi que des données fiables étaient un préalable au système plus large. Les enregistrements existants devaient d’abord être examinés, rapprochés et rendus aptes à un usage partagé.

2. Un registre commun des citoyens

Un élément central de l’approche consistait à identifier chaque personne par un enregistrement commun chaque fois que possible, plutôt que de créer un nouvel enregistrement indépendant pour chaque service municipal.

La relation visée était :

Personne → Enregistrement commun → Opérations municipales

Cela exigeait plus que l’attribution d’un numéro commun. Une même personne pouvait apparaître sous différentes orthographes de nom, adresses, informations incomplètes, formats d’enregistrement historiques ou enregistrements de service.

Le travail comprenait donc :

• Examen des enregistrements existants.
• Identification des doublons potentiels.
• Rapprochement des enregistrements liés entre systèmes.
• Préservation de l’intégrité des opérations associées.
• Élaboration d’un modèle de données commun.

Cette approche du registre commun a fourni une base pour relier les enregistrements entre services municipaux et est devenue un élément essentiel du système d’information urbain en développement.

3. Définition des exigences techniques

La mise en œuvre de l’approche du registre commun exigeait des changements coordonnés dans l’infrastructure de soutien.

Les exigences couvraient la capacité des serveurs, le stockage, la sauvegarde, les systèmes clients, l’infrastructure réseau, la communication entre institutions, la migration de données, l’organisation des utilisateurs et le personnel technique.

Des évaluations du matériel, de l’infrastructure réseau, du personnel et de la capacité technique requis ont été préparées et soumises à la direction.

À mesure que ces exigences se précisaient, le travail est devenu un projet d’infrastructure d’information municipale comportant plusieurs couches techniques et opérationnelles interdépendantes.

4. Enquêtes de terrain à l’échelle de la ville et inventaire des résidents et des biens immobiliers

Les seuls enregistrements informatiques existants ne pouvaient pas donner une image suffisamment fiable de la ville. Ils devaient être vérifiés par rapport aux bâtiments, aux lots, aux adresses et à l’occupation ou à l’usage réels.

Une enquête de terrain à l’échelle de la ville a été planifiée pour recueillir ces informations directement.

En m’inspirant des formulaires optiques utilisés à l’époque dans l’enseignement supérieur et les examens centralisés, j’ai proposé une approche par formulaires optiques pour soutenir la numérisation efficace de grands volumes de données d’enquête.

Après les approbations administratives et les décisions des conseils municipaux nécessaires, les formulaires ont été préparés et imprimés dans l’imprimerie de l’Anadolu University.

Les équipes de terrain ont recueilli les informations par une enquête de type recensement, en relevant :

• Bâtiments.
• Lots au sein des bâtiments.
• Adresses.
• Résidents et modes d’usage.

L’enquête s’est étendue à un important inventaire des résidents et des biens immobiliers à l’échelle de la ville. Elle a fourni une source d’information issue du terrain par rapport à laquelle les enregistrements municipaux existants pouvaient être évalués et mis à jour.

5. Volumes de données croissants et infrastructure de serveurs

À mesure que l’inventaire de terrain s’étendait, le volume de données a augmenté rapidement.

Les systèmes devaient aussi permettre la conservation des enregistrements historiques, l’ajout des informations nouvellement recueillies, l’accès partagé entre municipalités et l’introduction d’autres applications municipales.

Ces exigences cumulées ont exercé une pression croissante sur la capacité des serveurs et du stockage. De nouveaux systèmes de serveurs ont été installés et configurés pour absorber la charge croissante.

L’exigence dépassait la capacité de traitement. Les municipalités et les institutions situées sur des sites physiques distincts avaient besoin d’un accès fiable et à haut débit aux ressources d’information partagées.

L’architecture s’est par conséquent développée autour d’un enchaînement connecté :

Collecte de données de terrain → Ressources de données partagées → Infrastructure de serveurs → Connectivité inter-institutions

Soutenir des systèmes répartis sur des sites distincts rendait la connectivité fibre à haut débit de plus en plus nécessaire.

À l’époque, nous ne décrivions pas l’architecture en développement avec des termes tels que clusters étendus, extension de SAN ou infrastructure distribuée de serveurs et de stockage. Le travail allait cependant déjà dans cette direction : étendre les ressources de serveurs et de données sur des sites physiques distincts et les relier par un backbone fibre commun à haut débit.

L’exigence pratique était claire : des systèmes situés sur des sites différents devaient fonctionner ensemble, avec un accès fiable à des ressources de données communes.

6. Conservation et migration des données héritées

La conservation des données accumulées au fil des années d’exploitation municipale était une exigence centrale de la transition.

Les applications SAMPAŞ et COBOL existantes contenaient des enregistrements qui devaient rester disponibles et utilisables lorsque la municipalité est passée aux solutions fournies par İztek A.Ş.

Le travail de migration comprenait :

• Examen des structures de données existantes.
• Comparaison des modèles de données hérité et de remplacement.
• Nettoyage des enregistrements.
• Examen des doublons.
• Réévaluation des relations entre les personnes et les enregistrements.
• Transformation des données dans les formats requis.
• Migration des données.
• Vérification de l’intégrité des enregistrements transférés.

L’objectif était de produire des données pouvant être rapprochées, mises en relation et utilisées dans les nouvelles applications municipales tout en conservant leur valeur historique.

7. Données partagées et applications d’entreprise

L’environnement de remplacement a introduit des bases de données DB2 et des applications d’entreprise basées sur Java.

Cela soutenait l’usage prévu de ressources de données sous-jacentes communes entre les services municipaux.

Le modèle de travail était :

Données partagées → Applications d’entreprise → Services municipaux → Prestations municipales

L’information est de plus en plus devenue une ressource institutionnelle partagée, avec des relations pouvant soutenir plusieurs processus municipaux.

8. Planification de l’infrastructure fibre pendant les travaux de l’ESTRAM

Début 2002, les routes le long des tracés de l’ESTRAM avaient été fermées et d’importants travaux de génie civil étaient en cours.

À ce stade, les enquêtes de terrain s’étaient intensifiées, les volumes de données avaient augmenté, de nouveaux systèmes de serveurs avaient été installés et le besoin de communications à haut débit entre institutions était devenu évident.

Les fouilles en cours offraient l’occasion de préparer des tracés de fibre alors que les routes étaient déjà ouvertes. Cela soutiendrait les futurs besoins de communication sans recourir à une nouvelle campagne de fouilles le long des mêmes tracés.

Les besoins du système d’information urbain et des communications municipales ont donc été pris en compte pendant les travaux de génie civil.

Les préparatifs comprenaient :

• Fourreaux pour câbles de fibre.
• Traversées de tracé.
• Chambres de tirage souterraines.
• Points de raccordement.
• Armoires de terrain hors sol à des emplacements choisis.

Ces travaux ont établi des tracés physiques pouvant soutenir le réseau en développement et permettre une extension ultérieure.

9. Le backbone fibre inter-municipal

Les tracés préparés ont permis de relier par des liaisons fibre des municipalités et des institutions situées sur des sites différents.

Mon travail direct couvrait à la fois le backbone et l’infrastructure locale nécessaire pour y connecter les serveurs et les utilisateurs :

• Installation de câbles de fibre.
• Soudure par fusion.
• Terminaison de la fibre.
• Tests de liaison.
• Convertisseurs de média.
• Commutateurs et hubs Nortel.
• Distribution du réseau local basée sur NetWare.
• Câblage réseau en cuivre.
• Chemins de câbles.
• Réseaux internes des bâtiments.
• Raccordements des serveurs.
• Raccordements des clients.

Cette infrastructure fournissait les liaisons de communication dont les institutions géographiquement distinctes avaient besoin pour accéder aux systèmes d’information partagés.

Le backbone fibre reliait les couches serveur, données, applications et utilisateurs du système d’information urbain en développement.

10. Infrastructure fibre pour les communications et la signalisation de l’ESTRAM

L’ESTRAM avait aussi besoin d’une connectivité fibre pour ses systèmes de communication d’exploitation et de signalisation.

Les tracés physiques et les fourreaux préparés pendant les travaux de génie civil pouvaient répondre à cette exigence. Des câbles de fibre distincts ont été installés pour l’ESTRAM, et les fibres concernées ont été placées sous l’usage et le contrôle propres de l’ESTRAM.

Le corridor physique commun soutenait donc deux exigences distinctes :

• Communications de données municipales pour le système d’information urbain.
• Communications d’exploitation et signalisation de l’ESTRAM.

Les systèmes bénéficiaient de la même infrastructure de génie civil, tandis que la responsabilité de l’usage et de la gestion de leurs fibres restait séparée.

Cela faisait partie d’une approche coordonnée de planification de l’infrastructure urbaine pour plusieurs systèmes opérationnels.

11. Système d’information de gestion

À mesure que l’infrastructure de serveurs, de données et de communication se développait, le travail s’est étendu aux processus opérationnels des services municipaux.

Nous avons examiné les informations et les règles de gestion associées aux citoyens, aux contribuables, aux biens immobiliers, aux impositions, aux recouvrements, aux opérations, aux dates, aux taux et à la législation.

Une difficulté importante tenait au fait que les règles de gestion municipales évoluaient dans le temps. Les modifications de lois, de règlements et d’avis officiels pouvaient affecter les taux, les méthodes de calcul, les dates d’effet et le traitement de certaines périodes.

Les applications devaient donc tenir compte de la règle applicable à la date d’une opération.

Des milliers de cas possibles ont été examinés en relation avec :

• Plages de dates d’effet.
• Changements de taux.
• Changements législatifs.
• Types d’opérations.

Traduire ces exigences en comportement logiciel a constitué une part importante du travail sur le MIS.

12. Système d’information géographique

L’étape majeure suivante consistait à relier les informations administratives municipales à la ville physique.

Le travail GIS basé sur NetCad s’est concentré sur l’établissement de relations entre les objets cartographiés et les enregistrements municipaux correspondants.

La chaîne d’information visée était :

Ville → Îlot cadastral et parcelle → Bâtiment → Lot → Enregistrement → Citoyen ou contribuable → Opérations municipales

Un résultat pratique était la possibilité de sélectionner sur la carte un lot ou un objet géographique associé et d’accéder aux informations MIS correspondantes.

Cela établissait un lien direct entre l’information spatiale et l’administration municipale.

13. Intégration MIS/GIS

Le MIS et le GIS étaient traités comme des couches d’information complémentaires décrivant la même ville.

Le MIS contenait les personnes, les contribuables, les opérations, les impositions et les processus administratifs. Le GIS représentait les emplacements, les parcelles, les bâtiments, les lots et d’autres objets physiques.

Le travail d’intégration a établi des relations entre ces couches afin qu’un bien immobilier cartographié puisse mener aux enregistrements, aux personnes et aux opérations municipales concernés.

Cela permettait aux utilisateurs d’examiner la ville physique et ses informations administratives dans un environnement d’information connecté.

La relation en cours d’élaboration était :

Emplacement géographique → Parcelle → Bâtiment → Lot → Enregistrement → Citoyen ou contribuable → Opérations municipales

14. Travaux préliminaires d’intégration du registre foncier et du cadastre

À mesure que les relations MIS/GIS se développaient, les registres officiels de propriété et de cadastre sont devenus un autre domaine d’investigation.

Il fallait mettre en relation les informations municipales sur les personnes, les biens immobiliers, les parcelles, les bâtiments et les lots avec les enregistrements officiels correspondants.

Des discussions ont eu lieu avec les institutions concernées pour évaluer les possibilités d’intégration des données. Des discussions préliminaires ont aussi porté sur le partage d’informations dans le cadre des responsabilités institutionnelles applicables.

Cela est resté un travail préparatoire. Il a exploré comment le système d’information urbain pourrait se connecter aux informations détenues par d’autres institutions publiques.

15. Une approche intégrée des systèmes

Le périmètre exigeait que plusieurs couches techniques et opérationnelles fonctionnent ensemble :

• Infrastructure électrique et physique.
• Câblage et fibre optique.
• Équipements réseau.
• Serveurs, stockage et sauvegarde.
• Bases de données et applications d’entreprise.
• Systèmes hérités et migration de données.
• MIS et GIS.
• Données d’enquête de terrain.
• Législation et règles de gestion municipales.
• Flux de travail des utilisateurs.

Le projet s’est développé autour des relations entre ces couches :

Infrastructure physique → Communications → Serveurs et données → Applications d’entreprise → MIS/GIS → Prestations municipales

Les décisions d’installation, les structures de données, les exigences applicatives et les processus des services s’influençaient mutuellement. Les coordonner était une part centrale du travail.

16. Mon rôle et mes contributions directes

Mes responsabilités couvraient plusieurs disciplines et ont évolué au fil du projet.

Dans le domaine de l’analyse des systèmes et des données, mon travail comprenait :

• Évaluation des applications existantes et des problèmes de données.
• Élaboration de l’approche du registre commun.
• Définition des exigences techniques.
• Rapport sur les besoins en matériel et en personnel.
• Élaboration du modèle d’enquête de terrain et de la méthode des formulaires optiques.
• Soutien à l’inventaire à l’échelle de la ville.
• Examen des systèmes hérités.
• Nettoyage et rapprochement des enregistrements.
• Réalisation de la migration des données.

Dans le domaine de l’infrastructure et des communications, mon travail comprenait :

• Installation et configuration de systèmes de serveurs.
• Configuration des serveurs et des clients.
• Élaboration de schémas réseau.
• Planification des tracés de fibre.
• Travaux sur les fourreaux, les chambres de tirage et les armoires de terrain.
• Installation, soudure, terminaison et test de la fibre.
• Travail avec les équipements Nortel, les convertisseurs de média, les commutateurs et les hubs.
• Soutien à l’infrastructure NetWare.
• Installation du câblage en cuivre et des réseaux internes des bâtiments.

Dans le domaine des applications et de l’intégration, mon travail comprenait :

• Travail avec l’environnement de données DB2 et les applications d’entreprise basées sur Java.
• Soutien au développement du MIS.
• Travail avec le GIS et les applications NetCad.
• Établissement de relations entre les données MIS et GIS.
• Traduction de la législation et des règles de gestion municipales en exigences logicielles.
• Participation aux travaux préliminaires d’intégration du registre foncier et du cadastre.
• Test des systèmes et soutien à la mise en service sur le terrain.

Ce fut l’une des missions d’intégration de systèmes les plus étendues de ma carrière, réunissant matériel, réseaux, communications, données, applications d’entreprise et information géographique dans un même environnement municipal.

Évolution de 1998 à 2004

Le travail s’est développé à travers une série d’étapes connectées :

1. 1998 — Évaluation initiale : examen des applications municipales, des données héritées, des enregistrements en double et des problèmes d’intégrité des données.
2. Enregistrement commun et inventaire de terrain : élaboration de l’approche du registre commun et collecte des informations sur les bâtiments, les lots, les adresses, les résidents et l’usage au moyen de formulaires optiques.
3. Extension des données et des serveurs : installation de capacité de serveurs pour soutenir l’augmentation des volumes de données, la migration des données héritées et l’environnement applicatif DB2/Java.
4. 2002 — Travaux de génie civil de l’ESTRAM : préparation des fourreaux, des chambres de tirage, des traversées de tracé et des armoires de terrain pour l’infrastructure fibre.
5. Intégration des communications et des applications : développement du backbone inter-municipal, du MIS, du GIS basé sur NetCad et des relations entre données administratives et géographiques.
6. Planification d’intégration complémentaire : travaux préliminaires sur les liens avec les informations du registre foncier et du cadastre.
7. 2004 — Fin de ma période de projet : conclusion de mon implication dans cette phase du travail.

Des applications séparées à une infrastructure d’information urbaine connectée

L’environnement de départ se composait d’applications municipales distinctes, de jeux de données fragmentés, d’enregistrements en double, d’un partage d’information limité et de données administratives faiblement reliées à la ville physique.

Le travail a introduit une approche du registre commun, des données d’inventaire issues du terrain, des enregistrements nettoyés et migrés, une capacité de serveurs accrue, une connectivité fibre et des relations entre MIS et GIS.

Le résultat visé était un environnement d’information dans lequel emplacements, biens immobiliers, personnes et opérations municipales pouvaient être compris à travers leurs relations, soutenus par des données partagées et une infrastructure de communication.

Importance technique

L’importance du travail de 1998 à 2004 tient aux méthodes et à l’infrastructure développées pendant cette période.

À une époque où le rapprochement par identité nationale et les services numériques inter-institutions étaient moins établis, le travail a répondu à plusieurs exigences qui restent centrales pour les systèmes d’information urbains :

• Rapprochement des enregistrements de citoyens par une approche du registre commun.
• Production d’informations sur les résidents et les biens immobiliers issues du terrain.
• Conservation des enregistrements hérités pendant la migration.
• Mise en place de ressources de données institutionnelles partagées.
• Augmentation de la capacité des serveurs pour absorber des charges croissantes.
• Raccordement des municipalités et des institutions par la fibre.
• Planification des tracés physiques en tenant compte des besoins futurs de communication.
• Mise en relation des enregistrements administratifs municipaux avec les objets géographiques.
• Étude d’un partage d’information plus poussé entre institutions publiques.

Ces activités ont constitué une initiative précoce de système d’information urbain à Eskişehir, dans laquelle données, serveurs, communications, applications, information géographique et infrastructure de terrain ont été développés comme les parties d’un même système.

2004 — Fin de mon implication

Mon implication dans le projet a pris fin en 2004, après six ans de travail couvrant les données municipales, l’infrastructure physique, les communications, les applications d’entreprise et l’information géographique.

Cette expérience a constitué une base pratique pour travailler sur les données municipales, l’infrastructure physique de la ville, les systèmes d’entreprise et l’information géographique. Elle a aussi renforcé ma capacité à évaluer un système institutionnel complexe à travers les relations entre ses composants techniques et les services qu’il devait soutenir.