Générateur d’identifiants séquentiels à réinitialisation annuelle – Prise en charge de plusieurs préfixes

Dans cet article, Tamás, l’un de nos développeurs de la bibliothèque, revient sur les choix techniques qui ont présidé à la conception de l’application « Générateur d’identifiants séquentiels à réinitialisation annuelle – Prise en charge de plusieurs préfixes », disponible dans la bibliothèque.

Pourquoi l’ai-je conçue ainsi ?

J’ai conçu ce bloc logique pour résoudre un problème très concret : générer des identifiants de manière fiable, facile à réutiliser et rapide à déployer dans de nombreuses applications.Mon objectif était que l’identifiant lui-même contienne tout ce qui est nécessaire pour calculer le suivant. Chaque partie de l’identifiant a un rôle bien défini :* le préfixe indique à quelle séquence appartient l’identifiant* l’année sépare la séquence dans le temps* le nombre indique l’ordre au sein de cette année

Grâce à cette structure, je n’ai pas eu besoin d’introduire de logique de réinitialisation. Le dernier identifiant existant contient déjà toutes les informations nécessaires pour générer le suivant. Tant que le dernier identifiant est valide, le suivant peut toujours être calculé de manière prévisible.

J’ai intégré l’année directement dans l’identifiant, car elle sépare naturellement les enregistrements dans le temps. Cela permet également à la numérotation de redémarrer automatiquement chaque année, sans nécessiter de réinitialisation programmée ni de mise à jour manuelle.

Le préfixe sert de délimitation entre les différentes séquences. Cela permet d’utiliser plusieurs séquences de numérotation indépendantes au sein d’une même table. Changer de préfixe revient simplement à poursuivre une séquence différente.

J’ai ajouté une validation car l’approche dans son ensemble repose sur une structure d’identifiant cohérente. Si un identifiant existant ne respecte pas le format attendu, la poursuite de la séquence pourrait entraîner des résultats confus ou incohérents. Je préfère m’arrêter à temps, signaler le problème et éviter de générer des identifiants incorrects.

J’ai opté pour une recherche basée sur un connecteur afin que le bloc logique puisse fonctionner avec différentes tables sans modifier la logique de base. Une fois le connecteur configuré, il suffit de fournir l’identifiant de table (tableId) et le préfixe, et le même bloc logique peut être réutilisé à plusieurs endroits.

Pour moi, l’objectif n’était pas seulement de générer des identifiants, mais de créer un modèle réutilisable où le format de l’identifiant lui-même définit le fonctionnement de la séquence. C’est ce qui permet de garder la logique simple, prévisible et facile à réutiliser d’une application à l’autre.

Fonctionnement de ce bloc logique

Ce bloc logique génère des identifiants séquentiels qui sont réinitialisés chaque année selon la structure suivante :préfixe + année + numéro d’ordre

Exemple : TEST20240001 TEST20240002

Lorsque l’année change, la numérotation recommence automatiquement à 1 : TEST20250001

Plusieurs préfixes peuvent coexister dans une même table. Chaque préfixe dispose de sa propre séquence indépendante : ORD20240001 ORD20240002 INV20240001 INV20240002

Le bloc logique garantit : * un format d’identifiant cohérent * une réinitialisation annuelle automatique * une numérotation indépendante par préfixe * la détection précoce des identifiants historiques mal formés * la détection précoce des dépassements numériques

Pourquoi le connecteur fait-il partie de la conception ?

Avant de générer l’identifiant suivant, le bloc logique a besoin du dernier identifiant existant pour le préfixe donné. Le connecteur effectue une recherche filtrée : * filtrer les enregistrements dont l’identifiant commence par le préfixe * trier par ordre décroissant selon _sequenceNumber * renvoyer le dernier enregistrement

Le préfixe faisant partie du filtre, chaque préfixe dispose de son propre compteur incrémental, même au sein d’une même table. Cela permet de maintenir les séquences isolées et prévisibles.

Comment la structure est organisée

