Français
English
Español
DeutschPourquoi une migration IPAM échoue rarement à cause de l’outil
Les migrations qui dérapent ont presque toujours le même scénario : on importe le fichier tel quel, on découvre 300 doublons et 80 sous-réseaux qui se chevauchent, l’équipe perd confiance dans le nouvel outil, et six mois plus tard le tableur est toujours là, à côté de l’IPAM.
Le problème n’est pas l’import. Le problème est qu’un tableur autorise ce qu’un IPAM refuse : une adresse dans deux lignes, un masque incohérent avec la plage, un VLAN écrit « VLAN 12 », « vlan12 » et « 12 » dans trois onglets. Ces approximations sont invisibles dans Excel et bloquantes à l’import, ce qui fait précisément la valeur d’un IPAM. Mais cela veut dire que le nettoyage n’est pas une étape préalable à la migration : il est la migration.
Si vous en êtes encore à évaluer l’opportunité de sortir du tableur plutôt que la méthode, l’article Pourquoi Excel n’est plus suffisant pour gérer les adresses IP traite cette question en amont.
Avant de migrer : trois décisions à prendre
Trois arbitrages conditionnent tout le reste. Les trancher avant d’ouvrir le premier CSV évite de refaire l’import trois fois.
Quel est le périmètre du premier lot ?
Migrer l’intégralité du plan d’adressage d’un coup est le réflexe le plus courant et le plus risqué. Un site pilote, ou une plage bien connue, permet de valider la hiérarchie cible avant de l’appliquer à tout le reste.
Qui arbitre les données douteuses ?
Il y aura des adresses dont personne ne sait si elles sont utilisées. Il faut une règle décidée à l’avance (par exemple « non identifiée après scan et 30 jours d’observation = libérée ») et une personne qui tranche.
À quelle date le tableur meurt-il ?
Tant que le fichier reste modifiable, il reste la source de vérité officieuse. Fixer une date de gel, la communiquer et la tenir est ce qui distingue une migration d’une double saisie permanente.
Les 6 étapes d’une migration maîtrisée
Geler et photographier l’existant
Passer le fichier en lecture seule, en archiver une copie datée, et annoncer que toute nouvelle demande passe par le canal cible. Sans gel, vous migrez une cible mouvante.
Nettoyer et normaliser
Traiter les doublons, chevauchements, masques incohérents et libellés non normalisés. C’est l’étape la plus longue, et celle qui détermine la qualité finale.
Définir la hiérarchie cible
Blocs, sous-réseaux, plages, organisations, sites, VRF : décider de la structure avant l’import, car la reprendre après coup coûte bien plus cher.
Importer par lots
Importer d’abord les conteneurs (organisations, sites, blocs), puis les sous-réseaux, les plages et les adresses. L’ordre compte : sous-réseaux et plages doivent être rattachés à leur parent. Dans teemIP, une adresse IP peut toutefois être créée sans sous-réseau associé, ce qui facilite la reprise progressive de données incomplètes.
Réconcilier avec le terrain
Confronter le référentiel importé à la réalité : découverte IP, zones DNS, baux DHCP, tables ARP. C’est là que l’on mesure l’écart réel entre le fichier et le réseau.
Verrouiller la gouvernance
Droits, workflows de demande, responsables par plage, audit. Sans cette étape, l’IPAM se dégrade en quelques mois et redevient un tableur avec une meilleure interface.
Nettoyer le fichier : les 6 anomalies qui bloquent l’import
Ces anomalies reviennent dans presque tous les plans d’adressage tenus sous tableur. Les traiter avant l’import évite le rejet en masse et les allers-retours.
| Anomalie | Comment la repérer | Décision à prendre |
|---|---|---|
| Adresse présente plusieurs fois | Tri sur la colonne IP, ou mise en forme conditionnelle « valeurs en double ». | Garder la ligne la plus récente ou la mieux documentée, archiver l’autre. |
| Sous-réseaux qui se chevauchent | Trier par adresse réseau et vérifier que la fin de chaque plage précède le début de la suivante. | Retracer l’historique de découpage avant de trancher : un chevauchement cache souvent une plage réellement utilisée. |
| Masque incohérent avec la plage | Recalculer l’adresse réseau et le broadcast à partir du masque déclaré. | Faire foi sur la configuration réelle de l’équipement, pas sur le fichier. |
| Libellés non normalisés | Filtre sur les colonnes VLAN, site, organisation : les variantes apparaissent immédiatement. | Choisir une convention de nommage et l’appliquer avant l’import, pas après. |
| Statut absent ou implicite | Cellules vides, couleurs, ou commentaires utilisés comme statut. | Convertir chaque code couleur en valeur explicite : réservée, allouée, libre, non identifiée. |
| Propriétaire non renseigné | Colonne responsable vide ou pointant vers une personne partie. | Rattacher à une équipe ou un service plutôt qu’à un individu. |
Importer : l’ordre qui évite les rejets
Un IPAM valide les dépendances structurantes. Dans teemIP, un sous-réseau doit être rattaché à un bloc et une plage à un sous-réseau ; une adresse IP peut en revanche être créée sans sous-réseau associé. Cette souplesse permet de reprendre des données progressivement tout en conservant une hiérarchie cohérente pour les objets qui en dépendent. L’ordre d’import reste néanmoins la voie la plus sûre :
- Organisations et sites : les conteneurs de plus haut niveau.
- Blocs IP, IPv4 et IPv6, avec leur rattachement organisationnel.
- Sous-réseaux, avec masque, passerelle et statut.
- Plages (DHCP, réservées, statiques) à l’intérieur des sous-réseaux.
- Adresses IP, avec statut, nom DNS et commentaire.
- Liens vers les CI, une fois la CMDB alimentée.
Chaque objet IP accepte aussi un demandeur — la personne à l’origine de la demande — et autant de contacts que nécessaire, personnes ou équipes. Ces liens se complètent au fil de la reprise : ils ne bloquent jamais le premier import.
Un point pratique : importer un lot restreint d’abord (cinquante lignes suffisent) pour valider le mapping des colonnes, les séparateurs et l’encodage. Les fichiers issus d’Excel en français posent deux classiques : le point-virgule comme séparateur et l’encodage Windows-1252 qui casse les accents. L’encodage se choisit à l’import dans teemIP (UTF-8, ISO-8859-1…), ce qui évite de reconvertir le fichier en amont ; mieux vaut de toute façon découvrir ces détails sur cinquante lignes que sur quatre mille.
Réconcilier avec le terrain
Le fichier décrit ce que l’équipe croit savoir. Le réseau décrit ce qui existe. L’écart entre les deux est souvent la découverte la plus utile du projet, et parfois la plus inconfortable.
Trois sources permettent de le mesurer sans instrumentation lourde : les zones DNS, qui révèlent les adresses réellement nommées ; les baux DHCP, qui montrent ce qui est actif ; et une découverte IP par balayage, qui remonte ce qui répond. Le croisement de ces trois sources avec le référentiel importé produit trois listes : ce qui concorde, ce qui existe mais n’était pas documenté, et ce qui était documenté mais ne répond plus.
La troisième liste est celle qui libère de la capacité d’adressage. C’est souvent l’argument qui justifie le projet auprès de la direction : dans un plan d’adressage tenu sous tableur depuis plusieurs années, une part significative des adresses marquées comme utilisées ne l’est plus.
Verrouiller pour ne pas revenir au tableur
Un IPAM correctement rempli mais librement modifiable se dégrade à la même vitesse qu’un fichier partagé. Ce qui tient dans la durée, ce sont les règles d’écriture, pas la qualité de l’import initial.
Quatre mécanismes suffisent à stabiliser la situation : des droits par périmètre plutôt qu’un accès en écriture généralisé, un canal unique de demande d’adresse qui laisse une trace, un responsable identifié par plage, et un audit périodique qui compare le référentiel au terrain. C’est exactement ce que le tableur ne peut pas offrir, et ce qui explique que la migration ne se juge pas au jour de l’import, mais six mois après.
Ce verrouillage prend tout son sens lorsque l’IPAM est relié à la CMDB : une adresse rattachée à un équipement, un service et un propriétaire devient auditable. Le sujet est développé dans IPAM, CMDB et NIS2, et la page IPAM & CMDB détaille l’articulation entre les deux référentiels.
Combien de temps ça prend vraiment
La durée dépend beaucoup moins du volume d’adresses que de l’état du fichier de départ et du nombre d’interlocuteurs à mobiliser pour arbitrer les données douteuses. Un plan de 2 000 adresses bien tenu se migre plus vite qu’un plan de 500 adresses documenté par cinq personnes sur trois onglets.
L’ordre de grandeur observé sur ce type de projet place l’installation et le paramétrage en quelques jours, le nettoyage et l’import entre deux et six semaines selon l’état des données, et la réconciliation terrain sur un à deux mois, cette dernière phase étant surtout une affaire de disponibilité des équipes, pas de technique.
Questions fréquentes sur la migration d’un plan d’adressage
Peut-on importer directement un fichier Excel dans teemIP ?
L’import se fait au format CSV, que tout tableur exporte. teemIP propose un import guidé avec mapping des colonnes vers les champs du modèle de données, choix de l’encodage (UTF-8, ISO-8859-1…) et prévisualisation avant validation. Le point de vigilance n’est pas le format mais la cohérence des données : un CSV propre s’importe sans difficulté, un CSV qui contient des chevauchements sera rejeté ligne par ligne.
Faut-il tout nettoyer avant d’importer, ou peut-on corriger après ?
Les anomalies structurantes (chevauchements de sous-réseaux, masques incohérents, hiérarchie d’organisations) doivent être traitées avant l’import, car elles conditionnent l’arborescence. Les informations descriptives (commentaires, propriétaires, noms DNS) peuvent être complétées après, au fil de la réconciliation. La règle simple : ce qui définit la structure se règle avant, ce qui la documente peut se compléter ensuite.
Que faire des adresses dont personne ne connaît l’usage ?
Les importer avec un statut explicite du type « non identifiée » plutôt que de les supprimer ou de les marquer libres. Elles entrent ensuite dans le cycle de réconciliation : découverte IP, DNS, DHCP. Celles qui ne répondent à aucune de ces sources après une période d’observation définie à l’avance peuvent être libérées, avec une trace de la décision.
Peut-on migrer par étapes ou faut-il tout basculer d’un coup ?
La migration par lots est nettement préférable : un site ou une plage pilote permet de valider la hiérarchie cible et le mapping avant de généraliser. La seule contrainte est de geler le périmètre déjà migré dans le tableur, sinon les deux référentiels divergent immédiatement et l’équipe perd confiance dans les deux.
Comment migrer depuis phpIPAM ou un autre IPAM plutôt que depuis Excel ?
La logique est la même, avec un avantage : les données sont déjà structurées et l’export CSV ou API est natif. Le travail porte alors sur la correspondance des modèles de données, notamment les notions d’organisation, de site et de VRF, qui ne se recoupent pas toujours. Le comparatif phpIPAM et teemIP détaille ces différences de périmètre.
Combien de temps faut-il prévoir pour une migration complète ?
De quelques semaines à quelques mois selon l’état des données de départ et le nombre d’équipes à mobiliser. Le volume d’adresses est rarement le facteur limitant : c’est la qualité du fichier initial et la disponibilité des personnes capables d’arbitrer les cas douteux qui déterminent la durée réelle.
Pour aller plus loin
Sources publiques utilisées
- teemIP : documentation officielle
- teemIP : solution autonome et téléchargements
- Projet teemIP sur GitHub
Un plan d’adressage Excel à reprendre ?
Décrivez-nous l’état de votre fichier : nous vous aidons à cadrer le nettoyage, l’ordre d’import et la trajectoire de migration.
Cadrer ma migration IPAM