Nous allons ici proposer un cadre pratique destiné aux Citizen Dev pour 2025. Cet ensemble d’outils, de design et de méthodes évoluera avec le temps, mais ce qui restera constant, c’est la volonté de simplifier les choses grâce entre autres à l’uniformisation.
Dans notre recherche de simplicité nous devons uniformiser les technologies, ce qui veut dire, qu’il ne doit rester qu’un seul langage de programmation et ce sera le python. Un seul mode d’accès aux données, le SQL. Un seul style d’API, REST.
Code
Le citizen dev produit du code, un code qui opère le système d’information, il l’observe et modifie à loisir son état. Le citizen dev est un développeur dont le métier n’est pas de développer.
Une fois que l’IT aura terminé sa mutation (ce à quoi UCD participe), il existera ce risque très tentant, de vouloir imposer au Citizen dev les mêmes règles de fabrication de code que celles données aux software développeurs de l’entreprise.
L’écosystème
Vue simplifiée de l’architecture :
Le citizen dev exécute deux natures de code. La première sur sa machine de local, idéalement une Virtual Machine qui lui est dédiée, et la seconde sur une “runtime plateform” dans le cloud ou “on premise” peu importe.
Le premier type de code correspond à un usage très personnel et ad hoc. Le second correspond à des traitements devant être planifiés ou partagés avec le reste de l’équipe ou encore revus par Athéna.
Pour la runtime plateform nous conseillons Prefect.
Prefect offrent des fonctionnalités avancées pour la planification, la surveillance et la gestion des workflows, le tout en Python.
Dans le cadre de tout traitement n’imposant pas un changement d’état, le citizen dev va exécuter son code directement en production. Cela est possible dans la mesure où des seuils limites d’usage des ressources sont appliqués au sein des datasources et APIs.
Pour les autres actions, celles qui induisent du traitement et de la modification, nous ferons tout pour pouvoir les tester et exécuter directement en production. Il faut autant que possible éloigner le citizen dev des environnements de tests.
Nous voulons absolument faire disparaître la software factory et ce n’est pas un caprice d’adolescents. Dans ce cadre du citizen dev cela se justifie ainsi, la nature du code qu’il produit est moins noble que celui des software developer, les données qu’il manipule sont encadrées par des seuils, les résultats et traitements qu’il opère lui sont locaux ou au mieux touchent son équipe. Enfin aussi choquant que cela puisse paraitre, nous pensons qu’il existe des conditions pour tester son code en production.
Nous voulons aussi faire disparaître les architecture 3 tiers et offrir pour le citizen dev un expérience directe avec la donnée. Historiquement ce troisième tiers (le serveur) a été construit pour faire office d’intermédiation entre le client (lourd puis léger) et la base de données. A ce titre, il devait s’acquitter de la sécurité, de l’optimisation, de la cohérence de la logique métier, du monitoring, et enfin être une digue de protection sur les ressources sous-jacentes. La plupart des technologies de stockage moderne offrent la sécurité (row, column), l’optimisation, le caching, l’affectation d’unités de computing dédiées, le monitoring centralisé. Snowflake et Redshift en sont d’excellents représentants.
Le seul aspect non opéré par le retour d’une architecture 2 tiers est la centralisation de la logique métier, mais n’oublions pas comme cela a déjà été dit que les citizens opèrent d’abord pour eux, et rarement plus loin que la frontière de leur équipe, aussi cette synchronisation est possible par une gouvernance simple.
Nous ne voulons opérer qu’une seule source de données, ou plutôt qu’une seule représentation de cette source, c’est pour cela que nous ajoutons un composant de virtualisation de la data. Aussi bien pour les API, que pour les formes de persistances ne supportant pas le SQL.
La valeur du code / Please repeat yourself
Le code du citizen dev doit être vu comme un produit jetable tout comme les stylos, rasoirs et briquets. Basé sur ce constat et porté par nos trois valeurs, nous pouvons déployer nos règles de développement, en utilisant la méthode MoSCoW. Voici un exemple vraiment simpliste, à enrichir en situation :
Must :
- Suivre les pratiques de nommage Robert C. Martin
- Tout quantum de code doit pouvoir être réécrit en moins d’un jour.
Should :
- Réécriture du code si plus de 30% de modifications
- Maintenir un seuil de complexité du code inférieur à 20.
- Faire revoir son code par un LLM
Could :
- Effectuer une revue de code par Athéna pour améliorer la qualité et l’optimisation.
- Utiliser des outils de monitoring de performance pour identifier les points d’optimisation potentiels.
Won’t have:
- Héritage de classe
- D’avoir un code de complexité > 20
- De coupler son code avec d’autres équipes de l’entreprise
Si une nécessité émerge de faire un code réutilisable, ou par nécessité plus complexe, il faudra alors s’appuyer sur l’IT.
Python
Nous affirmons sans grand risque que le Python doit être le langage de développement du citizen dev. Il impose une syntaxe claire et concise, offre une large panoplie de librairies, un usage multiple et possède une grande communauté d’utilisateurs. Pour toutes ces raisons Python doit détrôner définitivement VBA.
On notera au passage qu’Excel aussi s’y est mis : https://support.microsoft.com/en-us/office/get-started-with-python-in-excel-a33fbcbe-065b-41d3-82cf-23d05397f53d
SQL My Love
Il est bien loin le temps où un système d’information se réduisait à deux bases de données, l’une pour le monolithe opérationnel et l’autre pour la BI.
Dans un système d’information (SI) moderne, il est inévitable de rencontrer différents types de bases de données, car chacune répond à des problématiques spécifiques. Parmi elles, on trouve les bases relationnelles (SQL comme MySQL, PostgreSQL, ou Oracle) pour les données structurées, les bases NoSQL (comme MongoDB, Cassandra) pour les données non structurées ou semi-structurées, ainsi que les bases de données orientées graphes (comme Neo4j) pour les relations complexes entre les entités. Chaque type de base de données propose une manière spécifique de les consulter, que ce soit via le SQL pour les bases relationnelles, des requêtes spécifiques à NoSQL, ou encore des langages comme Cypher pour les bases de graphes.
Cependant, un citizen dev n’a ni le temps ni l’expertise de maîtriser l’ensemble des langages et des paradigmes associés à chaque type de base. Exiger des équipes informatiques d’uniformiser tous les langages de requêtes serait non seulement irréaliste, mais également contre-productif, car cela entraînerait des pertes d’efficacité et de flexibilité dans le traitement des données.
Alors, que faire ?
La première solution réside dans la mise en place d’abstractions ou de couches intermédiaires, telle que la data virtualisation, qui permettent aux utilisateurs d’interagir en SQL avec différents types de bases, sans avoir à se soucier des spécificités techniques de chaque technologie sous-jacente.
La seconde solution demande plus d’effort et consiste à copier et transformer les sources de données dans des bases de données compatibles.
De toute façon cela doit se matérialiser au sein de la data plateforme.
Pour tout Résumer
Rôle de l’IT :
- Créer une infrastructure adaptée :
- Développer une plateforme de données en libre-service (self-service data platform) accessible aux Citizen Dev.
- Mettre en place des outils de virtualisation des données (ex. Denodo) pour faciliter l’accès aux datasets via SQL.
- Fournir un catalogue centralisé pour répertorier les données disponibles et leurs propriétaires (domain data product owner).
- Garantir la gouvernance :
- Assurer la sécurité des données (respect des règles GDPR, PII, etc.).
- Superviser la traçabilité (consommation, origine, distribution).
- Mettre en œuvre une gouvernance légère mais fonctionnelle, adaptée à l’autonomie des Citizen Dev.
- Offrir des outils et des APIs :
- Publier des APIs bien documentées pour l’accès aux données (lecture seule ou commandes CQRS).
- Proposer des outils low-code/no-code intégrés dans les workflows existants (Power Platform, Mendix, etc.).
- Faciliter l’autonomie :
- Éliminer les obstacles techniques inutiles (simplification des environnements de tests).
- Encourager l’utilisation d’architectures simples (éviter les architectures à 3 tiers pour privilégier l’accès direct aux données).
Rôle du Management de l’entreprise :
- Soutenir la transformation :
- Obtenir un engagement fort de la direction pour financer la formation et les infrastructures nécessaires.
- Promouvoir une culture d’autonomie et de collaboration entre les métiers et l’IT.
- Encourager l’adoption :
- Investir dans la formation continue des Citizen Dev sur les outils et technologies.
- Sensibiliser les équipes métier à l’importance de la gestion des données et des bonnes pratiques.
- Évaluer les compétences :
- Identifier les lignes métier prêtes pour cette transformation.
- Réaliser des audits ou sondages pour mesurer l’appétence et le niveau technique des équipes.
Rôle des Citizen Developers :
- Exploiter les outils disponibles :
- S’approprier les outils en libre-service pour accéder et manipuler les données (ex. Excel, Tableau, Power BI).
- Utiliser les APIs et catalogues pour répondre à leurs besoins métiers.
- Produire des solutions simples :
- Développer des scripts ou applications adaptées à leur équipe en respectant les règles de l’organisation.
- Limiter l’usage de macros complexes (ex. dans Excel) pour éviter des silos technologiques.
- Collaborer avec l’IT :
- S’appuyer sur l’IT pour des projets critiques ou complexes.
- Respecter les standards de sécurité et de gouvernance imposés.
- Se former en continu :
- Participer activement à des formations pour améliorer leur compréhension des données et des outils.
- Se familiariser avec des concepts tels que les datasets, la fraîcheur des données et les limites techniques des systèmes.
Leave a Reply