Lorsqu'on crée une entreprise, on doit très tôt prendre des décisions concernant les logiciels. Quel CRM allons-nous utiliser ? Où allons-nous tenir notre comptabilité ? Où seront stockés nos documents ? Allons-nous travailler avec Microsoft 365 ou Google Workspace ? Avons-nous déjà besoin d'un ERP ?

La plupart des gens répondent à ces questions en se basant sur les critères actuels : le prix, les fonctionnalités, la facilité d'utilisation et peut-être encore les intégrations avec d'autres applications. L'intelligence artificielle soulève une question supplémentaire qui devrait prendre au moins autant d'importance à l'avenir :

Les systèmes d'IA pourront-ils par la suite accéder de manière pertinente aux données et aux processus de ce logiciel ?

Quiconque répartit aujourd’hui les données de son entreprise sur des systèmes difficilement interopérables se fixe dès lors des limites pour l’utilisation de l’IA. C’est pourquoi un nouveau principe s’impose aux start-ups : l’infrastructure logicielle doit non seulement être « cloud-ready », mais aussi « AI-ready », c’est-à-dire compatible avec l’IA.

Ceux qui choisissent aujourd'hui leurs logiciels déterminent les possibilités de l'IA de demain

Imaginez une jeune entreprise. Les données clients sont stockées dans le CRM. Les factures et les paiements se trouvent dans le logiciel de comptabilité. Les devis et les commandes sont peut-être dans un ERP, les e-mails dans un autre système, et les contrats, présentations et documents de projet dans un cinquième système.

Pour les humains, cette distinction est déjà fastidieuse. Pour l'IA, elle devient une question d'architecture. Un assistant IA pourrait, par exemple, répondre à cette question :

Quelles sont les commandes en cours chez les clients avec lesquels nous avons eu des échanges par e-mail pertinents au cours des trois derniers mois et qui ont encore des factures impayées ?

Pour cela, le système doit pouvoir accéder au CRM, à la messagerie électronique, à la gestion des commandes et à la comptabilité. Si chacun de ces systèmes dispose d'une interface adaptée, cela est en principe réalisable. Lorsqu'un système essentiel est techniquement presque au point, ce sont justement les informations qui font toute la différence qui font défaut.

Cela signifie que la qualité d'une future solution d'IA ne dépend pas uniquement du modèle. Elle dépend également de la capacité de l'IA à accéder aux données pertinentes.

Le problème ne réside pas dans l'infrastructure sur site

Il serait trop simpliste de considérer les logiciels dans le cloud comme modernes et les logiciels sur site comme problématiques. Une application exploitée en local peut très bien s'intégrer. Ce qui est déterminant, c'est de savoir si elle dispose, par exemple, d'une API documentée ou d'autres interfaces contrôlables.

Quelques exemples :

  • Odoo peut être hébergé ou exploité sur une infrastructure propre. La documentation officielle décrit en détail les installations sur site.
  • ERPNext peut être hébergé en interne. Le framework Frappe sur lequel il repose fournit par défaut des interfaces REST pour les objets de données.
  • SAP continue de présenter SAP S/4HANA comme un ERP pouvant également fonctionner sur l'infrastructure de l'entreprise.

Le déploiement sur site n'est donc pas le véritable problème. C'est plutôt l'architecture fermée qui pose problème. La situation devient problématique lorsqu'une application fonctionne sur un serveur interne, mais n'offre ni interface utilisable ni accès contrôlé à ses données. Un système d'IA externe ne peut alors pas accéder à ces informations.

Cela peut même être voulu. Un système totalement isolé s'avère parfois judicieux pour des raisons de sécurité ou d'exploitation. Mais dans ce cas, il faut définir dès la phase d'architecture comment l'IA doit tout de même être mise en œuvre : via un middleware contrôlé, une interface interne ou un modèle d'IA exploité en local.

La question n'est donc pas « Cloud ou sur site ? ». Elle est la suivante : dans quelle mesure d'autres systèmes ont-ils accès à nos données et à nos fonctionnalités ?

L'API devient un critère d'achat

Une API, c'est-à-dire, pour simplifier, une interface standardisée entre des systèmes logiciels, a longtemps été un sujet réservé aux développeurs. Pour les fondateurs et fondatrices d'entreprise, elle constitue aujourd'hui un élément stratégique du logiciel.

