Intelligence artificielle

Brancher l’IA sur ce que vous avez déjà

Ces projets échouent sur le branchement, pas sur le modèle. Ce qu’il faut inventorier avant de signer, et où placer la couture.

Publié le 24 juillet 2026 — Algeria Agency

La démonstration fonctionne toujours. Elle fonctionne parce qu’elle ne traverse aucun de vos systèmes : les données y sont propres, disponibles et déjà au bon format, ce qui décrit exactement la situation dans laquelle vous n’êtes pas.

Chez vous, les données utiles sont dans une caisse qui n’expose rien, dans un fichier que quelqu’un exporte le lundi, et dans un logiciel dont l’éditeur ne répond plus. C’est là que ces projets meurent, et c’est connaissable avant d’engager le moindre dinar.

Cet article décrit l’inventaire qui permet de le savoir, ce qu’on fait quand un système est fermé, et où placer la couture pour que le fournisseur d’IA reste remplaçable — parce qu’il changera de prix, de catalogue ou de disponibilité pendant la vie de votre projet.

Le modèle n’est jamais le problème

Il vaut la peine de dire clairement où va le temps dans ces projets. Le choix du modèle occupe une journée et se révise en une heure ; la question « comment obtenir cette liste de clients à jour » occupe des semaines et se révise en refaisant tout.

La raison est que les modèles sont devenus interchangeables pour la grande majorité des usages d’entreprise, pendant que les systèmes de gestion sont restés aussi hétérogènes qu’avant. Deux boutiques du même métier ont le même besoin et deux installations sans rien de commun.

La conséquence est un ordre de travail inhabituel : on regarde les systèmes d’abord et le modèle en dernier. Un prestataire qui commence par vous parler du modèle qu’il a choisi vous parle de la partie du projet qui pose le moins de problèmes.

Il y a une manière rapide de vérifier cette affirmation sur votre propre projet. Demandez au prestataire combien de jours il consacre au choix du modèle et combien à l’accès aux données, et comparez les deux nombres à ce que vous venez de lire. Un devis où la seconde ligne est plus courte que la première décrit un projet qui n’a pas encore regardé vos systèmes.

L’inventaire avant le devis

L’inventaire répond à quatre questions par système : qu’est-ce qui en sort, par quel moyen, à quelle fréquence, et dans quel état sont les données. Il ne demande pas d’accès privilégié, il demande une demi-journée avec la personne qui utilise le système tous les jours.

Il produit un document court et froid : ce qui est branchable, ce qui ne l’est qu’au prix d’un export périodique, et ce qui ne l’est pas du tout. Cette page-là décide du projet, et elle décide parfois qu’il n’y en aura pas.

Nous facturons cette étape seule et le document vous reste, y compris si vous vous arrêtez là ou si vous partez chez quelqu’un d’autre avec. C’est délibéré : un inventaire dont le résultat est « non » a autant de valeur qu’un inventaire qui ouvre un chantier, et il doit pouvoir être rendu sans que le prestataire y perde.

L’inventaire pose aussi une question que les projets sautent systématiquement : qui a le droit d’accorder l’accès. Dans beaucoup d’entreprises, le mot de passe administrateur du logiciel de gestion appartient à une personne qui n’est ni dans la réunion ni au courant du projet, et parfois à un prestataire externe joignable difficilement. Repérer cela au début coûte une question ; le découvrir en cours de route coûte plusieurs semaines.

Ce qui sort d’un logiciel, et comment

Il y a trois cas et ils n’ont pas le même coût. Le premier : le logiciel expose une interface de programmation documentée. C’est le cas confortable, la donnée est disponible à la demande et à jour, et l’intégration se construit contre un contrat stable.

Le deuxième : le logiciel n’expose rien mais sait exporter — un fichier, une sauvegarde, un état imprimable. La donnée est alors disponible avec un retard égal à la fréquence de l’export, et il faut décider si ce retard est acceptable pour l’usage. Pour un assistant qui répond sur les stocks, un export quotidien est souvent inacceptable ; pour un tableau de bord mensuel, il est parfait.

Le troisième : le logiciel ne fait ni l’un ni l’autre. C’est le cas où il faut arrêter et poser la question autrement, parce que les solutions de contournement disponibles à ce stade sont toutes mauvaises et le sont durablement.

