> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2021/w03-digital-workflow.md).

# W03-Le workflow numérique

En préparant le plan 2021, Jerry m'a demandé comment mesurer la compréhension du métier dans l'équipe.

J'ai envisagé plusieurs angles. Côté résultats : capacité de l'architecture à soutenir l'activité, pertinence de la planification technique, nombre de problèmes métier améliorés par l'ingénierie. Côté processus : temps consacré au domaine, implication dans les discussions de besoins et de plans, retours des autres fonctions. Aucune de ces dimensions n'est vraiment SMART. Transformer une capacité aussi abstraite en indicateur mesurable est difficile.

J'ai alors remarqué une ironie : nous travaillons à la numérisation, mais notre propre travail reste peu numérisé. Sans cela, difficile d'abstraire, de standardiser puis de passer à l'échelle. Nous ne savons pas extraire et diffuser l'expérience des meilleurs, ni construire des modèles de compétences comme la compréhension métier.

Pour la gestion de l'organisation, nous ne voyons aujourd'hui la répartition de l'énergie de chacun qu'à travers les demandes. Le reste est presque absent des données.

Même une demande complète suit une longue chaîne : revue du besoin, conception technique, code, intégration, revue de code, autotests, déploiement d'environnement, mise en production progressive, observation. Chaque étape produit des données, mais peu détaillées, surtout orientées vers les résultats plutôt que les comportements et processus. Les étapes sont rarement reliées. Dans Ones, chaque état de demande ou de tâche est changé à la main, avec oublis et retards. Les données ne donnent donc qu'une vue grossière. Idéalement, comme utilisateurs, nous ne devrions presque pas percevoir un outil de gestion des demandes tel Ones.

Cela m'a fait penser aux IDE cloud. Je comprenais mal leur valeur, mais à l'échelle de l'organisation, elle est considérable. Leur principal apport est selon moi le workflow numérique. L'IDE est l'outil le plus utilisé par les développeurs, mais chacun a le sien, et ses comportements et données restent hors ligne. Un IDE cloud devient une plateforme reliée à l'amont et à l'aval : branche associée directement à une demande, envoi en test et déploiement en un clic. Les seules données de base suffiraient à mettre Ones à jour. Il résout aussi des problèmes d'efficacité et de sécurité : environnement unifié, code source protégé sans être stocké sur le disque du développeur.

Imaginons la suite : une maquette produit automatiquement du code modifiable, importé dans l'IDE cloud pour ajustement, puis compilé et déployé en un clic sur plusieurs plateformes. Toutes les données et tous les actifs restent sur la plateforme, et chaque étape peut être optimisée précisément grâce aux données accumulées.