# Micro-frameworks dans la console d'administration > La console d'administration d'Asana était un véritable enchevêtrement de logiques sur mesure, jusqu'à ce que l'équipe crée des cadres déclaratifs qui ont rendu possible la migration assistée par l'IA. Découvrez comment l'équipe a réussi à livrer son produ Source: https://asana.com/fr/inside-asana/microframeworks-admin-console ## Micro-frameworks dans la console d'administration Chaque mise en œuvre d'Asana dispose d'une console d'administration. C'est là que les administrateurs informatiques configurent la façon dont leur entreprise utilise Asana, par exemple en ajustant les exigences en matière de mots de passe, les rôles et les autorisations, en déterminant si des fichiers peuvent être joints depuis Dropbox et en définissant qui peut voir un nouveau projet par défaut. Au fur et à mesure de la croissance d'Asana, la console d'administration a accumulé des années de logique personnalisée et de solutions ponctuelles, ce qui a rendu la création et la maintenance des contrôles administratifs de plus en plus coûteuses. Prenons un paramètre administratif : la confidentialité par défaut pour les nouveaux projets. Un administrateur choisit si un nouveau projet est initialement visible par l'ensemble de l'organisation, visible par son équipe ou privé et accessible uniquement aux membres invités. Simple à décrire, mais il y a beaucoup de complexité cachée : - Cette fonctionnalité est-elle incluse dans la formule du client ? - Le client payait-il auparavant pour cette fonctionnalité, a-t-il cessé de le faire et s'est-il retrouvé bloqué sur un paramètre qu'il ne peut plus modifier ? - S'agit-il d'un client HIPAA ou FedRAMP, où seuls les rôles à privilèges élevés peuvent le modifier ? - Une option est-elle rendue indisponible par un autre paramètre ? - Faut-il afficher une bannière d'information pour décrire les limitations actuelles ? Toute équipe souhaitant ajouter un paramètre administrateur devait répondre correctement à toutes ces questions. La plupart ont décidé que cela n'en valait pas la peine, et au fil du temps, l'écart entre ce qu'Asana pouvait faire et ce qu'un administrateur pouvait contrôler s'est creusé. Cela s'illustre par le fait que certains contrôles ne peuvent être configurés qu'au niveau de l'entreprise, ce qui empêche les administrateurs informatiques d'appliquer le contrôle à un simple sous-ensemble de leurs utilisateurs. Voici un extrait de la boîte de dialogue des paramètres de confidentialité du projet, utilisée pour déterminer si elle doit être désactivée et si une bannière doit être affichée : Il y a beaucoup de logique à analyser ici : les licences des fonctionnalités, la gouvernance, les dérogations liées à la structure de mise en œuvre et les rôles des utilisateurs, en particulier pour les réviseurs. Pour être rigoureux, il faudrait reconstruire la matrice de test dans sa tête afin de déterminer si elle est correcte. Et ce n'est là que la boîte de dialogue. La question de savoir si la ligne apparaît ou non sur la page des paramètres a été tranchée ailleurs, et de manière incohérente : Trois lignes, trois mécanismes, et le contrôle d'accès n'est pas toujours dans le même fichier. Donc, pour répondre à la question « Quels sont les paramètres que ce client voit réellement ? », il ne suffisait pas de lire chaque ligne, il fallait aussi examiner chaque composant. Cette question revient assez souvent : le service client essaie d'expliquer pourquoi un paramètre a disparu pour un client, un chef de produit veut une réponse claire sur la question de savoir si un nouveau contrôle est une modification rapide ou une modification qui prendra deux semaines, une nouvelle recrue essaie de trouver l'endroit unique qui détermine ce qu'un utilisateur spécifique peut voir. Plus globalement, quatre éléments rendaient le travail dans la console d'administration coûteux : - **Coûteux à réviser.** La logique se trouvait là où l'auteur l'avait placée. Ainsi, une PR pouvait introduire un comportement particulier sans que cela soit évident pour un réviseur, et l'exactitude n'était pas quelque chose que l'on pouvait facilement vérifier simplement en lisant. - **Le manque de standardisation masquait les bugs.** Nous avions des bugs de longue date qui étaient difficiles à détecter. Beaucoup étaient dus à un écart entre les spécifications du produit et sa mise en œuvre, causé par une multiplication des implémentations sur mesure. Les équipes prenaient des décisions arbitraires, ce qui faisait que chaque contrôle avait ses propres particularités. - **Coûteux à modifier.** Pour apporter une seule modification pour l'utilisateur final, il fallait trouver tous les endroits où une règle était codée, et il était rare qu'il n'y ait qu'un seul point de définition. - **Coûteux à tester.** La mise en place des tests nécessitait une connaissance approfondie des états du backend, et des tests manuels complets des mises en œuvre finales étaient impossibles en raison du nombre de dimensions interagissant entre elles. ## Présentation des cadres Nous avons créé un cadre déclaratif pour les contrôles administratifs afin qu'il serve de source de référence dans la base de code. Un contrôle indique désormais ce qu'il est : Chaque champ ici correspond à une branche de la boîte de dialogue ci-dessus : requiredAdminRole est la vérification HIPAA/super-administrateur, upsellBehavior correspond aux deux branches de vente incitative, et churnBehavior correspond au cas du client ayant résilié son abonnement, ce qui lui permet de restaurer les paramètres par défaut et rien d'autre. Dans ce cadre, le cadre expose des hooks que les ingénieurs utilisent pour déduire l'état calculé du contrôle. Jetez un œil à ce à quoi ressemble maintenant la même boîte de dialogue de confidentialité du projet : La chaîne de conditions de la bannière a été regroupée en un seul composant partagé, piloté par un hook centralisé. Le cadre gère la logique combinatoire de tous les différents scénarios, et les experts en la matière chargés de le maintenir, qui connaissent parfaitement le produit d'administration, peuvent apporter des modifications radicales en toute confiance. Nous utilisons désormais un typage strict pour guider les développeurs afin qu'ils renseignent les informations obligatoires nécessaires pour afficher correctement leur paramètre dans tous les scénarios possibles. Il est essentiel de noter qu'ils n'ont pas besoin de comprendre les subtilités de ces scénarios, ni la façon dont ils interagissent. Ces paramètres sont accessibles via des lignes dans l'interface utilisateur de la console d'administration. La visibilité de ces lignes a bénéficié du même traitement, et c'est là qu'intervient le deuxième cadre. Une ligne dans le registre des paramètres ne décrit pas ses propres règles de visibilité, mais la lie plutôt aux contrôles qui la représentent : Le tableau des contrôles est la valeur ajoutée. Il contient le même objet ProjectDefaultPrivacy que celui que la boîte de dialogue transmet à useAdminConsoleControl, et le registre l'exécute à partir de la même source de référence, de sorte que la page et la boîte de dialogue ne peuvent pas être en désaccord. Auparavant, il était calculé séparément, de sorte que les divergences pouvaient entraîner deux modes de défaillance : une ligne visible mais qui ouvre une boîte de dialogue inutilisable, et un paramètre payant pour un client sans ligne permettant d'y accéder. La centralisation a permis d'éliminer cette catégorie de bugs. Les tests qui ont adopté les cadres centralisés ont considérablement amélioré l'expérience des réviseurs de demandes d'extraction (pull requests). Prenons par exemple les tests de visibilité des lignes, qui répondent à la question « Quels sont les paramètres que ce client voit réellement ? » posée précédemment. Au lieu d'un code de test, un scénario n'est que des données : un profil type d'utilisateur, un état de domaine et les pages sur lesquelles il s'affiche. Et une ligne indique simplement dans quels scénarios nommés elle doit apparaître : Il n'y a pas d'appel de rendu ni d'assertion à écrire. Une suite de tests dynamique lit le catalogue et vérifie chaque ligne par rapport à chaque scénario dans lequel elle est mentionnée. Le catalogue est désormais le seul endroit qui indique ce que voit un client, vérifié par une machine. Fini le temps où l'on devait compter sur un relecteur de code diligent ou sur l'auteur pour identifier et rédiger correctement ses propres scénarios de test. ## Dans le monde de l'IA Nous avons entamé ce travail fin 2025, car nous avions anticipé la nécessité de permettre aux ingénieurs non experts de développer en toute confiance dans la console d'administration. À l'époque, l'objectif n'était pas d'optimiser les performances des LLM, mais il s'avère que la standardisation et la simplification de l'expérience pour les ingénieurs ont le même effet pour les agents d'IA. Avant de concevoir ces cadres, nous avons tenté de résoudre ce problème de migration en utilisant l'IA, ce qui a fonctionné d'un point de vue technique. Le problème était que ni l'agent ni le réviseur ne pouvaient déterminer si les tests étaient réellement corrects, ce qui entraînait un faux sentiment de confiance et des lacunes silencieuses. L'IA ne résout pas le manque de structure ; elle se contente de produire plus de code, plus rapidement, en s'appuyant sur la structure existante. [Google a fait valoir un argument similaire concernant le système de types de Go dans le cadre du développement assisté par l'IA](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/) : les types statiques agissent comme un filet de sécurité automatisé, car les LLM ont tendance à « halluciner » les propriétés et à faire correspondre des types incompatibles entre les fichiers. TypeScript n'est pas aussi strict d'un point de vue statique que Go, mais un cadre peut offrir la même garantie : définir le type du contrôle une fois au niveau du cadre, et chaque implémentation doit s'y conformer au moment de son utilisation. Une fois les cadres prêts, nous avons commencé à nous préparer à déléguer et à paralléliser. J'ai utilisé notre nouvel outil de développement basé sur les spécifications [link placeholder : article de blog en anglais sur le développement basé sur les spécifications : [Blog technique d'Asana - Développement basé sur les spécifications : les points positifs](/inside-asana/spec-driven-development)] pour créer une compétence qui effectue le travail de A à Z. Il encode l'ensemble de la conversion : définir le contrôle, appeler le hook, remplacer les bannières, mettre à jour les fragments, ajouter les nouveaux tests déclaratifs, ainsi qu'une liste de contrôle à mise à jour automatique et un journal des cas particuliers issus des conversions précédentes. Sur l'ensemble des quelque 150 migrations, 91 % n'ont nécessité aucune révision après examen. Lancer un agent pour rédiger une PR ne demande pas beaucoup d'effort, et examiner ladite PR non plus. Étant donné que tout est déclaré de manière prévisible, les réviseurs n'ont pas besoin d'être des experts en administration pour vérifier si la mise en œuvre correspond aux spécifications du produit. Plus important encore, cela permet d'élargir le vivier de réviseurs éligibles à un groupe d'ingénieurs beaucoup plus vaste, ce qui accélère le rythme de travail bien plus qu'un simple élargissement de l'entonnoir en amont pour la création de PR. Nous ne sommes pas les seuls à repenser la revue pour cette époque : [GitHub a reconstruit l'agent de revue de Copilot en s'appuyant sur des preuves structurées relatives aux PR](https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/) afin d'aider les réviseurs humains à poser les bonnes questions plus rapidement, réduisant ainsi le coût de la revue d'environ 20 %. La migration initiale d'environ 150 éléments couvrant plusieurs cadres a été définie comme un travail d'ingénierie manuel et ponctuel, de A à Z. En créant d'abord les cadres, puis en déléguant la migration aux ingénieurs chargés de superviser les agents par la suite, nous avons pu mener à bien l'ensemble du projet plus d'un mois plus tôt que ne le prévoyait le plan initial. ## Et maintenant ? La création de ces cadres n'a jamais été un projet en soi. Elle est née d'une nécessité, d'une feuille de route qui devait être parallélisée et mise à l'échelle, avec des effectifs limités et changeants tout au long du processus, et sans exiger de chaque contributeur qu'il soit d'abord un expert du domaine. Nous avons déjà constaté que cela fonctionnait au-delà de l'équipe qui l'a créé : 18 des 66 contrôles du cadre actuel ont été rédigés par des ingénieurs de 8 équipes différentes. Nous cherchons maintenant le prochain domaine dans lequel réaliser ce type d'investissement. Si quoi que ce soit, les arguments en faveur de cette approche sont encore plus convaincants aujourd'hui qu'ils ne l'étaient avant que nous commencions : un cadre déclaratif bien conçu ne se contente pas de faciliter la révision, il détermine si un agent produit quelque chose de fiable ou simplement quelque chose de rapide. C'est aussi ce qui pourrait rendre la revue autonome plausible : [Cloudflare a conçu un système dans lequel un relecteur IA approuve le code propre et bloque les problèmes réels de manière autonome](https://blog.cloudflare.com/ai-code-review/), et cela ne fonctionne que parce que ses entrées sont suffisamment structurées pour que le relecteur puisse leur faire confiance. La question suivante qui se pose est de savoir si nos données sont suffisamment structurées pour tenter la même chose. #### À propos de l'auteur Leo Zhang est ingénieur logiciel au sein de l'équipe Admin Foundations, qui aide les administrateurs informatiques à gérer leurs organisations. Actuellement, il améliore l’expérience de développement des autres ingénieurs produit dans la console d’administration en investissant dans les cadres techniques qui sous-tendent notre produit. #### Remerciements à l'équipe La conception, la mise en œuvre, les tests et la diffusion de ces modifications ont nécessité un énorme travail d'équipe. Cela a été rendu possible grâce aux contributions d'autres ingénieurs de l'équipe Admin Foundations : Yunus Rahbar, Maryam Booshehrian, Saverio Castelli, Bronwyn Damm, Cindy Yu, Calvin Norton et Jaxsun McCarthy Huggan. Walter Li, de l'équipe tigre chargée de la réussite des agents, a grandement contribué à la mise en place des bons outils d'IA pour ces migrations. ### **Références** - Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang et Elizabeth Kammer, « What Improves Developer Productivity at Google ? Code Quality », ESEC/FSE '22, novembre 2022. [https://doi.org/10.1145/3540250.3558940](https://doi.org/10.1145/3540250.3558940) - « Orchestrating AI Code Review at Scale », blog Cloudflare, avril 2026. [https://blog.cloudflare.com/ai-code-review/](https://blog.cloudflare.com/ai-code-review/) - Napalys Klicius, « De meilleurs outils ont dégradé la révision de code de Copilot. Voici comment nous l'avons réellement améliorée », The GitHub Blog, juillet 2026. [https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/](https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/) - « Why Go is an Ideal Language for AI-Assisted Software Engineering », blog Google Developers, août 2026. [https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/) - [Développement axé sur les spécifications : les points positifs et ce que nous avons appris après trois mois](/fr/inside-asana/spec-driven-development) ingénierie #### Ingénieur logiciel permanent Au bout de trois mois, nous avions une vision plus claire des situations dans lesquelles la structure ajoutée était utile et de celles où elle constituait un frein.L'un de nos ing ... - [Nous avons migré hors d'Enzyme en deux semaines. Cela aurait dû prendre cinq ans](/fr/inside-asana/migrating-off-enzyme-2-weeks) ingénierie Nous avons récemment utilisé l'IA pour terminer des années de travail d'ingénierie en un sprint environ. Voici comment et pourquoi cela a changé notre façon de penser ce qui est p ... - [Comment les AI Teammates créent de la mémoire : transformer le travail en connaissances réutilisables](/fr/inside-asana/ai-teammates-turn-work-into-reusable-information) Intelligence artificielle (IA) ingénierie La plupart des produits d'IA traitent la mémoire comme une fonctionnalité personnelle : ils se souviennent de faits concernant un utilisateur ou une discussion. Mais une IA qui co ... - [Agents IA pensés pour les équipes : contexte partagé et transparence dans l'IA d'entreprise](/fr/inside-asana/ai-agents-built-for-teams-context-transparency) ingénierie Intelligence artificielle (IA) Le manque de responsabilisation Les agents IA d'entreprise sont des systèmes d'IA qui peuvent effectuer des actions dans les processus partagés entre les équipes et les projets. C ... - [Microframeworks in the Admin Console](/fr/inside-asana/microframeworks-admin-console) ingénierie Chaque mise en œuvre d'Asana dispose d'une console d'administration. C'est là que les administrateurs informatiques configurent la façon dont leur entreprise utilise Asana, par ex ... - [ingénierie](/inside-asana/engineering-spotlight)