L'Administration fédérale des douanes (AFD) et l'OFIT sont parvenus à mettre au point l'application Document d'accompagnement électronique en seulement six mois. Les premiers documents d'accompagnement électroniques relatifs aux cargaisons des expéditions sont déjà utilisés à l'Administration des douanes, ces documents ne devant ainsi plus être présentés sous forme papier à la frontière. L’application est la première qui a été développée par l'OFIT à l'aide de microservices dans le cadre du nouveau mode de travail DevOps.
Document d'accompagnement électronique: coup d'envoi pour DevOps à l'OFIT
Jusqu'ici, les chauffeurs devaient présenter à la frontière les documents requis sous forme papier pour l'importation, l'exportation ou le transit de leur cargaison. Mais, depuis début janvier, la mise en place réussie de l'application Document d'accompagnement électronique a rendu cette procédure inutile. Dès à présent, les premiers clients pilotes transmettent leurs documents par voie électronique à l'Administration des douanes avant même que leur cargaison n'ait quitté l'entrepôt. L'application Document d'accompagnement électronique constitue un premier résultat tangible du programme de transformation DaziT, prévoyant une numérisation intégrale des processus de l'Administration fédérale des douanes (AFD) pour 2026 (plus d'informations à ce sujet à l'adresse www.dazit.admin.ch).
DevOps: un aperçu des principes fondamentaux
Le concept de DevOps décrit une approche dans le secteur de l'informatique, dans laquelle les deux domaines que sont le développement et le domaine opérationnel (l'exploitation) coopèrent plus étroitement. Dans le cas de DevOps, il s'agit principalement d'une manière de penser et de travailler: les cinq principes fondamentaux sur lesquels DevOps repose sont résumés dans l'acronyme CALMS:
Culture: La coopération transversale entre les développeurs et l'exploitation constitue un des principes fondamentaux de DevOps. Mais elle suppose l'existence d'une culture de la coopération et d'entreprise marquée par la confiance mutuelle, promouvant l'envie d'apprendre ainsi que les échanges permanents.
Automatisation: L'automatisation des tests et du déploiement constitue un autre élément. Cela signifie par exemple que des développeurs ont codé des cas de tests, qui fonctionnent ensuite automatiquement en continu. Un code écrit récemment est ainsi testé automatiquement à une période plus précoce et, grâce à un déploiement automatique, peut être intégré au système de production en appuyant sur un bouton.
Lean: Le concept de lean implique que l'on se concentre sur l'essentiel, que l'on puisse livrer rapidement au client les premières fonctionnalités et que celles-ci soient améliorées en permanence au moyen de courtes itérations. Pour DevOps, l'amélioration de processus en continu revêt une grande importance. Les rétrospectives, pour reprendre leur appellation, fournissent une analyse à l'équipe DevOps et permettent à celle-ci d'observer ce qui s'est bien passé et ce qui peut encore être amélioré.
Measurement: L'existence de critères d'évaluation unifiés ainsi que l'évaluation permanente des performances de l'équipe et de la qualité des codes sont de la plus haute importance. Combien de temps sépare le développement du déploiement? Les fonctionnalités désirées par les clients sont-elles disponibles dans la qualité définie? Avec quelle fréquence les erreurs récurrentes dans le code interviennent-elles? Ici encore, beaucoup de processus sont automatisés grâce à l'existence de nombreux outils. L'OFIT met par exemple en place une sorte de feu de signalisation, directement relié au serveur. Lorsqu'un test automatisé est en cours sur un code récemment programmé, le feu indique en temps réel si le test a réussi ou non.
Sharing: Le partage du savoir, de la réussite et de la responsabilité constitue un autre pilier de DevOps, car ce mode de travail permet le rapprochement de différents domaines informatiques qui avaient jusqu'ici travaillé de manière très différente.
Accélérer la mise en place de nouvelles formes de travail Mise en service de l'application
«Ce que je trouve impressionnant dans le projet Document d'accompagnement électronique, c'est la rapidité de sa mise en œuvre: six mois seulement séparent le lancement du projet de sa mise en service, qui ont vu l'extension et l'adaptation de la plate-forme de nuage aux documents d'accompagnement électroniques ainsi que la phase de réalisation», rappelle Carsten Plum, responsable du programme Alignment & Coaching au sein de la division Mandats complexes, nouvellement instituée à l'OFIT. «Si cela a fonctionné, c'est parce que nous avons résolument misé sur les nouvelles formes de travail. Pour la première fois à l'OFIT, les personnes participant au projet ont travaillé selon l'approche DevOps.»
Un rapprochement entre le développement et l'exploitation
DevOps est un mot-valise, construit à partir des concepts développement (développement de logiciels) et opérations informatiques (exploitation informatique), avec pour idée maîtresse que des mesures incitatives, des processus et des outils communs doivent contribuer à une collaboration plus efficace entre les développeurs et les spécialistes de l'exploitation. L'objectif poursuivi est ainsi, grâce à un rapprochement plus étroit entre ces deux domaines, de pouvoir accélérer le développement et les tests sur les logiciels ainsi que leur mise à la disposition des clients (vous trouverez de plus amples informations sur DevOps dans l'encadré).
Cet étroit rapprochement doit également être compris en termes métaphoriques. Pour ce projet, l'OFIT a mis à disposition un local supplémentaire dans le bâtiment Titanic II, dans lequel se retrouve l'équipe DevOps, qui travaille en mode scrum. Cette équipe réunit un responsable d'application, un scrum master, des spécialistes de l'exploitation, des ingénieurs cloud, des responsables des tests, des développeurs, des architectes de solutions et d'autres spécialistes métier. Cette équipe planifie et évalue les sprints qui durent deux semaines, mais pas seulement: le local commun est également utilisé comme une sorte de laboratoire, devant permettre de faire l'apprentissage de nouvelles formes de coopération.
Une technologie de nuage moderne comme support
L'équipe DevOps utilise comme support une plate-forme basée sur une «Cloud Foundry» installée sur le nuage Atlantica de l'OFIT (Plate-forme en tant que service, PaaS), sur laquelle l'application Document d'accompagnement électronique est développée et exploitée. Comme le dit le responsable d'application Guido von Matt: «Les environnements de développement, de réception, de tests et de production n'existent plus que virtuellement. Ceci permet un déploiement automatisé de codes. Sur cette plate-forme, nous sommes en mesure de déployer des logiciels directement d'un environnement à un autre.»
Un développement au moyen de microservices
Les services dits partagés font aussi partie de la plate-forme. Il peut s'agir, à titre d'exemple, de banques de données. «Jusqu'ici, nous devions attendre au moins une semaine avant qu'une banque de données commandée ne soit disponible. Avec les services partagés, cela ne prend plus que deux minutes», comme le rappelle Guido von Matt.
Pour l'OFIT, la mise en place de la plate-forme et de ces services partagés constitue une nouveauté et représente l'un des défis dans le cadre de ce projet. Le nouveau mode de collaboration rendu nécessaire par le travail avec de nouveaux outils constitue lui aussi un défi, comme le montre l'exemple des essais. Le développeur Java Oliver Santschi explique: «Les tests ne se font plus après la finalisation complète de l'application, comme pour les projets suivant un modèle de processus linéaire. Non, aujourd'hui, c'est dès le premier sprint que nous testons de manière automatisée les fonctionnalités développées.» Pour DevOps, cela occasionne, en comparaison des projets linéaires, un déplacement dans le temps de certaines tâches vers une période plus précoce, donc vers des phases antérieures du projet. Certaines étapes de travail se déplacent de la droite vers la gauche sur l'axe temporel; ce phénomène est également dénommé «shift left» (décalage vers la gauche).
Un développement au moyen de microservices
Le développement de l'application reposant sur une architecture de microservices est étroitement lié à la philosophie DevOps. Un microservice est un module de logiciel qui remplit une fonction bien déterminée. «L'OFIT a développé pour la première fois des microservices et a réussi à les utiliser dans le cadre de l'application Document d'accompagnement électronique», indique Alexandre Proca, responsable de programme. Un microservice a par exemple pour tâche de télécharger des documents électroniques dans l'application, tandis qu'un autre n'aura pour fonction que de représenter l'interface utilisateur de l'application. L'application Document d'accompagnement électronique est faite de différents microservices de ce type, installés de sorte à pouvoir être combinés comme des casiers, quasiment de n'importe quelle manière. Les microservices sont ensuite placés dans des conteneurs permettant de mieux exploiter les performances du système d'exploitation, de simplifier le processus de déploiement et de réduire les dépendances.
L'avantage est le suivant: lorsqu'un changement intervient dans un microservice, il n'est pas nécessaire de modifier toute l'application, mais il suffit de modifier le module correspondant. C'est beaucoup plus rapide de procéder à une telle modification sur un microservice que sur un logiciel complexe couvrant tout un ensemble de fonctions. Par exemple, si l'Administration des douanes souhaite procéder à une modification sur la fonction de téléchargement, seul le microservice concerné doit être adapté. Le déploiement automatique permet à ce microservice de s'intégrer très rapidement au système de production. D'une manière générale, ni la fenêtre de maintenance ni l'interruption du système ne sont nécessaires. Comme le dit Guido von Matt: «Dans l'application Document d'accompagnement électronique, nous avons déjà procédé à plusieurs déploiements d'un microservice sur une journée sans devoir interrompre le système.» Une autre répercussion positive est la flexibilité d'adaptation de la prestation: lorsqu'une plus grande puissance de traitement est nécessaire, cela n'oblige pas à commander un nouveau serveur. Chaque microservice peut être redimensionné séparément en quelques secondes et chacun de ces microservices est exploité et perfectionné par l'équipe qui l'a mis au point. Ces équipes sont composées de spécialistes issus de différents domaines techniques, qui sont responsables d'un microservice donné sur toute la durée de son cycle de vie, ce qui inclut aussi le moment où il est exploité dans le système de production.
La réussite de la mise en service
La mise en service réussie de l'application Document d'accompagnement électronique début janvier a bien montré le caractère opérationnel de DevOps et de la mise en place de microservices à l'OFIT. D'après Kuno Zimmermann, responsable d'application à l'AFD: «L'application fonctionne de manière très stable. Les améliorations ayant été opérées ont pu être intégrées pendant l'exploitation, sans même que les clients s'en rendent compte.» Les clients pilotes téléchargent tous les jours leurs documents et l'AFD espère pouvoir constater très bientôt un élargissement continu et régulier du cercle des utilisateurs. Toutefois, le document d'accompagnement électronique n'est pas encore complètement finalisé: mais grâce à des processus et des outils communs et au savoir partagé, l'équipe DevOps sera à l'avenir en mesure de mettre en service des applications fonctionnelles beaucoup plus rapidement qu'avec une application spécialisée développée et exploitée de manière classique.
L'architecture de microservices en bref
Les architectures monolithiques de logiciels intègrent différentes fonctionnalités au sein d'une seule application. Or, l'architecture de microservices répond, pour sa part, à une tout autre logique, puisqu'avec une telle architecture, une application est composée de plusieurs microservices. Il s'agit de petits modules de logiciels englobant chacun une seule fonctionnalité, travaillant de manière autonome et communiquant avec d'autres microservices via des interfaces indépendantes de la langue utilisée. L'architecture de microservices simplifie la maintenance et l'actualisation d'une application. Si un microservice est touché par un problème, ce dernier n'affecte pas l'ensemble de l'application. Un microservice isolé peut être adapté, testé et intégré au système de production sans qu'il soit nécessaire d'interrompre tout le système. La complexité limitée de chacun des microservices offre un autre avantage: elle permet à ces microservices de rester clairement lisibles et de pouvoir être plus aisément perfectionnés.
Texte: Daniel Wunderli
Abonnez-vous gratuitement à l'«Eisbrecher»
Tous les trois mois, recevez les dernières nouvelles sur des thèmes informatiques au sein de l'administration fédérale et des projets actuels de l'OFIT.