HubSpot en est un bon exemple. Ses interfaces permettent notamment de connecter des contacts, des entreprises, des opportunités commerciales et des tickets. À cela s’ajoutent des webhooks pour des intégrations basées sur les événements et un serveur MCP grâce auquel les systèmes d’IA compatibles peuvent accéder à certaines parties du CRM. Cela ne signifie pas pour autant que HubSpot soit la solution adaptée à toutes les entreprises. Mais cela montre quelles sont les questions essentielles à se poser lors du choix d’un logiciel moderne.

Il ne s'agit pas seulement de se demander : « Le CRM peut-il gérer mes prospects ? », mais aussi : « Pourrai-je par la suite lire, relier et, le cas échéant, modifier mes données de manière automatisée et contrôlée ? »

CRM : les données clients ne doivent pas devenir une impasse

Pour de nombreuses entreprises, le CRM devrait devenir l'une des principales sources de données pour l'IA. Il contient des données clients, des opportunités commerciales, des activités, des notes et souvent l'historique complet d'une relation client. Un assistant IA pourrait par exemple, à partir de ces informations :

  • Préparer les entretiens de vente
  • Regrouper les historiques clients
  • Identifier les suivis
  • Préparer les offres
  • Analyser les opportunités commerciales
  • Relier les informations provenant d'autres systèmes aux données clients

Pour cela, le CRM doit rendre ses données accessibles. HubSpot offre de nombreuses possibilités d'intégration, tandis qu'Odoo relie le CRM et l'ERP tout en pouvant être exploité sur une infrastructure propre. Là encore, ce n'est pas le modèle d'hébergement qui est déterminant, mais l'ouverture du système.

ERP : c'est là que réside une grande partie de la réalité de l'entreprise

La question prend encore plus d'importance dans le cadre d'un progiciel de gestion intégré (ERP). Celui-ci regroupe les commandes, les produits, les stocks, les fournisseurs, les projets, les prestations, les factures et d'autres processus métier essentiels. À long terme, quiconque souhaite véritablement intégrer l'IA dans les processus d'entreprise ne pourra guère faire l'impasse sur ces données. Un système d'IA pourrait, par exemple, détecter :

  • quelles commandes sont en retard
  • pour quels clients les commandes sont bloquées
  • l'évolution du volume des commandes
  • quels sont les projets qui dépassent leur budget
  • quelles informations doivent être rassemblées pour prendre une décision commerciale

Odoo et ERPNext montrent que même les systèmes gérés en interne peuvent être compatibles avec les API. SAP démontre quant à lui que même les grands systèmes d'entreprise peuvent fonctionner sur site. Pour une start-up, SAP serait dans la plupart des cas surdimensionné, mais cela constitue néanmoins un bon exemple : le fonctionnement sur site et la capacité d'intégration ne sont pas incompatibles.

Comptabilité : les entreprises suisses devraient y regarder de plus près

En Suisse, bexio et Abacus sont très répandus. bexio met à disposition une API REST documentée permettant à des applications externes d'échanger des données avec le système. Abacus propose également des API REST et des services web. Il existe par ailleurs une version cloud, AbaWeb, tandis que les installations Abacus peuvent également fonctionner sur des serveurs propres à l'utilisateur.

Comme tu peux le constater, il ne suffit pas de demander au fabricant s'il s'agit d'une solution « cloud » ou « sur site ». Tu dois examiner la variante concrète du produit et ses interfaces. Il est également utile de se demander quelles données sont réellement disponibles via l'API. Le fait qu'une API existe ne signifie pas pour autant que toutes les fonctionnalités du logiciel y sont accessibles.

Le courrier électronique devient une source d'informations importante

Une part importante des connaissances de l'entreprise réside toujours dans les e-mails. Google met à disposition une API pour Gmail, grâce à laquelle des applications autorisées peuvent, entre autres, lire, organiser ou envoyer des messages. Chez Microsoft, outre les offres cloud, il existe toujours Exchange Server pour une utilisation au sein de l'entreprise. Microsoft qualifie expressément l'actuelle édition « Subscription » d'Exchange Server de solution de messagerie « sur site ».

Là encore, l'architecture joue un rôle essentiel. Si les e-mails doivent ultérieurement être intégrés à un système de connaissances basé sur l'IA, tu dois réfléchir dès le départ aux accès, aux autorisations et aux interfaces.

Les documents constituent souvent la plus grande base de données non structurée

Les offres, présentations, concepts, contrats, procès-verbaux, documentations techniques et directives internes renferment une grande partie du savoir-faire de l'entreprise. C'est précisément ce qui les rend si intéressants pour l'IA. Imagine que tes collaborateurs puissent poser les questions suivantes :