L’implémentation actuelle utilise trois déclencheurs. Cette structure est intentionnelle. Je souhaitais que le bloc logique soit facile à suivre de haut en bas, tout en conservant la logique principale séparée et réutilisable. Ainsi, au lieu de répartir la logique entre de nombreux déclencheurs modifiables, je l’ai organisée en trois étapes :1. CONFIGURATION UTILISATEUR : ÉTAPE D’ENTRÉE 2. Validation MAGIC + génération d’ID 3. CONFIGURATION UTILISATEUR : ÉTAPE DE SORTIE

Cela offre un bon équilibre entre facilité d’utilisation et contrôle.* Le premier déclencheur permet de définir les entrées.* Le deuxième déclencheur contient la logique interne qui, en règle générale, n’a pas besoin d’être modifiée pour que le bloc logique fonctionne.* Le troisième déclencheur permet de décider quoi faire du résultat généré.

Cela signifie que vous n’avez généralement pas besoin d’intervenir dans le déclencheur de logique principal. Il suffit de configurer les côtés entrée et sortie. C’était l’une des décisions clés de conception : rendre le bloc logique réutilisable en n’exposant que les parties qui doivent habituellement être modifiées.

Déclencheur 1 – CONFIGURATION UTILISATEUR : ÉTAPE D’ENTRÉE

Il s’agit du premier déclencheur avec lequel vous interagissez. Son objectif est de définir les valeurs d’entrée dont le bloc logique a besoin avant qu’un identifiant puisse être généré. En pratique, ce déclencheur sert à définir :* Le préfixe : _configPrefix* La longueur de l’identifiant : _configIdNumberFormat* L’identifiant de la table transmis au connecteur : tableId

Signification de chaque valeur

**_configPrefix :**il s’agit du texte placé au début de chaque identifiant généré. Vous l’utilisez pour définir la séquence que vous souhaitez générer.

Exemples :* ORD* INV* TEST

Si _configPrefix = ORD, le bloc logique ne prend en compte que les identifiants existants commençant par ORD, et ne poursuit que cette séquence. Cette valeur remplit donc deux fonctions à la fois :* elle définit le préfixe visible dans l’identifiant final* elle définit quels identifiants historiques le connecteur doit utiliser comme source pour le prochain numéro

Cela signifie que des préfixes différents dans une même table produisent des séquences différentes**._configIdNumberFormat**

Ce paramètre définit la longueur de la partie numérique de l’identifiant. Vous le définissez sous la forme d’une chaîne complétée par des zéros. Exemples :000000000000000000

Le nombre de zéros définit la largeur de la partie numérique.

Exemples :0000 → 0001, 0002, 0003 … 9999 ; 000000 → 000001, 000002 … 999999

Cette valeur ne définit pas le nombre lui-même. Elle définit le format dans lequel le nombre doit s'inscrire. Je l'utilise à deux fins : * pour ajouter des zéros non significatifs au début du nombre généré * pour vérifier si le nombre suivant respecte toujours la longueur autorisée

tableId

Ce paramètre définit la table sur laquelle le connecteur doit effectuer une requête.

En pratique, c’est ce qui rend le bloc logique réutilisable sur différentes tables. Vous pouvez copier le même bloc logique et le pointer vers une autre table en modifiant uniquement cette valeur dans le déclencheur de configuration.

Le bloc logique n’effectue pas de recherche dans les tables de lui-même. Il transmet tableId et _configPrefix au connecteur, et ce dernier renvoie le dernier ID correspondant issu de cette table.

Comment les utiliser ensemble

Ces trois valeurs définissent ensemble le comportement du générateur :* tableId indique au bloc logique où chercher* _configPrefix lui indique quelle séquence poursuivre* _configIdNumberFormat lui indique comment la partie numérique doit s’afficher

Conseils pratiques de configuration

Lorsque vous configurez le bloc logique, assurez-vous que :* tableId pointe vers la bonne table* _configPrefix correspond au préfixe que vous souhaitez poursuivre* _configIdNumberFormat correspond à la longueur du nombre que vous souhaitez imposer

Si vous modifiez le préfixe, vous ne poursuivez plus l’ancienne séquence. Vous démarrez ou poursuivez une séquence différente, spécifique à ce préfixe. Si vous augmentez ultérieurement la longueur du format numérique, le bloc logique s’attendra à ce format plus long lors de la validation des identifiants existants dans cette table et dans le champ d’application de ce préfixe.Le connecteur récupère le dernier identifiant correspondant au préfixe et le stocke dans _stateLastId. S’il n’existe encore aucun identifiant, la fonction LINK() garantit que le générateur peut toujours produire le premier identifiant valide.

