Brex face à l’IA : pourquoi la fintech accélère l’achat de logiciels

L’intelligence artificielle ne transforme pas seulement les métiers et les produits des entreprises. Elle bouscule aussi une fonction beaucoup moins visible, mais déterminante : l’achat de logiciels. Chez Brex, fintech connue pour ses cartes de paiement destinées aux entreprises, les procédures classiques d’approvisionnement se sont révélées trop lentes pour suivre l’arrivée continue de nouveaux outils d’IA.

Lors de la conférence HumanX AI, James Reggio, CTO de Brex, a expliqué que l’entreprise avait dû revoir en profondeur cette mécanique. L’enjeu n’est pas seulement de signer plus vite avec de nouveaux fournisseurs. Il s’agit de permettre aux équipes de tester ce qui peut leur être utile tant que l’intérêt est encore là, puis de conserver ou d’écarter les outils à partir d’usages concrets.

Cette approche peut sembler désordonnée au regard des méthodes traditionnelles. Brex assume pourtant une part d’incertitude. Dans un secteur où les produits et leurs capacités changent rapidement, attendre une décision parfaite peut surtout conduire à expérimenter trop tard. L’entreprise ne défend pas l’absence de règles : elle cherche plutôt à faire cohabiter vitesse d’essai, contrôle des données et discipline budgétaire.

Pourquoi les achats classiques deviennent trop lents pour l’IA

Dans une organisation établie, l’acquisition d’un logiciel suit souvent une succession d’étapes : expression d’un besoin, comparaison des solutions, validation du budget, examen de la sécurité, contrôle juridique, négociation contractuelle, déploiement, puis formation des utilisateurs. Ce processus protège l’entreprise contre des dépenses inutiles ou des risques liés aux données. Mais il peut s’étaler sur plusieurs mois.

C’est précisément ce que Brex a constaté. Selon James Reggio, les équipes qui demandaient un outil perdaient parfois tout intérêt avant la fin du circuit d’évaluation interne. Entre-temps, un produit pouvait évoluer, être remplacé par un concurrent ou ne plus correspondre à la manière dont le travail s’organisait réellement.

Le problème est particulièrement aigu avec l’IA générative. Un outil peut être pertinent pour résumer des documents, produire du code ou accélérer une recherche à un instant donné, puis changer de fonctions, de tarifs ou de conditions d’utilisation quelques semaines plus tard. À l’inverse, une solution très médiatisée ne prouve pas automatiquement son utilité quotidienne pour une équipe donnée.

Cette accélération ne signifie donc pas que tous les logiciels doivent entrer sans filtre dans l’entreprise. Elle change l’ordre des priorités : réduire le temps entre l’idée et l’essai, afin que la décision repose davantage sur l’expérience des utilisateurs que sur des hypothèses théoriques.

Le nouveau cadre de Brex pour tester les outils

Pour raccourcir les délais, Brex a mis en place un cadre destiné aux accords de traitement des données et aux validations juridiques. L’objectif est de ne pas recréer l’intégralité de l’examen à chaque arrivée d’un nouveau service, tout en conservant les garde-fous nécessaires avant de placer un outil entre les mains des employés.

Ce point est central. Dans les entreprises, un abonnement pris par une seule équipe peut engager bien plus qu’un budget. Il peut exposer des informations commerciales, du code, des documents internes ou des données personnelles. La vitesse recherchée par Brex s’accompagne donc d’une sélection en amont, avec une liste d’outils autorisés plutôt qu’une liberté totale d’achat sur n’importe quelle plateforme.

L’entreprise veut ensuite évaluer rapidement le potentiel réel des produits. Elle s’appuie pour cela sur un test désigné comme le « superhuman product-market-fit ». Derrière cette formule, l’idée est de dépasser la simple démonstration commerciale : un logiciel doit apporter une valeur suffisamment forte pour que les personnes concernées aient envie de continuer à l’utiliser dans leur travail.

Brex donne ainsi une place importante aux salariés les plus concernés par chaque outil. Leurs retours doivent permettre de préciser le besoin, d’identifier les cas d’usage qui fonctionnent et d’éviter d’investir dans une solution que personne n’intégrera à ses habitudes. Pour une IA, cette distinction compte particulièrement : une capacité impressionnante lors d’une présentation ne garantit ni la fiabilité des résultats, ni un gain de temps une fois l’outil utilisé chaque jour.

Donner un budget aux ingénieurs, sans ouvrir tous les robinets

L’une des mesures les plus concrètes adoptées par Brex consiste à attribuer à chaque ingénieur un budget mensuel de 50 dollars. Cette somme peut être utilisée pour choisir des outils au sein d’une liste approuvée par l’entreprise.

Le montant est limité, mais le signal organisationnel est fort. Au lieu de demander une autorisation détaillée pour chaque petit abonnement, les ingénieurs peuvent essayer des services susceptibles d’améliorer leur flux de travail. Cette autonomie rend l’expérimentation plus proche de ceux qui rencontrent les problèmes techniques au quotidien.

