Dans mon article précédent, j’ai parlé de l’état actuel de la définition des besoins en IA – comment le processus passe de l’« organisation » à la « décision », et mon inquiétude de voir de nombreux environnements de travail déléguer leur réflexion sans même s’en rendre compte.
Cette fois, je veux tirer une autre sonnette d’alarme sur un sujet connexe.
Le problème, c’est que les CTO et les SE internes, parce qu’ils peuvent désormais coder très vite grâce au développement assisté par l’IA, deviennent de simples « preneurs de commande » des directions métier – en substance, des « SIer internes ».
Les nouvelles dynamiques créées par le développement assisté par l’IA
C’est un fait indéniable que la diffusion du développement assisté par l’IA a considérablement abaissé la barrière du codage.
En conséquence, les demandes des directions métier comme « Je veux ceci » ou « Je veux automatiser cela » arrivent à une vitesse sans commune mesure avec le passé. Il n’est pas rare que des collaborateurs métier listent eux-mêmes leurs besoins via l’IA, voire créent des prototypes.
À première vue, cela semble une bonne chose. On dirait un scénario idéal où les directions métier prennent la tête de la transformation numérique et collaborent avec l’informatique pour lancer rapidement des systèmes.
Mais il y a un piège.
J’ai l’impression que de plus en plus de CTO et de SE internes deviennent des « personnes qui se contentent de concrétiser les demandes des directions métier ». Ils reçoivent une demande, la réalisent techniquement et la livrent. C’est exactement ce que fait un SIer interne.
Ce qui vous attend au bout de la prise de commandes
Répondre aux demandes métier n’est pas mal en soi. Le problème, c’est ce qui se passe quand vous continuez à satisfaire chaque demande individuelle d’un service telle quelle.
J’appelle cela la prolifération de « systèmes sauvages » et de « bases de données sauvages ».
Les ventes créent leur propre CRM, le Marketing met en place une plateforme d’analyse distincte, et le Service Client construit son propre outil de tickets. Chaque service est satisfait car il a obtenu un système optimisé pour son travail, à grande vitesse.
Mais qu’en est-il de l’entreprise dans son ensemble ?
Les données sont éparpillées à différents endroits, les formats ne sont pas unifiés. Les mêmes informations client existent sous des formes différentes dans plusieurs bases de données. Dès qu’on essaie de relier les données entre services, on a besoin de travail manuel ou de développements spécifiques.
C’est un silo technique.
Parce que le développement assisté par l’IA rend la construction de systèmes si facile, cette fragmentation progresse à une vitesse inédite. Auparavant, les coûts élevés de développement agissaient comme un frein naturel. Il y avait une dynamique du type « c’est difficile à construire, donc sélectionnons strictement ce qui est vraiment nécessaire ».
Aujourd’hui, ce frein a disparu. Parce que c’est possible de construire, on construit. Résultat : les systèmes et bases de données sauvages se multiplient, et le nombre d’applications et d’infrastructures à gérer ne cesse d’augmenter.
Pourquoi cela est fatal à l’ère de l’IA
Vous pourriez penser : « Même si les systèmes sont un peu dispersés, ça va tant qu’ils fonctionnent. » Cependant, à l’ère de l’IA, cette fragmentation provoque des problèmes plus graves qu’auparavant.
La raison est simple : La valeur de l’IA est proportionnelle au degré d’intégration des données.
L’IA montre vraiment sa puissance quand les données sont intégrées dans toute l’entreprise, permettant des analyses transversales. Ce n’est que lorsque les données commerciales, l’historique client, les effets marketing et les données financières sont intégrées que l’IA peut fournir des informations aidant les décisions de gestion.
Dans un environnement plein de systèmes sauvages, les données ne sont tout simplement pas connectées. Vous pouvez réaliser de petites optimisations IA au sein des services, mais vous n’atteindrez jamais une utilisation de l’IA à l’échelle de l’entreprise – celle qui a vraiment un impact business.
En accumulant les optimisations par service, vous perdez définitivement l’optimisation globale. C’est le risque que les CTO et SE internes preneurs de commande créent sans le savoir.
Le vrai rôle que les CTO et SE internes devraient jouer
Alors, comment les CTO et SE internes devraient-ils être ?
La réponse est claire : Devenez des « concepteurs et décideurs » plutôt que de simples « bâtisseurs ».
« Conception » ne signifie pas ici concevoir des systèmes individuels. Cela signifie concevoir l’architecture des données et des systèmes pour l’ensemble de l’entreprise.
Quand une demande arrive d’un service métier, au lieu de simplement la construire, vous jugez « comment cette demande doit se positionner dans l’architecture d’entreprise ». Dans certains cas, vous devez dire : « Cela ne devrait pas être construit individuellement. » Si cela peut être traité en étendant les plateformes existantes, orientez-les vers cela.
Cela peut sembler contraignant pour les services métier. Ils pourraient demander : « Pourquoi parlez-vous de toute l’entreprise alors que je veux juste que ceci soit construit maintenant ? »
Mais seuls les CTO et SE internes peuvent faire ce jugement. Les services métier sont incités à optimiser leur propre périmètre, mais n’ont aucune incitation à protéger l’architecture d’entreprise. C’est pourquoi les experts techniques doivent jouer le rôle de gardiens de l’optimisation globale.
La « décision de ne pas construire » est la compétence technique la plus élevée
Ironiquement, la capacité la plus importante requise des CTO et SE internes à l’ère de l’IA pourrait être la « décision de ne pas construire ». C’est pourquoi je les appelle les « décideurs ».
Une demande arrive d’un service métier. C’est techniquement possible. Avec l’IA, cela peut être façonné en quelques jours. Mais vous devez avoir le pouvoir de vous demander si le construire est vraiment bon pour l’ensemble de l’entreprise.
Cette demande peut-elle être traitée par les plateformes existantes ? La structure des données est-elle conforme aux règles de l’entreprise ? Un système similaire fonctionne-t-il déjà dans un autre service ? L’ajout d’un système optimisé individuellement rendra-t-il difficile l’intégration future des données ?
Être capable de poser ces questions est la véritable force technique à l’ère de l’IA.
L’IA s’occupera du codage. Cependant, juger quoi construire et quoi ne pas construire est quelque chose que l’IA ne peut pas faire. Comme je l’ai mentionné dans l’article précédent où « la définition des besoins deviendra un processus de prise de décision », le rôle des CTO et SE internes suit exactement la même structure.
Plutôt que d’être des preneurs de commande, votre rôle en tant que concepteurs de l’architecture d’entreprise devient de plus en plus important précisément à cause de l’ère de l’IA.
Créer un « état de préparation » parce que l’avenir est imprévisible
Bien que j’aie souligné l’importance de la « décision de ne pas construire », il y a une perspective supplémentaire que les CTO et SE internes devraient avoir.
Parce que l’avenir est imprévisible à l’ère de l’IA, vous devez maintenir l’entreprise dans un état où elle peut bouger à tout moment.
Actuellement, le discours selon lequel « le SaaS est mort » se répand. Depuis que le PDG de Microsoft, Satya Nadella, a prononcé ces mots fin 2024, beaucoup ont prédit la fin du SaaS. Effectivement, les valorisations du SaaS sont comprimées, et l’intérêt des investisseurs se tourne rapidement vers les plateformes natives de l’IA.
Mais le SaaS est-il vraiment en train de mourir ?
Je ne pense pas que ce soit si simple. Les entreprises SaaS investissent massivement en R&D pour trouver la forme optimale du logiciel à l’ère de l’IA. Intégration d’IA agentique, facturation basée sur les résultats, plateformes IA spécifiques à un secteur… Il y a une forte probabilité que des produits émergent sous des formes que nous ne pouvons pas imaginer actuellement.
En d’autres termes, conclure à la fois « le SaaS est mort » et se précipiter vers le développement interne, ou arrêter de réfléchir en pensant « le SaaS suffit », sont des risques.
La posture qu’un CTO/SE interne doit adopter n’est pas de parier sur l’un ou l’autre. C’est de concevoir une architecture capable de répondre, quelle que soit la direction que les choses prennent.
Plus précisément, standardisez la manière dont les données sont détenues et créez une structure qui n’est pas verrouillée sur un SaaS ou un outil spécifique. Gardez les connexions entre systèmes faiblement couplées via des API. Ne laissez pas proliférer les systèmes sauvages ; unifiez le socle de données de l’entreprise.
Avec cette philosophie de conception, si le SaaS évolue et que de meilleurs produits arrivent, vous pouvez basculer. Inversement, s’il devient clair que construire en interne est meilleur pour un certain domaine, vous pouvez migrer vers cela.
Vous ne pouvez pas prédire l’avenir. Mais vous pouvez créer une structure capable d’y répondre. C’est l’essence de la conception architecturale requise des CTO et SE internes à l’ère de l’IA. Inversement, seuls les experts techniques peuvent le faire. Je ne veux pas que vous consacriez ces précieuses ressources à jouer les SIer internes.
Accélérer les processus en amont avec l’IA
En tant qu’outil pour soutenir la transformation des processus en amont, nous avons publié « GEAR-UI », un outil de génération de maquettes et de définitions d’écrans basé sur l’IA, en tant qu’OSS (Open Source Software).
En le rendant OSS, nous espérons libérer les utilisateurs des obstacles de mise en œuvre et les aider à se confronter à l’essentiel. Utilisez-le surtout pour les jugements « avant construction » que j’ai évoqués.
La personnalisation est libre. N’hésitez pas à l’utiliser.