Pourquoi le connecteur fait-il partie de la conception ?

Le connecteur n’est pas seulement un détail technique. Il fait partie de la stratégie de réutilisation. J’utilise le connecteur pour lire le dernier identifiant existant dans la table cible. Le connecteur reçoit l’identifiant de la table en entrée, applique le filtre de préfixe, trie les enregistrements par _sequenceNumber dans l’ordre décroissant, puis renvoie le dernier enregistrement correspondant.

Ceci est important pour deux raisons.

Premièrement, cela permet au bloc logique de poursuivre la numérotation à partir de l’état réel de la table.

Deuxièmement, cela facilite considérablement la réutilisation du bloc logique. Si vous copiez le bouton dans une autre application, vous n’avez pas besoin de réécrire la logique. Il vous suffit de pointer le connecteur vers la bonne table et de fournir la configuration nécessaire. Voici le modèle pratique qui sous-tend cette implémentation : * créer le bouton une seule fois * définir la table en entrée dans le connecteur * définir le préfixe et le format du nombre * le réutiliser partout où cela est nécessaire

Il s’agit d’un choix délibéré visant à accélérer la création d’applications.

Que fait le connecteur dans le bloc logique ?

Voici ce qui se passe :* le connecteur reçoit l’ID de la table* le connecteur reçoit le préfixe* le connecteur filtre les enregistrements par préfixe* le connecteur trie les enregistrements par _sequenceNumber par ordre décroissant* le connecteur renvoie le dernier ID correspondant

Le connecteur prend également en charge un cas d’utilisation très important : la présence de plusieurs entités dans la même table.

Si une même table contient des enregistrements tels que : ORD20240001 MAT20240011

alors le bloc logique ne doit pas les traiter comme une seule séquence partagée. Chaque préfixe doit reprendre uniquement à partir de sa propre dernière valeur.

Le connecteur effectue donc d’abord un filtrage par préfixe. Cela signifie que les valeurs suivantes deviennent : ORD → ORD20240002, MAT → MAT20240012

J’ai choisi ce modèle car différentes entités peuvent coexister dans la même table, mais cela ne signifie pas pour autant qu’elles doivent partager le même numéro séquentiel.

Une exigence de configuration mérite également d’être clairement précisée : le connecteur nécessite une authentification ; un jeton doit donc être généré et ajouté aux paramètres d’authentification du connecteur. Je considère cela comme une tâche de configuration, et non comme faisant partie de la logique du bloc logique lui-même, mais cela reste un élément important pour rendre le bloc logique utilisable.

Déclencheur 2 – MAGIC : validation + génération d’ID

Ce déclencheur constitue le cœur de la logique du bloc logique. Il effectue trois opérations dans l’ordre : 1. vérifie si le dernier identifiant correspondant présente la structure attendue ; 2. vérifie si le numéro suivant respecterait toujours la longueur numérique configurée ; 3. génère l’identifiant suivant.

J’ai regroupé ces étapes dans un seul déclencheur, car elles appartiennent au même flux de décision. Avant de créer un nouvel identifiant, je souhaite répondre à trois questions : * l’identifiant précédent peut-il être utilisé en toute sécurité d’un point de vue structurel ? * le nombre suivant respecterait-il toujours le format ? * si oui, quel devrait être le prochain identifiant ?

Validation du format

Expression

REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + DATETIMETOTEXT(App info.Current Date and Time, 'YYYY') + Variable._configIdNumberFormat), '^' + Variable._configPrefix + '[0-9]{4}' + '[0-9]{' + LEN(Variable._configIdNumberFormat) + '}$','ok')

Fonctionnalité de cette expression