Le deuxième cas mérite une nuance qui change souvent la décision : la fréquence d’export n’est pas toujours celle que le logiciel propose. Beaucoup d’applications qui exportent une fois par jour peuvent exporter à la demande si quelqu’un lance la commande, et une tâche planifiée fait le reste. L’écart entre « une fois par jour » et « toutes les heures » suffit à rendre acceptable un usage qui semblait exclu.

La caisse qui n’expose rien

Une partie du parc installé localement est constituée d’applications de bureau plus anciennes, parfois sans documentation, parfois sans éditeur encore joignable. Ce n’est pas une critique : ces logiciels font le travail pour lequel ils ont été achetés, et ils le font depuis dix ans sans incident.

Ce sont simplement des systèmes conçus avant qu’on attende d’un logiciel qu’il parle à d’autres logiciels. Ils enregistrent correctement, ils impriment correctement, et ils n’ont jamais eu de raison d’exposer quoi que ce soit vers l’extérieur.

Nous n’avons pas de chiffre à citer sur la proportion que cela représente en Algérie. Nous constatons le cas régulièrement, il n’existe à notre connaissance aucun relevé daté du parc installé ici, et une statistique importée d’un autre marché décrirait un parc différent — nous préférons décrire ce que nous voyons et le présenter comme tel plutôt que d’habiller une impression en pourcentage.

Ce cas a une issue qu’il ne faut pas écarter trop vite : demander à l’éditeur. Quand il existe encore, il dispose parfois d’un module d’export ou d’une interface non documentée qu’il fournit sur demande, et le coût d’une lettre est nul comparé à celui d’un contournement. Cette démarche est rarement tentée parce qu’elle est lente ; elle est aussi la seule qui laisse le système sous garantie.

La couche que vous possédez

La décision d’architecture qui compte tient en une phrase : le modèle est appelé derrière une interface qui vous appartient, jamais directement depuis votre application. C’est un seul endroit dans le code où l’on décide quel fournisseur répond.

Le coût de cette précaution au moment de la conception est proche de zéro — quelques heures — et son coût si on l’ajoute après est celui d’une réécriture. C’est le genre de décision qu’on ne prend qu’au début et qu’on regrette exactement une fois.

Elle paraît théorique jusqu’au premier événement réel : un fournisseur qui multiplie ses tarifs, retire un modèle du catalogue avec un préavis court, ou devient inaccessible depuis l’Algérie. Aucun de ces trois n’est hypothétique et aucun ne se prévoit.

La couche a un second bénéfice qu’on ne mesure qu’après : elle rend le coût visible. Comme tous les appels passent par un seul endroit, on peut compter combien il y en a, lesquels sont chers, et lesquels sont inutiles. Sans elle, la facture arrive globale et personne ne sait quelle partie de l’application l’a produite, ce qui rend toute optimisation impossible à cibler.

Le fournisseur derrière

Il faut aussi que le remplacement soit vérifié, pas seulement possible. Un prestataire qui affirme que le fournisseur est interchangeable devrait le démontrer pendant le projet : basculer vers un autre modèle, faire tourner le jeu de tests, et vous montrer le résultat.

Ce test dure une demi-journée et il transforme une promesse d’architecture en fait constaté. S’il est refusé ou repoussé à plus tard, l’abstraction existe probablement sur le papier et pas dans le code.

Il y a une variante de ce test qui coûte encore moins et qui se demande en réunion : faire nommer le fichier ou le module où le choix du fournisseur est écrit. Si la réponse est un endroit précis, l’abstraction existe. Si la réponse commence par « ça dépend », le nom du fournisseur est probablement dispersé dans le code, et le remplacement annoncé comme simple sera un chantier.

Ce qui se passe quand il ne répond pas

Une interface distante ne répond pas toujours. Cela arrive pour des raisons banales — maintenance, saturation, limite de débit atteinte — et la question n’est pas comment l’éviter mais ce que fait votre système pendant ce temps.

Il y a trois comportements acceptables et il faut en choisir un explicitement : mettre en file d’attente et traiter plus tard, dégrader en annonçant la dégradation, ou s’arrêter proprement en le disant. Le comportement inacceptable est celui qu’on obtient par défaut : une page d’erreur technique devant un client, ou pire, un silence qui ressemble à une réponse.