« Qu'avons-nous promis à ce client dans nos trois dernières offres ? »

ou :

« Quelles décisions ont été prises jusqu'à présent concernant ce projet ? »

Pour que cela fonctionne, l’IA doit pouvoir trouver les documents pertinents et, en fonction des autorisations de chaque utilisateur, les consulter. Là encore, il existe différentes architectures. Outre les grandes plateformes cloud, Nextcloud peut par exemple être exploité sur une infrastructure propre. Nextcloud décrit explicitement son offre comme pouvant être déployée sur site et prend en charge l’intégration de différents espaces de stockage externes.

Le véritable problème : le savoir-faire de l'entreprise est dispersé

Même si chaque système fonctionne bien pris isolément, la croissance engendre un autre problème : les connaissances se dispersent. Une partie se trouve dans le CRM, une autre dans les e-mails, une autre encore dans les documents, dans l'ERP et dans la comptabilité. Plus tard, s'y ajouteront peut-être des systèmes d'assistance, de gestion de projet, un entrepôt de données et des applications spécialisées.

Un utilisateur passe d'une application à l'autre. Un agent IA, en revanche, a besoin d'un accès techniquement contrôlé à chaque source d'information. C'est pourquoi tu dois dès le début considérer l'architecture logicielle comme un système cohérent.

L'objectif n'est pas de transférer toutes les données vers une seule et même application. L'objectif est de permettre aux systèmes de communiquer entre eux et d'éviter que les données ne finissent définitivement par disparaître dans des silos isolés.

Le MCP est intéressant, mais une bonne API est plus importante

Dans le domaine de l'IA, on entend souvent parler du « Model Context Protocol », ou MCP. Ce protocole permet de simplifier la connexion entre les systèmes d'IA et les applications externes. HubSpot propose déjà son propre serveur MCP, tandis que d'autres fournisseurs travaillent à la mise au point de solutions similaires.

Tu ne devrais toutefois pas faire du MCP le seul critère de décision lors du choix d’un logiciel. Les technologies évoluent. Une API bien documentée, un bon modèle d’autorisation et une architecture de données ouverte sont des éléments fondamentaux. Si tu disposes de ces bases, tu pourras également intégrer les futures technologies d’IA.

Méfiez-vous du « vendor lock-in »

Au moment de la création d'une entreprise, de nombreux choix logiciels semblent réversibles. Plus tard, ce n'est souvent plus le cas. Au bout de cinq ans, le CRM contient peut-être des dizaines de milliers de contacts, l'ERP des centaines de milliers d'écritures comptables, les systèmes de messagerie électronique des années de correspondance et une plateforme héberge d'énormes quantités de documents. À ce stade, changer de système revient cher.

C’est pourquoi toute décision importante en matière de logiciel doit s’accompagner de la question suivante : « Comment en sortir ? » Une bonne fonctionnalité d’exportation n’est pas la même chose qu’une bonne API, et les deux sont importantes. L’API permet une intégration et une automatisation continues. La fonctionnalité d’exportation garantit que vos données ne restent pas enfermées de manière permanente dans le système. Vérifiez dès le début si vous pouvez exporter vos données de manière complète, structurée et dans un format réutilisable.

Une API ne suffit pas à elle seule à rendre un logiciel compatible avec l'IA

La mention « API disponible » recèle également plus de nuances qu'elle ne le laisse entendre. Avant de prendre une décision, tu devrais au moins vérifier ces sept points :

  1. Quelles sont les données disponibles via l'interface ? Cela ne sert pas à grand-chose que l'API existe si les informations pertinentes font justement défaut.
  2. L'API est-elle en lecture seule ou permet-elle également l'écriture ? Pour les analyses, un accès en lecture suffit. Les agents chargés d'effectuer des tâches peuvent, dans certains cas, avoir besoin d'un accès en écriture contrôlé.
  3. Existe-t-il un système d'autorisation raisonnable ? Une IA ne devrait pas avoir automatiquement accès à toutes les données simplement parce qu'une interface existe d'un point de vue technique.
  4. La plateforme prend-elle en charge l'automatisation ? Les webhooks et autres mécanismes similaires permettent aux applications de réagir à des événements sans avoir à interroger en permanence toutes les données.
  5. Y a-t-il des limites ? Les API peuvent être soumises à différentes restrictions de volume selon le fournisseur, la licence et la formule tarifaire.
  6. L'interface est-elle documentée et régulièrement mise à jour ? Une interface peu documentée entraîne, dans la pratique, des coûts d'intégration élevés.
  7. Les données peuvent-elles être exportées dans leur intégralité ? Cette question est pertinente indépendamment de l'IA et permet de réduire la dépendance vis-à-vis du fournisseur.

