Pourquoi l'IA d'entreprise ramène les éditeurs de logiciels au cœur de l'entreprise
Pendant des années, le secteur des logiciels d’entreprise a évolué dans la direction opposée. Les produits se sont transformés en services cloud, la mise en œuvre s’est standardisée, l’assistance s’est déplacée en ligne et la présence physique du fournisseur chez le client a perdu de son importance. L’IA générative est aujourd’hui en train d’inverser en partie cette tendance.
Les entreprises peuvent activer un Assistant IA En quelques minutes, certes, mais relier un modèle aux processus qui déterminent la manière dont une banque gère une exception, dont un assureur évalue un dossier ou dont un fabricant coordonne une commande est une tout autre affaire. Le logiciel peut être fourni via le cloud ; le plus dur commence une fois au sein de l'organisation.
C'est pourquoi certaines entreprises spécialisées dans les technologies d'entreprise renforcent leurs équipes d'ingénieurs qui travaillent directement avec les clients. Ce rôle est souvent qualifié d'« ingénierie sur le terrain » : les développeurs sont affectés au plus près des activités de l'entreprise, où ils peuvent analyser les flux de travail, interconnecter les systèmes et adapter un produit standard à un environnement d'exploitation spécifique.
Camunda, entreprise berlinoise spécialisée dans l’automatisation des processus, en est un exemple. Son logiciel coordonne les flux de travail d’organisations allant des banques aux groupes industriels, en passant par l’agence spatiale américaine NASA. Alors que ses clients cherchent à intégrer l’IA dans ces processus, Camunda renforce ses effectifs d’ingénieurs qui travaillent directement avec eux. L'offre commerciale ne se limite plus à une simple licence logicielle. Elle inclut de plus en plus la capacité à comprendre le fonctionnement réel de l'activité du client.
Un modèle d'IA ne comprend pas l'entreprise qui l'entoure
L'attrait de l'IA générative réside en partie dans son apparente universalité. Un même modèle peut rédiger un e-mail, résumer un rapport, répondre à une question technique ou classer un document. Cette polyvalence peut donner l'impression que sa mise en œuvre se résume essentiellement à choisir un fournisseur et à connecter une interface.
Les procédures d'entreprise sont moins souples.
Une demande de prêt peut passer par plusieurs systèmes, services et niveaux d'approbation. Une demande d'indemnisation peut être traitée automatiquement, sauf si elle présente une combinaison inhabituelle de circonstances. Un document entrant peut devoir être classé, comparé aux dossiers existants et transmis à une équipe spécialisée. Chaque étape comporte ses propres autorisations, dépendances et conséquences.
Un modèle linguistique ne dispose que des informations et des outils qui lui sont fournis. Il ne sait pas en soi quel système contient l'enregistrement faisant autorité, à quel moment un collaborateur doit valider une décision, ce qui constitue une exception ou quelle action enfreindrait un contrôle interne.
Ces détails ne figurent souvent pas dans la documentation officielle des processus. Ils sont dispersés entre des applications héritées, des règles départementales, des tableurs et l'expérience des employés qui savent comment mener à bien une tâche lorsque la procédure standard ne fonctionne pas. Un fournisseur ne peut pas cerner cette structure à partir d'une démonstration à distance.
L'ingénieur travaillant au sein de l'entreprise du client ne se contente donc pas de mettre en place une fonctionnalité d'IA. Sa mission, bien plus importante, consiste à repenser le processus autour de celle-ci.
Les systèmes hérités s'intègrent désormais au projet d'IA
La plupart des entreprises bien établies ne partent pas de zéro pour mettre en place leur architecture d'IA. Elles exploitent déjà des combinaisons complexes de logiciels de gestion intégrée (ERP), de plateformes de gestion de la relation client, de systèmes de gestion documentaire, de bases de données et d'applications spécialisées, accumulées au fil de nombreuses années.
L'IA doit fonctionner dans cet environnement sans compromettre les systèmes qui continuent de stocker des données essentielles et d'exécuter des transactions stratégiques.
L'orchestration revêt donc une importance plus grande que le modèle lui-même. Un modèle peut certes interpréter une requête non structurée, mais une autre couche doit encore déterminer quels systèmes doivent être consultés, quelles règles s'appliquent et quelle doit être la suite des opérations. Le processus doit également rester suffisamment transparent pour que l'entreprise puisse comprendre comment un résultat a été obtenu.
Le travail de Camunda auprès des institutions financières illustre bien ce principe. Dans un processus bancaire, le courrier entrant est classé et acheminé vers le service concerné, tandis qu’un agent IA traite les exceptions plus complexes. Cet agent opère au sein d’un flux de travail traçable plutôt que d’agir comme une «boîte noire» indépendante. Chacune de ses étapes peut être suivie et des contrôles peuvent intervenir avant qu’une erreur n’affecte le client ou l’ensemble du processus.
Ce type de déploiement est bien loin de se limiter à l'ajout d'un chatbot à une application existante. Il nécessite une vision détaillée du modèle opérationnel, y compris des systèmes qui n'ont jamais été conçus pour fonctionner avec l'IA générative.
Il faut repenser le processus, et non pas simplement l'embellir.
De nombreux projets d'IA d'entreprise lancés à leurs débuts se sont contentés d'ajouter une nouvelle interface à un flux de travail inchangé. Les employés se sont vu proposer un assistant de rédaction, un champ de recherche ou un outil de synthèse, tandis que la structure sous-jacente restait intacte.
Ces applications permettent certes de gagner du temps, mais elles n'apportent que rarement les gains de productivité plus importants associés à l'automatisation. Un employé peut certes créer un document plus rapidement, mais il devra tout de même transférer les informations manuellement, les vérifier dans un autre système et demander une validation en suivant une chaîne d'e-mails bien établie.
C'est lorsque les entreprises repensent le processus lui-même que l'IA prend toute son importance. Quelles étapes nécessitent un jugement humain ? Quels contrôles peuvent être automatisés ? Dans quels cas un modèle doit-il interpréter des informations non structurées, et dans quels cas un logiciel déterministe doit-il garder le contrôle ? Que faut-il faire lorsque le modèle manque de confiance ou est confronté à un cas qui dépasse son champ d'application ?
Pour répondre à ces questions, il faut autant de connaissances opérationnelles que de compétences techniques. Les éditeurs de logiciels, qui se concentraient autrefois sur la configuration des produits, s'orientent donc de plus en plus vers le conseil, la conception de processus et le changement organisationnel.
La distinction entre une entreprise de logiciels et un partenaire de mise en œuvre devient plus difficile à maintenir lorsque la valeur du produit dépend de son degré d'intégration dans les activités du client.
À chaque tâche son modèle
La présence de fournisseurs au sein de l'entreprise s'explique également par un marché caractérisé par un modèle plus fragmenté. Les entreprises ne partent plus du principe que chaque tâche d'IA doit être confiée au système le plus volumineux et le plus coûteux du marché.
Le recours à un modèle « frontier » puissant peut se justifier lorsque la tâche nécessite un raisonnement complexe ou porte sur des données ambiguës. Un modèle plus léger peut suffire pour la classification de documents, l’extraction d’informations ou les requêtes internes répétitives. Les entreprises peuvent également privilégier un modèle européen ou à pondération ouverte pour les applications où la souveraineté, le contrôle du déploiement ou la localisation des données revêtent une importance particulière.
Le défi consiste à attribuer le modèle approprié à chaque tâche.
Il s'agit en partie d'un choix technique et en partie d'un choix économique. Les coûts liés à l'IA peuvent grimper rapidement lorsque des modèles de grande envergure sont utilisés sans discernement dans des processus à haut volume. L'option la plus sophistiquée peut n'apporter qu'une faible valeur ajoutée à une tâche de classification courante, tandis qu'un modèle moins coûteux pourrait fonctionner de manière fiable dans le cadre d'un flux de travail strictement défini.
L'architecture d'entreprise émergente s'apparente donc à un système de routage. Chaque demande est évaluée en fonction de son niveau de sensibilité, de sa complexité, de son coût et des performances requises avant d'être acheminée vers un modèle approprié. Certaines tâches peuvent rester au sein de l'infrastructure contrôlée par l'entreprise, tandis que d'autres sont confiées à des services externes.
La conception et la maintenance de ce système exigent une compréhension approfondie de la charge de travail du client. Un fournisseur proposant l'accès à un seul modèle peut se contenter de rester à distance. Ce n'est pas le cas d'un fournisseur chargé de coordonner plusieurs modèles au sein des processus clés.
L'IA instaure une nouvelle norme en matière de responsabilité
L'automatisation traditionnelle des processus est généralement prévisible. Un système fondé sur des règles suit des instructions prédéfinies et produit le même résultat lorsqu'il reçoit la même entrée.
Les modèles génératifs se comportent différemment. Ils sont capables d'interpréter des contenus ambigus et de gérer des cas que des logiciels rigides ne peuvent pas traiter, mais leurs résultats sont probabilistes. Ils peuvent mal interpréter un document, inventer des informations ou choisir une action inappropriée.
Les entreprises ne peuvent pas éliminer ce risque simplement en choisissant un prestataire de confiance. Elles doivent mettre en place des contrôles autour de ce modèle.
Ces contrôles peuvent inclure des seuils de confiance, un accès pré-approuvé aux outils, des sources de données restreintes, une vérification humaine et une remontée automatique. Le système doit enregistrer quel modèle a été utilisé, quelles informations il a reçues et quelles étapes ont été suivies à partir de sa réponse. Lorsque le processus concerne un client, un salarié ou une décision soumise à réglementation, l'organisation doit être en mesure de reconstituer le déroulement des événements.
C'est l'une des raisons pour lesquelles les fournisseurs de solutions d'automatisation des processus pourraient gagner en influence sur le marché de l'IA d'entreprise. Leur valeur réside moins dans la création d'un modèle supplémentaire que dans l'intégration de ces modèles au sein de flux de travail régis par des règles, où leur pouvoir est limité et où leurs actions restent observables.
Le rôle du fournisseur se rapproche de plus en plus de celui d'un ingénieur chargé d'assurer le bon fonctionnement d'un système opérationnel. L'échec d'une démonstration est gênant. L'échec d'un processus de production peut entraîner l'interruption des paiements, retarder les commandes ou exposer l'entreprise à des risques réglementaires.
Les entreprises suisses attendront une certaine proximité sans pour autant renoncer à leur contrôle
Cette évolution revêt une importance particulière en Suisse, où de nombreuses entreprises combinent des activités réparties à l'échelle internationale avec des exigences élevées en matière de confidentialité, de traçabilité et de résilience opérationnelle.
Les banques, les assureurs, les groupes pharmaceutiques et les entreprises industrielles peuvent être disposés à recourir à des technologies d'IA externes, mais ils ont besoin de clarté quant aux flux de données, aux modèles utilisés et aux modalités de contrôle des décisions. Certains exigeront un déploiement au sein d'un cloud privé ou de leur propre infrastructure. D'autres combineront des modèles externes et des modèles gérés en interne, en fonction du degré de sensibilité de la tâche.
La capacité d'un fournisseur à prendre en charge plusieurs modèles peut donc s'avérer plus précieuse que l'accès exclusif à un seul modèle. Les entreprises peuvent souhaiter utiliser des systèmes proposés par de grands fournisseurs américains parallèlement à des modèles européens ou à des alternatives « open-weight ». Elles souhaiteront également disposer de la liberté de remplacer un modèle lorsque son coût, ses performances ou son profil de risque évoluent.
Cette flexibilité n'est utile que si le flux de travail global a été conçu en conséquence. Si chaque connexion, chaque mécanisme de contrôle et chaque pipeline de données est articulé autour d'un seul fournisseur, toute possibilité de choix disparaît. L'indépendance vis-à-vis des fournisseurs doit être intégrée dès le départ dans l'architecture.
Le fournisseur, qui travaille en étroite collaboration avec le client, est bien placé pour y parvenir, mais cette proximité soulève également une nouvelle préoccupation en matière d'approvisionnement. Une entreprise peut réduire sa dépendance vis-à-vis d'un fournisseur de modèles tout en devenant fortement tributaire du prestataire chargé de la mise en œuvre, qui comprend ses processus et assure la gestion de la couche d'orchestration.
Les contrats, la documentation et les capacités internes revêtent donc une grande importance. L'organisation doit conserver l'accès à ses définitions de processus, à ses données d'évaluation, à sa logique d'intégration et à sa documentation opérationnelle. Les ingénieurs du fournisseur peuvent contribuer à la mise en place du système, mais le client doit rester en mesure de comprendre ce qui a été mis en place.
Les ingénieurs déployés sur le terrain font désormais partie intégrante du produit
La demande renouvelée d'ingénieurs sur site ne signifie pas pour autant que les logiciels d'entreprise reviennent à l'époque des grandes équipes de mise en œuvre permanentes. La logique commerciale est désormais plus sélective.
Les produits d'IA sont relativement génériques au point de vente. Leur valeur augmente lorsqu'ils sont appliqués à un processus spécifique, avec des données, des règles et des résultats clairement définis. Les ingénieurs déployés sur le terrain réduisent l'écart entre la fonctionnalité générique et l'application opérationnelle.
Ils sont capables d'identifier un processus initial, de mettre en place les intégrations, de définir des tests de performance et de résoudre les problèmes qui n'apparaissent qu'en production. Une fois l'architecture stabilisée, l'entreprise peut l'étendre à des flux de travail connexes avec moins d'assistance directe.
Pour le fournisseur, cette approche permet de garantir l'adoption du produit au-delà de la phase pilote. Elle fournit également des informations qui ne peuvent être recueillies par le biais des analyses de produit classiques. Les ingénieurs identifient les défaillances du logiciel, les contrôles exigés par les clients et les différences entre les environnements d'exploitation réels et les hypothèses formulées par les équipes produit.
Cette solution est coûteuse, ce qui signifie qu'elle ne conviendra pas à tous les clients ni à toutes les applications. Cependant, les fournisseurs peuvent accepter ce coût lorsque l'alternative consiste en une série de projets pilotes prometteurs qui ne débouchent jamais sur des systèmes opérationnels.
Les logiciels deviennent indissociables de leur mise en œuvre
Le secteur des logiciels d'entreprise a passé des décennies à chercher à rendre ses produits plus reproductibles. La normalisation a permis d'augmenter les marges, d'accélérer les ventes et de faciliter l'expansion internationale. L'IA complique ce modèle, car cette technologie tire une grande partie de sa valeur du contexte.
Un modèle général peut être vendu à plusieurs reprises. Le bon fonctionnement d’un système d’IA d’entreprise dépend des données du client, de l’architecture de ses processus, de ses contrôles et de ses responsabilités organisationnelles. Plus l’application est proche des activités principales de l’entreprise, plus il devient difficile de dissocier le produit du travail nécessaire à sa mise en œuvre.
Cela ne signifie pas pour autant que tous les éditeurs de logiciels se transforment en cabinets de conseil traditionnels. Les éditeurs les plus solides continueront de s'appuyer sur des plateformes réutilisables, des connecteurs standard et des composants de gouvernance communs. Leurs ingénieurs ne reconstruiront pas chaque système à partir de zéro.
Ils devront toutefois avoir une connaissance bien plus approfondie de l'organisation que ne l'exige un abonnement classique à un logiciel.
L'IA d'entreprise ramène les fournisseurs au cœur des activités, car les entreprises ont compris que l'accès aux modèles n'était que la partie la plus simple. La véritable valeur commerciale réside dans la définition des capacités du modèle, son intégration aux systèmes clés et la garantie que le processus qui en résulte reste rentable, traçable et maîtrisé.