Ce choix se fait au cadrage et prend dix minutes. Il est presque toujours omis, parce qu’il porte sur un événement qui n’a pas encore eu lieu et que rien dans une démonstration ne le rend visible.

Le cas le plus insidieux n’est pas l’absence de réponse mais la réponse lente. Une interface qui répond en trente secondes au lieu d’une n’est pas en panne, donc rien ne se déclenche, et pourtant l’application devient inutilisable pour l’utilisateur qui attend. Un délai maximal au-delà duquel on abandonne l’appel doit être fixé explicitement, sinon c’est l’utilisateur qui l’applique en fermant la page.

Ce qui sort du pays, champ par champ

Envoyer une requête à un service étranger, c’est envoyer des données. Lesquelles exactement est une question à traiter champ par champ, pas globalement, parce que la réponse n’est presque jamais « toutes ».

Pour classer un message entrant, le modèle a besoin du texte du message. Il n’a pas besoin du numéro de téléphone, du nom, de l’adresse ni de l’historique d’achat, et les envoyer parce qu’ils étaient dans le même enregistrement est une négligence courante et évitable.

La bonne pratique est une liste explicite des champs transmis, validée par vous, et un mécanisme qui refuse tout ce qui n’y figure pas. Ce qui est exclu est alors traité par des règles locales ou pas traité, et cette décision vous appartient plutôt que d’être la conséquence d’un choix technique que personne ne vous a présenté.

Il existe une technique simple et sous-employée : remplacer avant l’envoi. Un numéro de commande devient un identifiant interne, un nom devient un jeton, et la correspondance reste chez vous. Le modèle travaille sur un texte qui a le même sens et aucune donnée nominative, et la réponse est remise en forme au retour. Ce n’est pas toujours possible, et quand ce l’est cela règle la question sans rien retirer au service.

L’environnement de test

Il faut un endroit où vérifier une modification avant qu’elle touche la production, avec des données qui ressemblent aux vôtres. Sans cela, chaque évolution est un pari fait sur un système vivant, et les paris se perdent le jour où il y a du monde.

C’est la première chose coupée quand le budget se tend, et la coupe se paie plus tard avec intérêts. Une copie de test coûte peu à mettre en place au début du projet et devient impossible à rajouter une fois que l’intégration est en production et que personne ne veut y toucher.

Une nuance sur les données de test : elles doivent ressembler aux vôtres sans être les vôtres. Copier la base de production dans un environnement moins protégé est une pratique courante et une mauvaise idée, parce que l’environnement de test finit toujours par être accessible à plus de monde. Un jeu de données dérivé, où les noms et les numéros ont été remplacés mais où les cas tordus sont conservés, donne les mêmes bugs sans le risque.

Le prototype sur le chemin le plus difficile

Quand un prototype est demandé, il doit porter sur la partie la plus risquée, pas sur la plus démontrable. Un prototype qui prouve que le modèle sait résumer un texte ne prouve rien : c’était acquis. Un prototype qui va chercher une donnée dans votre caisse prouve la seule chose incertaine.

C’est un principe simple et il est systématiquement inversé, parce qu’un prototype facile fait une meilleure réunion. Il fait aussi un moins bon projet, et l’écart apparaît au moment où le budget est engagé.

Un prototype a aussi une date de péremption qu’il faut annoncer. Il est écrit pour prouver un point, pas pour durer, et le réutiliser comme base de production est la façon la plus courante de transformer une bonne étape en dette. Le dire au moment de le livrer évite la conversation pénible où quelqu’un demande pourquoi il faut reconstruire une chose qui marche déjà.

Ce qui cassera, écrit à l’avance

Une intégration est un contrat avec un logiciel qui ne l’a pas signé. Le système d’en face changera de version, renommera un champ, modifiera un format de date, et il le fera sans vous prévenir parce qu’il ne sait pas que vous existez.

Donc la documentation ne décrit pas seulement ce qui a été construit, elle décrit ce qui le cassera : les dépendances externes, les versions supposées, les formats attendus, et le symptôme que chaque rupture produira. C’est la partie qui rend l’intégration réparable par quelqu’un d’autre.

Cette page est aussi le test le plus simple de la qualité d’un prestataire. Demandez-la avant la fin du projet. Si elle n’existe pas, ce n’est pas qu’elle n’a pas encore été écrite : c’est que personne ne s’est posé la question.

