L’ingénierie logicielle à l’ère du « No-Code » d’Excel
L’annonce récente d’intégration de capacités de résolution de problèmes complexes directement au sein d’Excel pour Windows, avec des « fonctionnalités d’automatisation et d’IA » pour assister les utilisateurs, mérite une attention particulière à mon avis. Si la promesse d’une autonomie accrue pour les utilisateurs métiers est séduisante, elle soulève une multitude de questions techniques et stratégiques qui ne sauraient être ignorées.
Traditionnellement, Excel a toujours été un peu le couteau suisse de la donnée pour le monde de l’entreprise. Ses capacités de calcul, de modélisation et de visualisation sont indéniables, et nombre de processus critiques reposent encore aujourd’hui sur des feuilles de calcul parfois vertigineuses. Cependant, l’évolution vers une « construction de solutions complexes » par Excel lui-même, aidé par l’IA, transforme potentiellement cet outil d’analyse en une plateforme de développement low-code ou no-code de facto.
Le cœur de cette évolution réside dans la capacité d’Excel à déduire et à proposer des formules ou des automatisations basées sur l’intention de l’utilisateur, et potentiellement à gérer des interactions complexes avec d’autres services via Power Automate ou Power Apps. Pour un DSI, l’avantage apparent est une réduction de la pression sur les équipes de développement, les utilisateurs métiers pouvant « résoudre leurs propres problèmes ». Cependant, cette autonomie accrue est à double tranchant.
Sur le plan technique, nous devons nous interroger sur la gouvernance de ces « solutions complexes ». Qui est responsable de la maintenance de ces constructions ? Comment sont-elles testées ? Quid de la gestion des versions, de la documentation technique et de la dette technique qui ne manquera pas de s’accumuler ? Les macros VBA ont déjà prouvé que des solutions métiers ad-hoc, bien que fonctionnelles, pouvaient devenir des boîtes noires critiques et ingérables, entraînant des risques opérationnels et de sécurité non négligeables. L‘IA d’Excel, aussi performante soit-elle pour « développer » des solutions, ne peut substituer la rigueur d’un cycle de vie de développement logiciel (SDLC) maîtrisé.
La connectivité avec des bases de données ou des API via Power Query ou Power Automate, si elle est simplifiée, ouvre également la porte à des intégrations « sauvages ». Sans une architecture d’intégration définie, des utilisateurs bien intentionnés pourraient créer des dépendances critiques, difficiles à identifier et à gérer pour les équipes IT. La gestion des identités et des accès (IAM) aux ressources sous-jacentes devient également un défi : comment s’assurer que les privilèges accordés via Excel respectent les politiques de sécurité de l’entreprise ?
Enfin, la performance et la scalabilité de ces solutions « Excel-centric » sont des points d’achoppement potentiels. Les limites inhérentes au modèle de données d’Excel, même avec les améliorations, pourraient rapidement être atteintes face à des volumes de données importants ou des logiques métiers gourmandes en ressources.
En conclusion, si cette évolution d’Excel est une démonstration impressionnante des capacités de Microsoft en matière d’IA et d’outillage, elle impose aux professionnels de l’IT une vigilance accrue. Il est impératif d’établir des cadres de gouvernance stricts, de sensibiliser les utilisateurs aux bonnes pratiques de développement low-code et de définir des architectures d’intégration claires. Ignorer ces aspects, c’est risquer de transformer un outil productif en une source de complexité et de risques systémiques. L’objectif n’est pas de freiner l’innovation métier, mais de l’encadrer pour garantir la pérennité et la sécurité de notre écosystème informationnel.