Les sept questions qui révèlent si l'IA est vraiment intégrée

La plupart des acheteurs évaluent aujourd'hui l'IA comme ils évaluent une fonction : ils la regardent marcher une fois. C'est exactement le mauvais test, car une démonstration est le seul environnement où un assistant greffé après coup se comporte bien. La question est choisie, les données sont propres, et tout reste à l'intérieur d'un seul produit.

Les défaillances arrivent plus tard, et elles sont structurelles plutôt qu'une question de qualité du modèle. Les modèles de frontière sont excellents. Ce qui distingue les plateformes, c'est ce que le modèle a le droit de voir, ce qu'il a le droit de faire, et ce qui se passe lorsqu'il se trompe.

1. Peut-elle répondre à une question qui traverse deux modules, sans intégration ?

Demandez une question qui couvre deux parties de l'entreprise à la fois. « Quels clients sont à risque ce trimestre, et pourquoi ? » convient bien, car une vraie réponse a besoin du pipeline commercial, de l'historique du support, de l'état des livraisons et des factures.

Une bonne réponse, c'est une requête unique sur un modèle de données unique, et l'éditeur sait décrire la forme de cette requête.

Une mauvaise réponse contient le mot « intégration », ou bien la démonstration rétrécit la question sans le dire : vous avez interrogé le risque sur toute l'entreprise et vous obtenez une réponse tirée du seul pipeline. Ce rétrécissement est le signal. Il veut dire que l'assistant ne voit qu'un silo, et que les parties qu'il ne voit pas sont précisément celles qui auraient changé la réponse.

2. Chaque enregistrement a-t-il une représentation conçue pour un modèle, et non pour une base de données ?

Une IA posée sur des lignes de table brutes doit déduire le sens à partir du nom des colonnes. Cela marche jusqu'à ce que deux tables emploient status pour dire des choses différentes.

Une bonne réponse, c'est que chaque entité se sérialise en une vue déterministe et consciente du schéma, construite spécifiquement pour être consommée par un modèle, y compris le contexte lié qu'un humain jugerait évident. Chez Cyril, c'est le sérialiseur ai_context, et il est obligatoire sur chaque entité au lieu d'être ajouté là où quelqu'un y a pensé.

Une mauvaise réponse, c'est « nous transmettons l'enregistrement au modèle » ou « nous faisons de la recherche documentaire sur vos données ». La recherche documentaire est un bon complément et un mauvais substitut : elle répond à ce qui a été écrit, pas à ce qui est vrai maintenant.

3. Y a-t-il un seul modèle de permissions, et l'IA en hérite-t-elle ?

C'est la question qui décide si l'IA pourra un jour être activée pour toute l'entreprise plutôt que pour un groupe pilote.

Une bonne réponse, c'est que l'IA s'exécute en tant qu'utilisateur, sous son rôle et ses permissions au niveau de l'enregistrement, et ne peut rien voir que cet utilisateur ne pourrait ouvrir lui-même.

Une mauvaise réponse, c'est un compte de service distinct avec un large accès en lecture et la promesse que l'invite lui dit de bien se tenir. Les instructions d'une invite ne sont pas un mécanisme de contrôle d'accès. Si la seule chose qui sépare un agent de support de la table de paie est une phrase dans une invite système, le modèle n'a pas besoin d'être malveillant pour que cela échoue : il lui suffit de vouloir aider.

4. Y a-t-il un seul journal d'audit, et l'IA y figure-t-elle ?

Demandez à voir la piste d'audit après l'action de la démonstration, et regardez où l'action de l'IA a été consignée.

Une bonne réponse, c'est qu'elle apparaît dans le même journal que les actions humaines, l'acteur étant identifié comme l'IA agissant pour le compte d'un utilisateur nommé, exactement comme n'importe quelle autre écriture.

Une mauvaise réponse, c'est un écran séparé d'« activité IA ». Deux journaux signifient que personne ne peut reconstituer ce qui est arrivé à une donnée sans les croiser, et au moment où l'on en a le plus besoin — un client qui conteste une modification, un auditeur qui demande qui a approuvé quoi — réconcilier deux systèmes par horodatage est précisément la façon dont les faits se perdent.

5. Une action de l'IA peut-elle être annulée ?

Mal répondre à une question coûte une minute. Mal exécuter une action envoie le courriel, déplace l'affaire, crédite la facture.

Une bonne réponse décrit une voie de retour arrière qui est une propriété de la plateforme et non de la fonction IA : suppressions logiques, enregistrements versionnés, écritures transactionnelles en plusieurs étapes — le mécanisme même qui permet d'annuler une erreur humaine.

Une mauvaise réponse, c'est « l'utilisateur approuve chaque étape ». L'approbation est un bon contrôle et n'est pas un mécanisme de récupération. Les gens approuvent. La question est de savoir ce qui se passe le jour où quelqu'un approuve la mauvaise chose.

6. Quelque chose d'extérieur au produit peut-il le piloter ?