Liste de contrôle pour les créateurs et créatrices d'entreprise

Avant de mettre en place un CRM, un ERP, un logiciel de comptabilité, un système de messagerie électronique ou de gestion de documents, je te conseille aujourd'hui de te poser au moins les questions suivantes :

  • Existe-t-il une API documentée et mise à jour régulièrement ?
  • Quelles sont les données importantes disponibles via cette API ?
  • Est-il possible de lire des données et, si nécessaire, d'en écrire ?
  • Existe-t-il des webhooks ou des possibilités d'automatisation similaires ?
  • Existe-t-il un système de rôles et d'autorisations permettant un contrôle précis ?
  • Les utilisateurs techniques ou les applications peuvent-ils disposer de leurs propres droits d'accès ?
  • Est-il possible d'exporter l'ensemble des données de l'entreprise, de les structurer et de les réutiliser ultérieurement ?
  • Quelles sont les restrictions applicables à l'API ?
  • L'accès à l'API dépend-il d'une licence spécifique ?
  • La solution peut-elle s'intégrer à des plateformes d'automatisation ou à des intergiciels ?
  • Existe-t-il déjà des intégrations avec les principales plateformes d'IA ?
  • Le fabricant prend-il en charge les normes ouvertes ?
  • Dans quelle mesure un changement ultérieur de système serait-il complexe ?
  • Peux-tu continuer à utiliser tes données indépendamment du fournisseur ?

Et pour finir, la question qui est au cœur du débat : un futur agent d'IA pourrait-il accéder de manière contrôlée aux informations que vous stockez actuellement dans ce système ? Si vous ne pouvez pas répondre à cette question, renseignez-vous avant l'achat.

La stratégie « cloud-first » ne suffit plus

Ces dernières années, de nombreuses start-ups ont adopté le principe du « cloud d’abord ». Cela se comprenait : les logiciels cloud réduisaient les coûts d’infrastructure, simplifiaient les mises à jour et permettaient aux jeunes entreprises de démarrer rapidement. Avec l’IA, les exigences changent à nouveau. Aujourd’hui, la question qu’il convient de se poser est la suivante : notre infrastructure est-elle prête pour l’IA ?

Cela ne signifie pas que chaque entreprise doive immédiatement développer des agents d'IA. Cela ne signifie pas non plus que chaque système doive être hébergé dans le cloud. Cela signifie qu'il faut tenir compte, dans les décisions prises aujourd'hui, de l'utilité future de ses propres données. Les données ne prennent pas de valeur simplement parce que vous les collectez. Leur valeur naît lorsqu'elles sont faciles à trouver, interconnectables et accessibles aux applications appropriées.

Le choix d'un logiciel devient un choix en matière de données

Il est tentant de choisir un logiciel en fonction de ce qui semble aujourd'hui le plus simple ou le moins cher. Or, une telle décision peut avoir des répercussions pendant dix ans. Pour les systèmes d'entreprise centraux, il ne suffit donc pas de se limiter à la question des fonctionnalités actuelles. Il est tout aussi important de se demander : que pourrons-nous faire demain avec les données qui y sont stockées ?

En résumé : les entreprises dont les systèmes CRM, ERP, de comptabilité, de messagerie électronique et d'archivage de documents peuvent être interconnectés de manière contrôlée ne disposent pas seulement d'une bonne infrastructure informatique. Elles posent les bases nécessaires pour que les futurs systèmes d'IA puissent véritablement fonctionner en s'appuyant sur les connaissances et les processus de l'entreprise.

Quels logiciels utilises-tu aujourd'hui, et sais-tu si une IA pourrait accéder à leurs données demain ? Raconte-moi ton expérience, je suis curieux de savoir où vous avez déjà rencontré des systèmes fermés.

Remarque concernant la protection des données : swissAI aborde séparément , dans l'article « Utiliser l'IA en toute sécurité sans en limiter inutilement les possibilités », les données d'entreprise et les données à caractère personnel que vous êtes autorisé à transmettre à des systèmes d'IA externes , ainsi que les exigences applicables en la matière .