Cette expression vérifie si le dernier ID correspond exactement à la structure attendue par le bloc logique. Elle fonctionne dans l’ordre suivant : 1. LINK(...) récupère Variable._stateLastId.id lorsque le connecteur a renvoyé une valeur. 2. Si aucun ID n’existe encore, LINK(...) utilise une valeur de secours construite à partir de : * Variable._configPrefix * DATETIMETOTEXT(...,'YYYY') * Variable._configIdNumberFormat3. Cette valeur de secours est incluse afin que la validation dispose toujours d’une structure valide à évaluer, même s’il s’agit du premier ID généré.4. Variable._configPrefix définit le préfixe exact par lequel l’ID doit commencer.5. DATETIMETOTEXT(...,'YYYY') n’est pas utilisé comme valeur de correspondance au sein de l’expression régulière elle-même, mais il fait partie de la structure de secours afin que celle-ci ressemble à un véritable ID.6. LEN(Variable._configIdNumberFormat) définit le nombre de chiffres que doit contenir la partie numérique.7. REGEX_REPLACE(...) compare ensuite la chaîne complète à ce modèle : * préfixe * exactement 4 chiffres pour l’année * exactement N chiffres pour la partie numérique8. Si la chaîne complète correspond, la valeur entière est remplacée par « ok ».9. En cas de non-correspondance, la valeur d’origine reste inchangée.10. Le déclencheur vérifie ensuite si le résultat est égal à « ok ». Si ce n’est pas le cas, l’exécution s’arrête.

Cette fonction « expression » n’extrait donc pas de valeurs à des fins de calcul. Son rôle est de vérifier que l’ID présente la structure attendue avant que toute logique numérique ne soit appliquée.

Pourquoi j’ai choisi cette approche

J’ai choisi de valider la structure complète de l’ID avant d’appliquer toute logique numérique. Je l’ai conçu ainsi car le reste du déclencheur part du principe que les éléments occupent des positions fixes :* préfixe au début* année immédiatement après le préfixe* nombre immédiatement après l’année

Si l’ID précédent ne respecte pas ce contrat, l’incrémentation à partir de celui-ci ne serait pas fiable.

J’ai également choisi d’inclure ici la solution de secours LINK(...) afin que le premier identifiant généré ne nécessite pas de logique de validation distincte. Le même chemin de validation fonctionne, qu’un identifiant plus ancien existe ou non. J’interromps intentionnellement le déclencheur plutôt que d’essayer de corriger les identifiants mal formés. Une correction automatique masquerait les problèmes de données et pourrait créer une séquence qui semble valide mais qui repose sur une entrée erronée.

Protection contre les dépassements

Expression

