Attention : à partir du 1er janvier 2026, la facturation électronique via Peppol sera obligatoire en Belgique.
Attention : à partir du 1er janvier 2026, la facturation électronique via Peppol sera obligatoire en Belgique.
Plus de contrôle et moins de travail. Aussi dans votre secteur.
Traitement des factures rapide et sécurisé pour chaque entreprise.
Traitement des factures rapide et sécurisé pour chaque entreprise
Quelle est la manière la plus simple de rester informé sur ce qui se passe en matière d’ingénierie chez Payt ? Selon nous, les blogs techniques offrent une excellente opportunité pour communiquer cela avec vous. Je m’appelle Ivan Malykh et je suis développeur chez Payt. Pour vous donner un aperçu de notre logiciel, nous essayons d’écrire un blog d’ingénierie chaque mois. Je vous offre un aperçu chez Payt.
Lorsque j’ai commencé cet article, j’ai écrit une introduction pour l’un des outils utilisés par notre équipe frontend – Create React App. L’objectif était de montrer comment cet outil nous avait fait gagner beaucoup de temps et d’efforts dans le choix, l’installation et la configuration des différents packages tiers.
En cours de route, j’ai conclu que le premier article d’ingénierie logicielle de Payt, au lieu de plonger dans les détails, pourrait être un peu plus général. J’ai donc choisi de modifier légèrement l’objectif de cet article. Aujourd’hui, nous allons parler de différentes mesures dans notre flux de travail qui augmentent la productivité de l’équipe d’ingénierie et nous permettent de nous concentrer pleinement sur le développement de nouvelles fonctionnalités.
Mais d’abord, un peu de contexte sur notre stack logiciel.
Payt offre le logiciel le plus complet en matière de gestion des créances. Ce logiciel se compose de plusieurs applications web. Principalement, il s’agit de l’application de gestion des créances et de l’application portail des créances. Ces deux applications sont “alimentées” par les données d’une seule et même application backend.
L’application backend de Payt se compose, au moment de l’écriture, entre autres, des technologies suivantes :
Les applications frontend de Payt utilisent entre autres les technologies suivantes :
Les backends et les frontends communiquent entre eux via des API REST et GraphQL et sont hébergés sur l’infrastructure Amazon AWS.
Payt existe depuis un peu plus de huit ans. Au cours de ces années, le système a grandi et s’est considérablement étendu avec différents processus, fonctionnalités et la logique métier qui les accompagne. Maintenir une telle quantité de logique n’est pas trivial, mais certainement pas impossible.
Cela peut sembler évident, mais de nombreuses entreprises n’utilisent aucune forme de tests dans leur logiciel.
Le développement de nouvelles fonctionnalités chez Payt est toujours accompagné de l’exécution de tests. Ces tests peuvent être effectués de différentes manières. Chez Payt, nous avons choisi que nos tests soient écrits et exécutés par les développeurs. Le développement piloté par les tests, ou Test-Driven Development. Lors du développement d’une fonctionnalité, le développeur doit écrire les tests unitaires correspondants. Ces tests unitaires font partie du code. Lorsqu’un autre développeur travaille sur une nouvelle fonctionnalité et casse accidentellement la fonctionnalité existante, la suite de tests en avertit.
Git est un outil de gestion de versions. La fonctionnalité la plus utilisée de Git chez Payt est la “branche”. Une branche est une dérivation du code produit existant pour le développement d’une nouvelle fonctionnalité en isolement du code de production fonctionnel. Lorsque la fonctionnalité est terminée et que les tests sont écrits, le développeur peut soumettre son travail pour révision. Github – une plateforme de collaboration de développement via Git – offre la possibilité de créer des Pull Requests. Une Pull Request est la différence entre la branche principale et la branche de la nouvelle fonctionnalité (“branche de fonctionnalité”). Une exigence pour fusionner une Pull Request avec la branche principale est que les vérifications automatisées réussissent et qu’un ou deux collègues approuvent le code.
Comme je l’ai mentionné ci-dessus, les tests font partie du code. Lors du développement d’une fonctionnalité, un développeur peut exécuter des tests pour s’assurer que le code fonctionne. Notre suite de tests se compose, au moment de l’écriture, de 11 051 tests. Certains d’entre eux testent l’intégration entre les différentes parties et sont donc lents. Ce serait une perte de temps considérable si nous devions exécuter les onze mille tests avant de développer une fonctionnalité.
C’est pourquoi nous avons un système externe qui garantit que chaque commit Git sur la branche principale est entièrement testé. Un tel système (Intégration Continue ou CI) garantit également que les branches de fonctionnalités sont testées avant d’être examinées par d’autres développeurs.
En plus des tests unitaires, d’acceptation et d’intégration, il existe également d’autres vérifications qui garantissent la qualité du code. Quelques-unes d’entre elles sont :
Nous visons 100% et, au moment de l’écriture, nous sommes en moyenne légèrement au-dessus de 90%.
La vérification du style de code garantit que la manière dont le code est écrit est cohérente. Un style de code clair et cohérent facilite la familiarisation des nouveaux membres de l’équipe avec le code. Mais les membres existants de l’équipe peuvent également plonger plus rapidement dans une partie inconnue de l’application.
Les backends et les frontends chez Payt sont des bases de code indépendantes, chacune avec son propre dépôt Git. L’interface utilisateur frontend dépend des données fournies par l’API du backend. Le frontend attend également une certaine structure de données. Cette vérification garantit que le développeur est informé des changements “ruptures” dans l’API.
Lorsque l’une des vérifications ne répond pas aux exigences de qualité, le développeur concerné doit corriger les erreurs ou les lacunes. Son travail ne peut pas être déployé sur la branche principale avant cela.
Les développeurs ne seraient pas des développeurs s’ils n’automatisaient pas tout leur travail. Ainsi, le déploiement des fonctionnalités développées chez Payt est également automatisé. Chaque nouvelle fonctionnalité – testée et approuvée – est entièrement déployée automatiquement sur nos serveurs.
Malgré la quantité de flux de travail automatisés, l’équipe d’ingénierie de Payt a encore de nombreux défis. Par exemple, nous devons passer moins de temps sur la configuration, l’administration et d’autres tâches répétitives et automatisables. Et consacrer plus de temps au développement de nouvelles fonctionnalités et à l’extension des fonctionnalités existantes de nos applications.
Par exemple, nous travaillons actuellement à l’automatisation de la construction des serveurs sur lesquels les applications fonctionnent. L’intention est que notre infrastructure soit codifiée. Cela nous donnera bientôt un modèle unique du logiciel requis pour exécuter nos applications. Cela accélère le déploiement de nouvelles instances de serveur et assure la cohérence entre les différentes machines.