Elle produit aussi des informations utiles à l’entreprise. Si plusieurs équipes utilisent durablement la même solution, Brex peut mieux estimer la demande réelle avant de négocier une licence plus large. À l’inverse, un outil qui ne trouve pas son public peut être arrêté sans que l’organisation se retrouve liée trop longtemps à un contrat coûteux.

Ce modèle répond à un risque fréquent dans le logiciel d’entreprise : la prolifération d’abonnements qui se chevauchent. Elle est parfois appelée « shadow IT » lorsque les équipes adoptent des outils en dehors des règles prévues. Brex tente de canaliser ce mouvement plutôt que de l’ignorer, avec un cadre d’outils approuvés et un plafond de dépense individuel.

Environ 1 000 outils d’IA, puis une rationalisation nécessaire

Brex indique utiliser environ 1 000 outils d’IA. Un chiffre qui illustre l’ampleur du phénomène, mais qui pose immédiatement une question de gestion : comment éviter qu’un portefeuille aussi vaste ne devienne illisible, redondant et coûteux ?

La réponse avancée par l’entreprise tient dans le suivi des usages. Brex entend annuler les outils qui ne répondent pas à ses besoins, ou ne pas renouveler les contrats concernés. L’objectif n’est donc pas d’accumuler les solutions au nom de l’innovation. Il est de conserver celles dont la valeur apparaît dans le travail des équipes.

Cette logique peut également renforcer la position de l’entreprise lors des négociations de licences. Lorsqu’un acheteur connaît le nombre d’utilisateurs actifs, les fonctions réellement utilisées et les besoins des différents services, il peut discuter d’un contrat plus adapté. À l’inverse, acheter un très grand nombre de sièges avant même de savoir si les salariés utiliseront le produit conduit souvent à payer pour des licences inutilisées.

Pour les directions financières et les responsables informatiques, l’IA pose donc un double défi. Il faut éviter d’étouffer les expérimentations qui pourraient générer des gains de productivité, tout en empêchant une multiplication incontrôlée des abonnements. Le suivi de l’adoption devient aussi important que la sélection initiale.

Accepter le désordre ne veut pas dire accepter tous les risques

James Reggio présente l’acceptation du « désordre » comme une condition pour ne pas prendre de retard. Cette expression ne désigne pas un abandon des critères de décision. Elle reconnaît plutôt qu’il est difficile de prévoir à l’avance quel outil sera le plus utile, combien de temps il le restera ou quel service interne en tirera le meilleur parti.

Dans ce contexte, une décision imparfaite mais réversible peut parfois être plus raisonnable qu’une attente prolongée. Tester à petite échelle, recueillir des retours et arrêter rapidement ce qui ne fonctionne pas permet de limiter le coût des erreurs. Cette méthode demande toutefois un cadre clair : des données protégées, des règles de dépenses, des responsables identifiés et une capacité à mettre fin aux outils qui n’apportent pas la valeur espérée.

Toutes les décisions ne peuvent pas être traitées à la même vitesse. Un logiciel qui manipule des informations sensibles ou qui devient central pour une activité de l’entreprise exige une évaluation plus approfondie qu’un service utilisé de façon limitée pour une expérimentation. La leçon n’est pas de supprimer les validations, mais de proportionner leur lourdeur au niveau de risque et à l’ampleur du déploiement.

Brex ne communique pas ici de mesure chiffrée des gains de productivité obtenus, ni du nombre de licences effectivement supprimées grâce à cette organisation. Son témoignage porte avant tout sur une méthode de fonctionnement. Son intérêt réside dans le déplacement du regard : face à l’IA, l’achat de logiciel devient un processus continu d’essai, d’observation et d’ajustement, plutôt qu’une décision définitive prise une seule fois.

Ce qu’il faut surveiller dans la stratégie de Brex

La stratégie de Brex sera jugée sur sa capacité à préserver cet équilibre dans la durée. Plus une entreprise teste d’outils, plus elle doit savoir lesquels sont réellement utilisés, quelles données y circulent et quelles dépenses ils génèrent. La rapidité initiale n’a de sens que si elle est suivie d’une rationalisation rigoureuse.

Il faudra aussi observer si le budget de 50 dollars par mois donné aux ingénieurs permet de faire émerger des outils utiles sans créer trop de doublons. L’autonomie peut accélérer l’innovation locale, mais elle nécessite une vision centralisée pour repérer les produits similaires, mutualiser les licences et maintenir des règles cohérentes.

Enfin, l’expérience de Brex souligne une évolution plus large : les entreprises ne choisissent plus seulement un logiciel pour plusieurs années. Elles doivent apprendre à gérer un portefeuille de solutions mouvant, dans lequel les utilisateurs sont à la fois testeurs, prescripteurs et sources de données pour la décision. À l’ère de l’IA, accepter une part de désordre peut être une façon de rester agile, à condition de savoir quand et comment remettre de l’ordre.