LEN(IF(MID(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat), LEN(Variable._configPrefix), 4) = DATETIMETOTEXT(App info.Date et heure actuelles,'AAAA'),RIGHT(Variable._configIdNumberFormat + TOTEXT(TEXTTOINTEGER(REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}','')) + 1), LEN(Variable._configIdNumberFormat)), RIGHT(Variable._configIdNumberFormat + '1', LEN(Variable._configIdNumberFormat))))

Fonctionnalité de cette expression

Cette expression calcule quelle serait la partie numérique suivante, puis en mesure la longueur. Elle fonctionne dans l’ordre suivant : 1. LINK(...) utilise le dernier identifiant lorsqu’il en existe un. Sinon, elle utilise par défaut Variable._configPrefix + Variable._configIdNumberFormat. 2. MID(..., LEN(Variable._configPrefix), 4) extrait les 4 caractères situés immédiatement après le préfixe. Ceux-ci sont considérés comme la partie « année » de l’ID précédent. 3. DATETIMETOTEXT(...,'YYYY') fournit l’année en cours à des fins de comparaison. 4. IF(...) détermine si la partie numérique doit se poursuivre ou être réinitialisée : * même année → incrément * année différente → recommencer à 15. Dans la branche d’incrémentation, REGEX_REPLACE(...) supprime le préfixe et l’année à 4 chiffres du début de l’ID précédent afin que seule la partie numérique subsiste.6. TEXTTOINTEGER(...) + 1 convertit ce texte numérique en nombre et l’incrémente.7. TOTEXT(...) reconvertit le nouveau nombre en texte.8. Variable._configIdNumberFormat + ... place le format zéro configuré devant la valeur.9. RIGHT(..., LEN(Variable._configIdNumberFormat)) ne conserve que le nombre de chiffres requis.10. Dans la branche de réinitialisation, RIGHT(Variable._configIdNumberFormat + '1', LEN(...)) crée le premier numéro autorisé pour une nouvelle année.11. LEN(...) mesure la longueur de la partie numérique obtenue.

Le déclencheur compare cette longueur à la longueur autorisée définie par Variable._configIdNumberFormat. Si la partie numérique suivante s'avère trop longue, l'exécution s'arrête.

Pourquoi j’ai fait ce choix

J’ai choisi de calculer le numéro suivant de la même manière que l’ID est réellement généré, au lieu d’utiliser une formule distincte pour deviner à quel moment le nombre dépasserait la longueur autorisée.

J’ai conçu ce système ainsi car je souhaitais que la vérification de débordement suive exactement les mêmes règles que la génération réelle de l’identifiant. Cela réduit le risque que la logique de validation et la logique de génération divergent par la suite.

Il est plus sûr de s’arrêter ici que de continuer. Si la valeur numérique suivante ne respecte plus la longueur configurée, l’identifiant résultant enfreindrait la structure que vous avez configurée.

Par exemple, si le format numérique est 0000, alors 9999 est valide mais 10000 ne l’est pas. Je souhaite que le bloc logique détecte cela avant la création de l’enregistrement, et non après.

Logique de génération d’identifiants

Expression

Variable._configPrefix + DATETIMETOTEXT(App info.Date et heure actuelles, 'AAAA') + IF(MID(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat), LEN(Variable._configPrefix), 4) = DATETIMETOTEXT(Infos application.Date et heure actuelles, 'YYYY'), RIGHT(Variable._configIdNumberFormat + TOTEXT(TEXTTOINTEGER(REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}','')) + 1), LEN(Variable._configIdNumberFormat)), RIGHT(Variable._configIdNumberFormat + '1', LEN(Variable._configIdNumberFormat)))

Fonctionnalité de cette expression

Il s’agit de l’ expression qui génère l’ID final. Elle fonctionne dans l’ordre suivant : 1. Variable._configPrefix ajoute le préfixe configuré au début de l’ID. 2. DATETIMETOTEXT(App info.Current Date and Time, 'YYYY') ajoute l’année actuelle à 4 chiffres. 3. LINK(...) utilise le dernier identifiant renvoyé par le connecteur lorsqu’il en existe un. Si le connecteur ne renvoie pas d’identifiant, il utilise Variable._configPrefix + Variable._configIdNumberFormat comme structure de secours. 4. MID(..., LEN(Variable._configPrefix), 4) lit les 4 caractères situés immédiatement après le préfixe. Ceux-ci sont considérés comme la partie « année » de l’ID précédent.5. DATETIMETOTEXT(...,'YYYY') est à nouveau utilisé ici afin que l’ expression e puisse déterminer si l’ID précédent appartient à l’année en cours.6. IF(...) gère les deux cas de figure possibles : * même année → poursuivre la numérotation * année différente → remettre à 17. Dans la branche « même année », REGEX_REPLACE(...) supprime le préfixe et l’année à 4 chiffres du début de l’identifiant précédent afin que seule la partie numérique subsiste.8. TEXTTOINTEGER(...) + 1 ** incrémente cette valeur numérique.9. TOTEXT (...) reconvertit la valeur incrémentée en texte.10. Variable._configIdNumberFormat + ... place le format zéro configuré devant la nouvelle valeur.11. RIGHT (..., LEN(Variable._configIdNumberFormat)) ne conserve que le nombre de chiffres requis, de sorte que la partie numérique ait toujours une longueur fixe.12. Dans la branche de réinitialisation, RIGHT (Variable._configIdNumberFormat + '1', LEN(...))** crée le premier numéro d’une nouvelle séquence annuelle.13. Le préfixe, l’année en cours et le nombre formaté sont concaténés pour former l’identifiant final.

Le résultat final présente donc toujours la structure suivante :préfixe + année + nombre de longueur fixe

Pourquoi j’ai choisi cette approche

J’ai choisi de dériver l’identifiant suivant entièrement à partir du dernier identifiant réel de la table. J’ai conçu ce système de cette manière car l’identifiant précédent contient déjà toutes les informations dont la logique a besoin : * à quel préfixe appartient la séquence * à quelle année elle appartient * quelle était la dernière valeur numérique

Cela signifie que je n’ai pas besoin d’une table de compteur distincte, d’un champ d’année stocké, ni d’une réinitialisation annuelle programmée.

J’ai également opté pour un format à longueur fixe, car cela permet de conserver une structure prévisible et plus facile à valider.

En contrepartie, l’ expression e dépend d’une structure d’identifiant stricte. C’est pourquoi l’étape de validation intervient en premier. J’ai accepté ce compromis car un contrat strict et lisible est ici plus utile que d’essayer de prendre en charge de nombreux formats d’entrée peu rigoureux.

Déclencheur 3 – CONFIGURATION UTILISATEUR : ÉTAPE DE SORTIE

Il s’agit du dernier déclencheur du bloc logique. Son objectif est de définir ce qu’il doit advenir de l’ID généré dès que _stateOutput contient une valeur valide.

Le point important ici est que cette étape vous est intentionnellement laissée libre.

Si _stateOutput n’est pas vide, vous pouvez décider de la suite des opérations du bloc logique. Dans la configuration actuelle, le déclencheur affiche un message d’aide expliquant les étapes suivantes : * ajouter la table configurée à l’application * remplacer l’étape de message par un déclencheur « Créer un enregistrement » * utiliser _stateOutput comme nouvel identifiant d’enregistrement

Je l’ai conçu ainsi car le comportement de sortie peut varier selon les cas d’utilisation.

Vous souhaiterez peut-être :* créer un enregistrement immédiatement* stocker d’abord l’ID dans une autre variable* utiliser l’ID dans un workflow plus long* valider des conditions supplémentaires avant d’écrire dans la table

Au lieu d’imposer un comportement de sortie fixe, j’ai conservé la possibilité de configurer l’étape de sortie.

C’est pourquoi la configuration accessible à l’utilisateur se trouve aux deux extrémités du bloc logique :* la structure d’entrée est configurable* le comportement de sortie est configurable* la logique centrale reste au milieu

Approche de nommage des variables

Les variables internes utilisent un préfixe « _ » :* _configPrefix* _configIdNumberFormat* _stateLastId* _stateOutput

Cela permet de distinguer rapidement les valeurs de configuration des variables de traitement internes.

Limites de conception

Le bloc logique repose sur la structure suivante :préfixe + année + numéro. Chaque préfixe dispose de sa propre séquence indépendante.

Le bloc logique ne prend pas en charge un compteur partagé entre plusieurs préfixes.

Si l’année ou les parties numériques sont déplacées au sein de l’identifiant, l’ expressions t doit être ajustée en conséquence.

Résumé des choix de conception

Si je résume l’ensemble du bloc logique à ses principes fondamentaux, voici ce qu’il en ressort :* Je souhaitais une réutilisation rapide, c’est pourquoi le bloc logique est piloté par la configuration.* Je souhaitais que la table soit la source de vérité, de sorte que l’identifiant suivant soit toujours basé sur le dernier enregistrement réel.* Je souhaitais que la logique reste facile à maintenir, c’est pourquoi le calcul est centralisé en un seul endroit.* Je souhaitais que plusieurs entités dans une même table fonctionnent correctement, c’est pourquoi chaque préfixe dispose de sa propre séquence indépendante.* Je souhaitais que la structure de l’identifiant reste cohérente au fil du temps, c’est pourquoi l’année fait partie de l’identifiant et que la séquence se réinitialise automatiquement lorsque l’année change.* Je souhaitais protéger la table contre les mauvaises pratiques ; c’est pourquoi la validation du format et les contrôles de dépassement empêchent la création d’identifiants incorrects avant la création d’un enregistrement.* Je souhaitais que le flux du déclencheur reste lisible ; c’est pourquoi les responsabilités sont réparties en étapes claires : configuration, validation, génération, sortie.

C’est pourquoi le bloc logique se présente ainsi. Il ne s’agit pas seulement d’un générateur d’identifiants. C’est un modèle réutilisable pour la création contrôlée d’identifiants qui cherche à trouver un équilibre entre simplicité, réutilisation et protection des données, tout en intégrant directement la segmentation annuelle dans la structure de l’identifiant.

Participez

Rejoignez la communauté pour partager des améliorations, proposer des unités supplémentaires, signaler des problèmes ou discuter des choix architecturaux.