La documentation a un lecteur précis qu’il faut avoir en tête : la personne qui ouvrira le dossier dans dix-huit mois, en urgence, sans vous. Ce lecteur n’a pas besoin de savoir pourquoi telle bibliothèque a été choisie ; il a besoin de savoir ce qui se passe quand le fichier attendu n’arrive pas, où regarder, et qui appeler. Écrire pour lui produit un document plus court et beaucoup plus utile que la documentation d’architecture habituelle.

Ce que nous faisons, et ce que nous ne toucherons pas

Nous faisons l’inventaire, nous prototypons le chemin le plus difficile, nous construisons derrière une couche qui vous appartient, et nous remettons le code, les accès et la documentation sur vos comptes pendant le projet plutôt qu’à la fin. Vous n’avez jamais à nous demander l’autorisation de travailler avec quelqu’un d’autre.

Nous ne chiffrons pas l’intégration avant l’inventaire, et nous refusons de le faire même quand on nous le demande avec insistance. Un prix donné avant de savoir ce que vos systèmes exposent n’est pas une estimation, c’est un pari dont vous portez le risque : soit il est gonflé pour couvrir l’inconnu, soit il est juste et sera dépassé, et dans les deux cas vous avez payé notre incertitude. L’inventaire coûte quelques jours, il est facturé seul, et il transforme la question en question chiffrable.

Il y a aussi une chose que nous ne ferons pas, même quand c’est techniquement possible et que le client la demande : lire directement la base de données d’un logiciel qui n’a pas prévu qu’on la lise. On peut souvent le faire, cela marche pendant quelques mois, et cela casse à la première mise à jour de l’éditeur — un jour que nous ne choisissons pas, sur lequel nous n’avons aucune information, et où nous ne serons peut-être plus là. Le client hérite alors d’un système en panne dont personne ne comprend la cause. Quand un logiciel n’expose rien, nous proposons un export périodique en acceptant son retard, ou nous disons que le projet ne se fait pas.

Une dernière chose, plus banale et plus fréquente que tout ce qui précède : nous ne conservons pas vos identifiants après la fin du projet. Ils sont créés à votre nom, ils vous sont remis, et ils sont révoqués à la livraison. C’est une hygiène élémentaire et elle est rarement appliquée, parce que garder l’accès rend le support plus commode pour le prestataire. Si vous nous rappelez, vous nous rouvrirez l’accès, et cette friction est voulue.

Questions fréquentes

Et si notre logiciel n’a aucune interface de programmation ?

Nous regardons ce qu’il exporte et à quelle fréquence, et nous vous disons si ce retard est compatible avec l’usage. Parfois oui, parfois non, et l’inventaire tranche.

Pouvons-nous changer de fournisseur d’IA plus tard ?

Oui, c’est l’objet de la couche d’abstraction. Demandez que la bascule soit testée pendant le projet plutôt que promise pour plus tard.

Nos données partent-elles à l’étranger ?

Seulement les champs nécessaires, listés un par un et validés par vous. Ce que vous excluez est traité localement ou pas du tout.

Qui maintient l’intégration après la livraison ?

Vous, votre équipe ou nous, selon votre choix. La documentation est écrite pour que la troisième option reste une option et pas une obligation.

Faut-il tout refaire si nous changeons de CRM ?

La partie modèle non, la partie branchement oui. C’est précisément pourquoi les deux sont séparées dans ce que nous livrons.

Combien de temps dure un projet type ?

L’inventaire prend quelques jours. La suite dépend entièrement de ce qu’il trouve, et nous ne la chiffrons pas avant de l’avoir.

Où nous intervenons

Pour chacun de vos systèmes, savoir qui l’a installé et si son éditeur répond encore décide de tout. La deuxième réponse est souvent non.

Nous établissons l’inventaire avant d’avancer le moindre montant.
Nous construisons d’abord le raccordement qui a le plus de chances d’échouer.
Nous rendons vos exports à la fin et nous n’en gardons pas de copie.

Tant que l’inventaire n’est pas fait, aucun chiffre ne sortira de chez nous, même si vous insistez : une estimation à l’aveugle se trompe d’un facteur, pas d’un pourcentage.

Commencer par l’audit gratuit Voir la page Intégrations IA sur mesure

À voir aussi

Parlons de votre projet

Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.

Demander l’audit gratuit Nous écrire