Disposable Software : le quatrième pilier manquant de notre productivité au travail avec l’IA
Un de nos leaders, Ishan Babbar, faisait face à une tâche particulièrement chronophage. Une tâche qui nécessitait l’analyse de centaines de points de données, répartis dans plusieurs fichiers, ainsi qu’une bonne compréhension d’un projet spécifique. Le genre de travail qui, de façon traditionnelle, prend entre six et huit heures d’effort minutieux et répétitif, et qui demande souvent plusieurs itérations tout au long d’un projet. Il avait déjà réalisé des versions de cette tâche à de nombreuses reprises au cours de sa carrière et savait exactement ce qui était requis (et à quel point ce serait exigeant pour son équipe).
Cette fois-ci, il a passé vingt minutes avec un outil de développement IA et a construit quelque chose à la place.
Pas un contournement. Pas un script bricolé à la va-vite. Un outil conçu sur mesure, utilisable immédiatement, pouvant être relancé à tout moment pendant le projet, et ajusté facilement. Lorsqu’il voulait une modification, une requête différente, ou une vérification inverse pour valider les résultats, il n’avait qu’à le demander, et quelques minutes plus tard, une version révisée était prête. Ce qui était auparavant une tâche de plusieurs heures, répétée potentiellement de nombreuses fois au cours du projet, est devenu une tâche de cinq minutes. Et voici ce qui m’a marqué : dès que le projet a été terminé, l’outil l’était aussi. Il n’a jamais été conçu pour évoluer. Il n’a jamais été conçu pour être transféré. Personne n’a eu à recueillir des exigences, à le rendre évolutif ou à obtenir une approbation sur une feuille de route. C’était un essuie-tout. On l’utilise, puis on le jette. Et c’était parfaitement correct, en fait, son caractère jetable était une fonctionnalité, pas un défaut.
Ça semble évident maintenant, mais ça ne l’était pas avant qu’il me le montre.
Les trois façons dont nous avons envisagé l’IA jusqu’à présent
Jusqu’à maintenant, notre pratique Salesforce fonctionnait principalement avec trois modèles mentaux pour l’adoption et l’utilisation de l’IA.
Le premier est la productivité générale : une IA intégrée directement dans les outils que notre équipe utilise déjà au quotidien. Notre suite bureautique, Slack, Salesforce évidemment, les plateformes que nous utilisons tous les jours. Une efficacité ambiante, en quelque sorte. Rendre son utilisation tellement naturelle, intégrée et intuitive que les gens ne pensent même plus à cela comme étant de l’IA.
Le deuxième est celui des outils stratégiques : des solutions construites avec l’IA et qui l’exploitent, conçues pour être utilisées par plusieurs membres de l’équipe, de façon répétée, dans un objectif précis. Cela demande de la réflexion, de la collecte d’exigences, de la gestion du changement, de la formation et un certain niveau de pérennisation. Ce sont des investissements à moyen ou long terme. Leur déploiement et leur adoption prennent du temps.
Le troisième est celui de la livraison : l’IA intégrée dans notre processus de développement lorsque nous construisons des solutions pour nos clients. Un environnement de bout en bout (même si, soyons honnêtes, ce n’est pas encore parfaitement fluide aujourd’hui, mais nous nous améliorons chaque jour) où les outils d’IA sont utilisés pour améliorer la collecte des besoins, la rédaction des user stories, les critères de test, le développement et l’assurance qualité.
Ces trois modèles sont réels, utiles, et nous continuons d’y investir. Mais ils partagent une hypothèse commune : qu’un outil qui vaut la peine d’être construit est un outil qui vaut la peine d’être maintenu. Que l’outil et son résultat doivent être durables.
Cette hypothèse laissait de côté toute une catégorie.
Ce que cela change réellement
Ishan n’avait besoin ni de réunion, ni de planification, ni d’intervention d’équipe pour construire ce qu’il a construit. Il était déjà expert du problème qu’il cherchait à résoudre. Il savait exactement ce qu’il voulait, pouvait le décrire avec précision et demander sa création. Le fait que ce ne soit pas parfait dès la première version n’avait aucune importance. Les itérations étaient peu coûteuses. Le fait que cela ne fonctionne pas pour d’autres projets n’avait pas d’importance non plus, ce n’était pas l’objectif. L’absence de scalabilité était une caractéristique, pas un échec.
C’est une équation économique complètement différente de tout ce à quoi nous avions appliqué l’IA auparavant. Il n’y a pas de calcul de coût total de possession à long terme ici, parce qu’il n’y a pas de long terme. Il n’y a pas d’alignement entre parties prenantes requis, parce que la seule personne qui compte vraiment dans l’instant, c’est celle qui construit l’outil.
Nous commençons maintenant à diffuser activement cette idée au sein de la pratique Salesforce. La question que nous posons à l’équipe est simple : avant de passer cinq ou six heures sur une tâche, demandez-vous si vous pourriez passer vingt minutes, trente minutes, même une heure, à construire un outil jetable pour la réaliser à votre place. Toutes les tâches ne s’y prêtent pas. Mais beaucoup plus qu’on pourrait le croire. Et les personnes les mieux placées pour les identifier ne sont pas les leaders — ce sont celles et ceux qui font le travail concret, au quotidien.
La partie qui devrait rendre les leaders inconfortables
Il y a quelque chose d’important à considérer ici. Cette idée ne vient pas de moi. Elle vient d’un membre de notre équipe, sur un projet, parce qu’il avait les outils et l’instinct pour les utiliser différemment. Ma seule contribution est d’essayer de créer un environnement où ce type d’initiative peut émerger et se propager.
C’est de plus en plus à ça que ressemble le leadership dans une organisation orientée IA. Nous pouvons définir une stratégie et fixer des objectifs — par exemple, notre objectif d’efficacité de 5 % par trimestre dans la pratique Salesforce — mais les applications les plus intéressantes de l’IA viendront des personnes directement impliquées dans le travail, pas de celles qui l’observent de loin.
Le rôle de leader, que ce soit pour une équipe RevOps, une équipe de praticiens Salesforce ou une petite équipe agile chargée de déployer les premiers cas d’usage d’Agentforce dans votre organisation, est de s’assurer que votre équipe dispose des outils, de la permission et du langage nécessaires pour agir sur ce qu’elle découvre. Nous avons intégré le concept de « Disposable Software » dans notre vocabulaire. C’est comme ça que ça se diffuse.
