Le département E&IT agit comme un « prestataire clé de services » pour l’ICANN. Étant donné que les systèmes ne correspondent pas tout à fait aux périmètres fonctionnels définis par l’organisation, l’E&IT est l’endroit où les effets du travail interfonctionnel deviennent facilement visibles. C’est pourquoi l’équipe E&IT met en place des processus intégrateurs et collaboratifs pour traiter les demandes de systèmes qui lui sont adressées et hiérarchiser son travail. Deux fois par an, les cadres de l’ICANN sont invités à évaluer leur demandes actuelles et futures de projets E&IT liés à leurs fonctions respectives. Les projets peuvent être relativement simples, comme l’optimisation d’un ordinateur, d’un réseau ou d’une infrastructure de stockage, ou bien plus complexes, comme la mise au point de systèmes logiciels codés sur mesure pour répondre à des objectifs spécifiques et l’optimisation de l’infrastructure qui accompagne ces systèmes. Ce processus comporte différentes tâches qui consistent à recueillir les besoins de chaque équipe, à aligner les projets proposés sur les stratégies de l’organisation, à comprendre les dépendances et les conséquences interfonctionnelles, à examiner les retours d’information de la communauté et à déterminer la priorité des demandes. Cette démarche aboutit à une liste hiérarchisée de demandes E&IT pour chaque fonction au sein de l’organisation ICANN.
Ces demandes de projets sont ensuite analysées à la lumière des fonds disponibles (sur la base des budgets vérifiés par la communauté et approuvés par le Conseil d’administration de l’ICANN) et de la capacité de l’équipe E&IT (en fonction des ressources humaines disponibles au sein de l’équipe E&IT et parmi les sous-traitants). Voilà les principaux critères utilisés pour déterminer combien de projets relevant de l’E&IT peuvent être réalisés chaque semestre (de janvier à juin et de juillet à décembre). Cela nous permet d’établir une coupure dans la liste hiérarchisée de demandes.
La liste finale de projets E&IT est ce que l’on appelle le « pipeline figé de livraison ». Chaque semestre, notre pipeline figé de livraison est tout d’abord vérifié et approuvé par les vice-présidents séniors de l’ICANN et ensuite par le PDG de l’ICANN afin de confirmer la liste de livrables prévus pour la période. Toute modification du plan, y compris l’ajout ou la suppression de projets, doit être approuvée par le PDG.
Pour assurer la coordination et l’organisation internes du pipeline figé de livraison, l’équipe E&IT organise ses activités autour de sept volets de travail. Si les six premiers volets ne se recoupent presque pas, ils convergent pourtant d’une manière ou d’une autre vers le septième et dernier volet (infrastructure IT de base). Les sept volets de travail sont :
- Participation de la communauté : travail de soutien à la participation de la communauté de l‘ICANN. Par exemple, les systèmes utilisés par le Programme de bourses, par les structures de la communauté de l’ICANN et par les programmes de voyage de l’ICANN.
- Collaboration avec la communauté : travail en lien avec les outils et les sites web utilisés par l’organisation ICANN, les organisations de soutien (SO) et les comités consultatifs (AC). L’initiative relative à la transparence des informations (ITI) se trouve dans cette catégorie.
- Parties contractantes : soutien au travail d’échange avec les opérateurs de registres et les bureaux d’enregistrement, dont fait partie le portail des services de nommage (NSp).
- Services techniques : travail lié aux nombreux systèmes utilisés par l’organisation ICANN et/ou par la communauté de l’ICANN pour veiller au respect des obligations contractuelles des parties contractantes. Des systèmes tels que le système de surveillance des conventions de service (SLAM), l’accès au fichier de zone et le CZDS font partie de cette catégorie.
- Services de l’Autorité chargée de la gestion de l’adressage sur Internet (IANA) : travail lié aux systèmes utilisés par la communauté et par l’équipe IANA pour assurer les fonctions IANA, y compris la gestion de la zone racine.
- Services pour le personnel : travail lié aux systèmes utilisés par l’organisation ICANN, dont font partie les fonctions de planification des ressources d'entreprise (ERP) comme les ressources humaines et les finances, ainsi que l’Intranet, la messagerie électronique, les systèmes téléphoniques, Slack pour la messagerie Internet, etc.
- Infrastructure IT de base : travail lié aux systèmes et aux services utilisés par toutes les parties prenantes ci-dessus. Zoom, les centres de traitement de données, l’informatique en nuage, la sécurité des informations et les serveurs racine gérés par l'ICANN (IMRS) font partie de ce groupe.
Tout en gardant à l’esprit ce processus de hiérarchisation, j’aimerais maintenant parler plus en détail du CZDS et répondre ainsi à l’intérêt manifesté par la communauté.
Il y a quelques années, le CZDS a été basculé à une autre plateforme combinant Java pour les demandes côté utilisateur (communauté de l’ICANN) et Salesforce pour les approbations back-end des parties contractantes (fonctionnalité consolidée avec le NSp). Ce travail a été achevé en janvier 2019. Il s’agit certes d’un bon début mais des efforts supplémentaires sont nécessaires pour que le CZDS soit conforme aux recommandations formulées en 2017 par le Comité consultatif sur la sécurité et la stabilité (SSAC) dans son rapport SAC097.
Le travail de l’E&IT sur le CZDS concerne le troisième (parties contractantes) et le quatrième (services techniques) volets de travail. Le schéma ci-dessous illustre le pipeline figé de livraison correspondant à ces volets de travail pour le semestre à venir (de janvier à juin 2021) sur la base des priorités identifiées et des ressources allouées. Il est accompagné d’une brève explication des projets.
Services techniques
- Le système de surveillance des conventions de service (SLAM) fait l’objet d’une importante mise à jour destinée à améliorer sa performance, sa sécurité et les indicateurs pour les registres. Le système SLAM constitue la dorsale des systèmes techniques de l’ICANN.
- Le projet de surveillance des bureaux d’enregistrement permettra de veiller au respect des conventions de service des bureaux d’enregistrement et donnera à l’ICANN la possibilité de surveiller les services fournis par les bureaux d’enregistrement en vertu de leurs contrats d'accréditation.
- Des améliorations apportées à l’interface de programmation d’application du système de surveillance (MoSAPI) incluront la possibilité de surveiller le protocole d'accès aux données d'enregistrement des noms de domaine (RDAP) et permettront à l’ICANN de fournir des informations RDAP détaillées aux parties contractantes lorsque que cette surveillance sera activée. Grâce à ces évolutions, les opérateurs de registres pourront disposer de nouveaux indicateurs pour assurer le suivi des SLA.
- L’interface de déclaration d'enregistrement (RRI) bénéficiera aussi d’améliorations qui permettront à l’équipe de l’ICANN en charge de la conformité contractuelle de mieux répondre à d’éventuelles notifications des agents d’entiercement de données (DEA) des bureaux d'enregistrement.
Parties contractantes
- Le travail sur le portail des services de nommage (NSp) se poursuit.
- Nous mettons au point des intégrations avec les systèmes des services techniques qui nous permettront d’arrêter l’utilisation d’une ancienne plateforme de conformité (Kayako), avec à la clé une réduction des coûts de licence, un gain d’efficacité pour l’équipe chargée de la conformité et une expérience utilisateur améliorée pour le signalement des non-conformités.
- Une nouvelle fonctionnalité pour les dossiers de conformité sera introduite dans le NSp pour permettre le signalement de multiples cas de non-conformité (groupés) grâce aux intégrations qui seront mises en place.
- Entre juin et juillet 2021, l’équipe espère commencer le travail sur la version 3.0 du CZDS afin d’appliquer la recommandation faite par le SSAC pour permettre le renouvellement automatique des demandes approuvées pour les fichiers de zone.
En somme, depuis l’approbation du SAC097 par le Conseil d'administration de l’ICANN en 2017, le travail lié au CZDS a été prioritaire. De nombreuses modifications ont été apportées au CZDS, qui n’ont pas été visibles pour les utilisateurs finaux car elles impliquent des changements au niveau de l’infrastructure sur laquelle il s’appuie. En outre, des consultations auprès de la communauté et des discussions au sein de l’organisation ICANN ont fini par accorder la priorité à d’autres projets. Quoi qu’il en soit, d’après le flux d’activités prévu pour le semestre prochain et compte tenu des priorités et des contraintes actuelles, le travail sur le CZDS reprendra à compter de la mi-2021.
L’équipe E&IT comprend toutefois le souhait de la communauté d'accélérer les délais des livrables liés aux projets CZDS et étudie la possibilité d’augmenter ses capacités de travail à court terme, dans les limites des ressources humaines et financières disponibles. Les spécialistes Java ont été recrutés assez facilement à court et à long terme, mais l’identification et le recrutement d’experts Salesforce pour le travail lié au NSp s’est révélée beaucoup plus difficile.
Je ferai un nouveau point de situation pour la communauté au début du prochain semestre de travail. En attendant, merci de votre compréhension et de votre patience.