Le vrai test de la disponibilité réelle des capacités d'une plateforme pour l'IA, c'est de savoir si un agent que l'éditeur n'a pas écrit peut les appeler.

Une bonne réponse, c'est une surface d'outils documentée — un serveur MCP ou équivalent — où les actions offertes à un agent externe sont celles-là mêmes que le produit exécute en interne, sous les mêmes permissions.

Une mauvaise réponse, c'est une API REST et un haussement d'épaules. Une API est nécessaire et ce n'est pas la même chose : elle expose des points de terminaison qu'un développeur assemble, pas des capacités entre lesquelles un agent peut choisir.

7. Pouvez-vous changer de fournisseur de modèle sans changer de produit ?

Une bonne réponse, c'est une couche d'abstraction des modèles, le fournisseur actuel étant cité comme valeur par défaut et non comme élément d'architecture, avec un routage décidé par tâche.

Une mauvaise réponse, c'est un éditeur dont l'histoire sur l'IA et le fournisseur de modèles ne font qu'une. La capacité et le prix des modèles ont bougé fortement tous les quelques mois pendant trois ans. Une plateforme qu'il faut réécrire pour en profiter n'en profitera pas.

Comment noter

Sept questions, trois issues.

• Cinq bonnes réponses ou plus. L'IA est dans les fondations. Ce qu'elle ne fait pas encore est un problème de feuille de route, c'est-à-dire un problème normal.
• De deux à quatre. Un produit capable avec un assistant accroché dessus. Il fera des choses utiles à l'intérieur d'un silo. N'y bâtissez pas un flux qui traverse l'entreprise.
• Moins de deux. Vous achetez une fenêtre de conversation. Cela peut encore valoir la peine ; payez-la à ce prix-là.

Notez qu'aucune des sept ne porte sur la qualité des réponses. Cette qualité suit la frontière du secteur et s'améliore seule. L'architecture, non : personne ne rétro-adapte un modèle de données unique à un produit assemblé à partir de cinq acquisitions, parce que cette migration coûte plus que ce que le produit rapporte. C'est pourquoi ce sont là les questions durables, et pas « à quel point est-elle intelligente ».

Le bilan de Cyril, honnêtement

Il serait facile de publier un examen sans le passer.

Cyril répond solidement aux questions 1, 2, 3, 4, 6 et 7 : un graphe unique couvrant les ventes, les projets, le support, les documents et les finances ; un sérialiseur ai_context obligatoire sur chaque entité ; une IA qui s'exécute avec les permissions de l'appelant à travers un point de contrôle unique et gouverné ; un seul journal d'audit ; un serveur MCP qui expose les outils de la plateforme à des agents externes ; et une couche d'abstraction des modèles sans fournisseur figé dans le code.

Sur la question 5 — le retour arrière — les primitives sont là et chaque module s'en sert : suppressions logiques, écritures transactionnelles en plusieurs étapes et un enregistrement d'audit pour chaque mutation. Ce qui reste à finir, c'est d'annuler une action d'IA en plusieurs étapes comme une seule unité plutôt qu'étape par étape.

Deux réserves que l'examen ne couvre pas, dites clairement : Cyril est en phase de pré-lancement, et son mode Agentique pleinement autonome est à venir et non livré. Ce qui existe aujourd'hui, c'est la plateforme et un assistant IA qui travaille à vos côtés et montre son plan avant d'agir. Lorsque vous poserez ces sept questions à n'importe quel éditeur — celui-ci compris — exigez la même distinction entre ce qui existe et ce qui est prévu.

Questions fréquentes

« Native IA » n'est-il qu'un terme de marketing ?

Tel qu'on l'emploie couramment, le plus souvent oui. Tel qu'il est défini ici — l'IA lisant et écrivant à travers le même modèle de données, le même modèle de permissions et le même journal d'audit que les humains — c'est une propriété structurelle qu'on peut exiger d'un éditeur en une seule démonstration.

Une plateforme peut-elle devenir native IA plus tard ?

La couche IA peut s'améliorer à tout moment. Le modèle de données unique en dessous, en pratique, ne se rétro-adapte pas : il faut refonder le produit sur un seul schéma, un seul modèle de permissions et un seul journal d'audit, ce qui est une réécriture et non une version.

Est-ce que cela concerne les petites entreprises ou seulement les grands comptes ?

Cela concerne davantage les petites équipes. Une grande entreprise peut payer des gens pour réconcilier cinq systèmes. Une équipe de quarante ne le peut pas : la qualité des questions qu'elle peut poser à ses propres données dépend donc presque entièrement du fait que ces données partagent un même graphe.

Quelle est la question la plus rapide à poser ?

La quatrième. Demandez à voir le journal d'audit juste après que l'IA a fait quelque chose. Cela prend dix secondes, c'est difficile à préparer de façon convaincante, et la réponse vous dit à quel point l'éditeur a pris au sérieux toutes les autres questions de cette liste.

---

Si vous voulez être parmi les premiers à utiliser Cyril, inscrivez-vous sur la liste d'attente.