Services / Comment nous travaillons

Comment fonctionnent les services d'IA

De la définition du problème à l’intégration, à l’accompagnement et à l’amélioration à long terme.

Un projet d’IA sur mesure ne doit pas commencer par une demande de fonctionnalité au hasard ou par un modèle générique de chatbot. Il doit commencer par la situation réelle : le processus de travail, les utilisateurs, les données, les systèmes, les contraintes, les risques et le résultat attendu par le client.

inAi Services suit une démarche pragmatique : comprendre le problème, définir le périmètre, concevoir le système, construire et évaluer la solution, l’intégrer dans le bon environnement et l’accompagner après la livraison lorsque cela est convenu. La forme exacte dépend du projet, mais le principe reste le même : le client doit savoir ce qui est construit, ce qui est inclus, quelles informations sont nécessaires, ce qui reste privé, comment la solution sera exploitée et ce qui se passe après le lancement.

Démarrer une conversation sur les services Découvrir les services d’IA

Les projets d’IA exigent plus qu’un appel à un modèle.

De nombreux projets d’IA échouent parce que leur première version est traitée comme la solution complète. Un chatbot est construit avant le nettoyage de la base de connaissances. Un prototype est montré avant que les critères de réussite soient définis. Un processus de travail est automatisé avant que ses exceptions soient comprises. Un modèle est relié à des données qui n’ont pas été structurées, vérifiées ou délimitées.

Les systèmes d’IA utiles demandent généralement un travail produit et logiciel classique autour de la couche IA : préparation des données, expérience utilisateur, contrôle d’accès, intégration, journalisation, évaluation, gestion des erreurs, points de vérification, déploiement, maîtrise des coûts et accompagnement. Le modèle compte, mais c’est souvent le système qui l’entoure qui détermine si le résultat est utile en pratique.

C’est pourquoi inAi traite les services comme un travail de mise en œuvre, et non comme du simple conseil. L’objectif n’est pas de recommander l’IA en théorie, mais de définir, construire, intégrer et accompagner un système capable de fonctionner dans le contexte réel du client.

Commencer par le problème, pas par l’architecture.

Un client n’a pas besoin d’arriver avec une spécification technique complète. Dans de nombreux cas, la première étape utile consiste à décrire clairement le problème : ce qui est lent, manuel, coûteux, déroutant, répétitif, risqué, difficile à faire évoluer ou bloqué par les outils existants.

Le premier échange sert à comprendre la situation et à déterminer si les services IA sont la bonne voie. Certains problèmes correspondent à un produit inAi existant ; d’autres demandent un petit prototype ; d’autres encore une phase de découverte plus approfondie avant qu’un développement soit réaliste. Certains ne sont pas de bons problèmes d’IA, ou exigent d’abord du logiciel conventionnel, un nettoyage des données, une refonte des processus ou une vérification juridique ou de sécurité spécialisée.

Un bon projet de services commence lorsque le problème, le contexte et le résultat souhaité sont suffisamment concrets pour définir une étape suivante.

Découverte : comprendre la situation réelle.

La découverte est la phase dans laquelle inAi et le client rendent le problème suffisamment précis pour pouvoir le résoudre. Elle peut comprendre l’examen du processus actuel, l’identification des futurs utilisateurs, des données ou documents concernés, la cartographie des outils ou plateformes à connecter et la clarification de ce que le client attend du système d’IA.

Pour une intégration produit, la découverte peut porter sur le parcours produit existant, l’expérience utilisateur, les API, le modèle de données et les endroits où l’IA doit — ou ne doit pas — intervenir. Pour un assistant de connaissances interne, elle peut porter sur les sources documentaires, les limites d’accès, la fréquence des mises à jour, les références aux sources et la qualité des réponses. Pour une couche d’analyse de données, elle peut porter sur l’état des données, les schémas, les tableaux de bord, les exportations, les besoins de reporting et les décisions que l’analyse doit éclairer. Pour un processus agentique, elle peut porter sur les étapes, les outils, les autorisations, les points de vérification, les parcours de reprise et les modes de défaillance.

La découverte ne doit pas aboutir à un vague enthousiasme pour l’IA, mais à une définition plus claire du travail : quel problème est traité, quels éléments ou systèmes sont concernés, quelles contraintes comptent, à quoi ressemble la réussite et quelle doit être l’étape suivante.

La découverte peut clarifier

le processus de travail actuel et les personnes concernées ;

les données, documents, outils, API ou systèmes requis ;

ce qui doit être automatisé, assisté, vérifié ou laissé manuel ;

ce que signifie la qualité des résultats dans ce contexte spécifique ;

quelles autorisations, validations ou étapes de vérification humaine sont nécessaires ;

ce qui ne peut être promis tant que les données ou les systèmes n'ont pas été examinés ;

si la prochaine étape doit être un audit, un prototype, un projet à périmètre fixe, une intégration ou une relation d’accompagnement à plus long terme.

Le périmètre précède le développement.

Après la découverte, le projet doit être traduit en périmètre convenu avant le début du développement. Ce périmètre protège les deux parties : il indique au client ce qu’inAi construit, ce qui est inclus ou non, quels accès ou éléments sont nécessaires, comment le travail sera évalué et quel accompagnement ou transfert est attendu.

Un projet d’IA peut évoluer lorsque des données, documents, utilisateurs ou cas limites réels sont examinés ; c’est normal. L’essentiel est de traiter ces changements explicitement. Si le projet s’étend à de nouvelles fonctionnalités, sources de données, intégrations, à une échelle plus grande, à une infrastructure différente ou à un processus plus large que celui prévu, il s’agit d’un changement de périmètre et non d’un ajout silencieusement absorbé dans la première proposition.

C’est ainsi que le travail sur mesure reste sain. Le client obtient de la clarté. inAi obtient les conditions nécessaires pour livrer correctement. Les deux parties peuvent séparer les corrections dans le cadre convenu des nouveaux travaux qui doivent être planifiés, tarifés et programmés séparément.

La portée doit définir

le problème à résoudre ;

les livrables attendus ;

ce qui est inclus et exclu ;

les données, documents, comptes, API ou systèmes requis ;

les points d'intégration attendus ;

les critères d'évaluation ou d'acceptation;

le format de livraison ;

le modèle d’accompagnement ou de transfert ;

le modèle de tarification et les facteurs de coûts connus ;

ce qui compte comme correction et ce qui compte comme nouveau travail.

Confidentiel par défaut.

Le travail du client est confidentiel par défaut. Les projets de services peuvent impliquer des documents privés, des plans de produits, des processus opérationnels, des données commerciales, des outils internes, des utilisateurs, des ensembles de données, des documents sources ou des idées de produits inédites. inAi ne traite pas ces éléments comme une preuve publique.

Nous ne publions pas les noms de clients, détails de projet, captures d’écran, résultats, livrables, témoignages, jeux de données, documents ou études de cas, sauf accord du client. Certains clients pourront ultérieurement choisir de devenir des références publiques ou des études de cas. C’est facultatif : la règle par défaut est la confidentialité.

La confidentialité signifie aussi que les exemples publics figurant sur la page Services sont des scénarios, non des affirmations sur des clients précis. Un processus de traitement de documents, un assistant interne, une couche d’analyse de données assistée par l’IA, une intégration produit, un prototype ou un processus agentique peuvent être décrits comme des types de projet possibles sans révéler avec qui inAi travaille ni ce qui a été réalisé pour ces clients.

Clair avec le client. Privé pour tous les autres.

La confidentialité ne signifie pas que le projet ne doit pas être clair pour le client. Le client doit comprendre ce qui est construit, quelles données ou quels systèmes sont utilisés, comment la solution est censée fonctionner, où se situent les limites importantes, quels coûts peuvent apparaître et ce qui se passe après la livraison.

Un projet de services doit être transparent dans la relation avec le client et privé en dehors de celle-ci. inAi peut expliquer les compromis, les limites, les choix d’infrastructure, les considérations liées au modèle ou à l’API, les besoins d’accompagnement et les hypothèses opérationnelles sans transformer le projet en étude de cas publique.

La propriété et le transfert sont convenus avant le début des travaux.

La propriété doit être définie projet par projet. Un travail d’IA sur mesure peut associer plusieurs couches : données client, contexte métier confidentiel, documents, processus de travail, instructions, code applicatif, intégrations, expérience utilisateur, scripts de déploiement, configuration de modèle ou d’API, documentation, composants réutilisables, ainsi que méthodes ou technologies préexistantes d’inAi.

Il n’existe donc pas de règle publique universelle. La propriété des livrables, l’accès au code source, les licences, les droits de réutilisation, les conditions de transfert et les responsabilités de maintenance continue doivent être convenus avant le début du développement.

Les données propres au client, les documents privés, le contexte métier confidentiel, les processus internes et les éléments fournis par le client restent confidentiels. Les méthodes générales, les schémas réutilisables, la technologie inAi préexistante et les composants qui ne sont pas propres au client sont traités conformément à l’accord de projet.

Utilisez le minimum d’accès utile.

Les systèmes d'IA ont souvent besoin d'accéder à des documents, des bases de données, des informations sur les produits, des données d'application, des fichiers, des API ou des outils internes. Cet accès doit être adapté et limité. L’objectif est d’utiliser le minimum d’accès utile nécessaire pour résoudre le problème, et non de collecter plus d’informations que ce dont le projet a besoin.

Avant le début des travaux, inAi et le client doivent clarifier quelles données ou systèmes sont nécessaires, qui peut autoriser l'accès, ce qui ne doit pas être partagé, comment les documents sensibles doivent être traités et ce que le client doit examiner ou approuver. Dans certains projets, le client peut d'abord fournir des exemples de données ou des exemples synthétiques. Dans d’autres, des données réelles peuvent être nécessaires pour évaluer si le système peut fonctionner.

Le bon modèle d’accès dépend du projet. Un prototype peut nécessiter des données de test limitées. Une intégration de production peut nécessiter des API authentifiées, des identifiants de déploiement, des environnements de préproduction ou des sources documentaires approuvées. Un système de connaissances privé peut nécessiter des limites claires autour de ce que l'assistant est autorisé à rechercher. Ces choix doivent être faits délibérément et non présumés.

Les données et accès peuvent inclure

sources de documents approuvées ;

bases de données, exportations, feuilles de calcul ou données de produits ;

API et identifiants d’intégration ;

environnements de préproduction ou de test ;

des échantillons de données, des données anonymisées ou des données synthétiques, le cas échéant ;

règles d'accès pour différents utilisateurs ou équipes ;

les responsabilités de vérification des résultats sensibles ou incertains ;

limites concernant ce que le système ne doit pas utiliser.

Concevez la bonne forme de système.

Tous les problèmes d’IA ne demandent pas la même architecture. Une solution utile peut prendre la forme d’un assistant privé, d’un système de recherche documentaire, d’une fonctionnalité produit, d’une chaîne de traitement de documents, d’un tableau de bord assisté par l’IA, d’un processus de données, d’un processus agentique, d’un prototype, d’une application sur mesure ou d’une combinaison de ces éléments.

La conception de la solution est le moment où inAi choisit la forme du système autour du problème. Elle peut inclure le choix du modèle ou de l’API, la conception de la recherche ou de la récupération d’informations, les chaînes de données, les invites et instructions, le comportement de l’expérience utilisateur, la logique d’autorisation, les points de vérification, les surfaces d’intégration, les formats de sortie, la journalisation, le parcours de déploiement et le modèle d’accompagnement.

Cette étape est importante car l’IA ne doit pas être ajoutée comme décoration. La conception doit répondre à des questions pratiques : où l’IA apparaît, ce qu’elle est autorisée à faire, ce qu’elle doit produire, comment les utilisateurs l’inspectent ou la corrigent, comment elle se connecte aux outils existants et que se passe-t-il lorsque le système est incertain ou erroné.

Construisez, testez et évaluez en situation réelle.

Un système d’IA fonctionnel doit être testé par rapport au type de cas auquel il sera réellement confronté. Cela ne signifie pas que tous les cas futurs possibles peuvent être prédits. Cela signifie que le projet doit inclure une évaluation suffisamment spécifique pour révéler les faiblesses évidentes avant la livraison.

Selon le projet, l'évaluation peut inclure des exemples de requêtes, des documents de test, des résultats attendus, des cas de comparaison, un examen par des experts du client, des vérifications des modes de défaillance, des indicateurs d'incertitude, des références aux sources, une validation de données structurées, des tests d'intégration, des retours d'utilisateurs ou des exécutions répétées sur des exemples représentatifs.

Le but de l’évaluation n’est pas de prétendre que l’IA est parfaite. L’objectif est de comprendre comment le système se comporte, où il est fort, où il doit être vérifié et quelles conditions doivent être respectées pour que la solution soit utile.

Le client ne devrait pas avoir à gérer seul la pile IA.

Une solution d'IA personnalisée peut nécessiter un hébergement, un stockage, un accès au fournisseur d'IA, des clés API, une authentification, des bases de données, des files d'attente de tâches, une surveillance, des journaux, des sauvegardes, des pipelines de déploiement, un accès utilisateur ou des connexions aux outils existants du client. Le client ne devrait pas avoir à comprendre ou gérer tout cela seul.

Selon le projet, la solution peut fonctionner sur une infrastructure organisée par inAi, une infrastructure contrôlée par le client ou une configuration hybride. Le bon modèle dépend de la sensibilité des données, des préférences du client, des systèmes existants, des besoins de déploiement, du budget, de la propriété technique et des attentes en matière d’accompagnement à long terme.

L'hébergement, le stockage, l'utilisation du modèle/API, les coûts des services tiers, la supervision, la maintenance, les sauvegardes, les attentes en matière de disponibilité et les responsabilités d’accompagnement doivent être définis dans la proposition ou l'accord d’accompagnement. Le rôle d'inAi est d'organiser le parcours technique nécessaire au fonctionnement de la solution, sans impliquer que chaque projet utilise du matériel appartenant à inAi ou un modèle d'hébergement fixe.

Configuration mise en place par inAi

inAi aide à organiser et à exploiter la configuration technique lorsque cette solution convient au projet et au modèle d’accompagnement.

Configuration contrôlée par le client

La solution fonctionne dans une infrastructure contrôlée par le client ; inAi la construit, l’intègre, la documente ou l’accompagne conformément à l’accord.

Configuration hybride

Certaines parties sont gérées ou organisées par inAi, tandis que d’autres restent dans les systèmes, comptes, environnement cloud ou outils internes du client.

La livraison doit inclure une fenêtre de correction claire.

La livraison ne consiste pas simplement à envoyer des fichiers ou à activer une intégration. Un projet doit définir ce que signifie l'acceptation : ce qui a été livré, ce que le client peut tester, quelles conditions s'appliquent, quels problèmes sont considérés comme des corrections dans le périmètre convenu et combien de temps dure la période de test ou d'acceptation.

Pendant la période de test et d’acceptation convenue, inAi corrige les problèmes qui relèvent du périmètre convenu afin que le système livré fonctionne comme prévu dans les conditions définies pour le projet. Cela ne constitue pas une refonte illimitée. Si le système ne répond pas aux critères de livraison convenus, il s’agit d’une correction. Si le client souhaite de nouvelles fonctionnalités, intégrations, processus de travail, un changement d’échelle, des sources de données supplémentaires, un comportement modifié ou une nouvelle orientation produit, il s’agit d’un travail supplémentaire.

Cette distinction doit être claire avant le début des travaux. Elle protège la qualité sans transformer le projet en processus de changement illimité.

Domaine

Catégorie

Définition

Corrections

problèmes relevant du périmètre convenu, pendant la période de test ou d’acceptation convenue.

Demandes de changement

nouvelles fonctionnalités, nouveaux processus de travail, intégrations supplémentaires, changement d’échelle, nouvelles sources de données, exigences modifiées ou évolution ultérieure du produit.

Les systèmes d’IA évoluent souvent après la première version.

Un premier système opérationnel révèle souvent de nouveaux besoins. Les utilisateurs demandent un autre format de sortie ; une équipe souhaite connecter une autre source de données ; le processus de travail évolue ; un modèle ou un fournisseur change. Le client peut vouloir prendre en charge davantage d’utilisateurs, de documents, de produits, de langues ou d’intégrations, ou mettre en place un processus d’approbation plus complexe.

Cette évolution peut être utile, mais elle doit être gérée délibérément. Les nouvelles exigences doivent faire l’objet de demandes de modification, de phases de suivi ou d’un accompagnement et développement continus. Cela préserve la clarté de la livraison initiale tout en permettant au système de s’améliorer au fil du temps.

L’objectif n’est pas de figer définitivement le projet, mais de distinguer la livraison de son évolution afin que le client sache ce qui est inclus aujourd’hui et ce qui doit être planifié ensuite.

L’accompagnement peut se poursuivre après le lancement.

Un système d’IA ne reste pas forcément stable parce que sa première version fonctionne. Les données changent, les utilisateurs rencontrent des cas limites, les modèles et fournisseurs évoluent, les API et les coûts changent, et les processus de travail se transforment. Un système utile aujourd’hui peut ensuite nécessiter maintenance, supervision, mises à jour, corrections de bogues, amélioration des instructions ou de la recherche, changement de modèle ou de fournisseur, évolution de l’expérience utilisateur, nouvelles intégrations ou évaluation supplémentaire.

inAi ne présente pas les services comme une réalisation unique suivie d’un départ. Un projet peut prévoir seulement un transfert, un accompagnement limité après lancement ou une relation mensuelle continue d’accompagnement et de développement. Le bon modèle dépend de l’importance et de la fréquence d’usage du système, de sa dépendance à des fournisseurs externes, de l’évolution des données du client et de son souhait de confier à inAi la maintenance et l’amélioration.

L’accompagnement continu doit être explicitement convenu. Il peut inclure maintenance, supervision, mises à jour, corrections de bogues, ajustements de fournisseur ou de modèle, amélioration des processus de travail, développement de fonctionnalités, retours utilisateurs, mises à jour de la documentation et revue périodique de la qualité du système.

Transfert

Le projet est livré avec la documentation et le client en assume la responsabilité après la période d’acceptation convenue.

Accompagnement limité après lancement

inAi reste disponible pendant une période définie après la livraison afin de corriger les problèmes identifiés et d’accompagner l’adoption.

Accompagnement et développement continus

inAi continue de maintenir, surveiller, améliorer et étendre le système dans le cadre d'un accord mensuel ou basé sur un projet distinct.

Le prix dépend du périmètre, de la responsabilité et des besoins opérationnels.

Les services IA sont tarifés par projet, car un travail d’IA sur mesure peut varier fortement. Une courte phase de découverte, un prototype ciblé, une intégration produit, un processus de traitement de documents, une couche d’analyse de données et un système accompagné sur le long terme n’impliquent ni la même structure de coûts ni la même responsabilité.

Le prix peut dépendre des besoins de découverte, de la complexité du projet, de l'état des données, de la préparation des données, du nombre d'intégrations, du modèle de déploiement, des exigences d'hébergement ou d'infrastructure, de l'utilisation du modèle/API, des coûts des services tiers, des besoins en matériel ou en calcul le cas échéant, de la profondeur de l'évaluation, des attentes en matière d’accompagnement et du niveau de responsabilité continue après le lancement.

Pour cette raison, inAi n’a pas besoin de publier des prix de service fixes pour toutes les situations possibles. La bonne tarification intervient une fois que le problème, le périmètre, les exigences techniques, le modèle d’accompagnement et les coûts d'exploitation sont compris.

Audit de découverte ou de mise en œuvre de l'IA

Une phase ciblée pour comprendre le problème, les données, le processus de travail, les risques et la piste de solution envisageable.

Prototype ou MVP

Une version limitée qui permet de vérifier si une idée, un assistant, un processus de travail ou une fonctionnalité produit d’IA peut fonctionner avant de s’engager dans un système plus large.

Projet à périmètre fixe

Un projet défini avec des livrables convenus, des critères d'acceptation, une fenêtre de correction et un plan de transfert ou d’accompagnement.

Projet d'intégration

Un projet centré sur l’ajout de l’IA à un produit, un site web, un outil interne, une base de données, un CRM, un ERP, un CMS, un PIM, une place de marché ou un processus de travail existant.

Accompagnement continu

Maintenance, supervision, améliorations, corrections de bogues, mises à jour de modèle ou de fournisseur, évolution des processus de travail et accompagnement après livraison.

Développement continu

Une relation à plus long terme pour les clients qui souhaitent qu’inAi continue à développer et à améliorer un système d’IA au fil du temps.

Le client apporte du contexte. inAi construit le parcours technique.

Un projet de services fonctionne mieux lorsque les responsabilités des deux parties sont claires. Le client n’a pas à gérer seul la pile IA, mais son contexte est essentiel. inAi ne peut pas concevoir un système utile sans comprendre le processus de travail, les utilisateurs, les objectifs, les contraintes, les données et la réalité concrète de l’organisation ou du projet.

Le client doit généralement fournir un contexte commercial, un accès aux documents ou systèmes pertinents, des retours sur les résultats, des validations en temps utile et des personnes capables de confirmer si le système est utile. inAi peut apporter une réflexion produit native de l’IA, la conception du système, la mise en œuvre, l'intégration, l'évaluation, le parcours de déploiement, la documentation et l’accompagnement, lorsque cela est convenu.

Les meilleurs projets ne sont pas construits à partir d’une vague ambition en matière d’IA. Ils sont construits à partir d’un problème réel, d’une connaissance claire du client et d’un parcours technique qui peut être testé par rapport à une utilisation réelle.

Le travail d’IA sur mesure commence par des engagements clairs.

Un projet d’IA sérieux ne doit pas commencer par des promesses vagues. Avant qu’inAi confirme le périmètre, le calendrier, le coût, le niveau d’automatisation ou l’accompagnement à long terme, nous examinons d’abord le problème réel : le processus de travail, les données disponibles, les systèmes existants, les utilisateurs, les risques, les contraintes et le résultat attendu.

Cette analyse permet de définir ce qui peut être construit, ce qui doit être testé, ce qui nécessite une expertise spécialisée, ce qui nécessite l'approbation humaine et ce que devrait signifier le succès. Elle évite également au client de se voir livrer une démo d’IA fragile qui fonctionne une fois mais ne peut pas fonctionner de manière fiable dans la situation réelle.

Le but n’est pas d’affaiblir l’offre. L’objectif est de rendre le projet suffisamment concret pour le réaliser, l’accompagner et l’améliorer.

Ce que nous clarifions avant le début du travail

Périmètre et critères de réussite

État des données et accès

Systèmes et intégrations existants

Coûts de modèle, d'API, d'hébergement ou de calcul

Expertise juridique, de sécurité ou propre au domaine concerné

Niveau d'automatisation et points de vérification humaine

Délai de livraison, de test et de correction

Propriété, transfert et accès au code source

Accompagnement continu et évolutions futures

Références publiques uniquement avec le consentement du client

Où les services s'intègrent dans inAi.

Les services font partie de la mission plus large d’inAi visant à amener l’IA dans le monde réel, mais ils ont un rôle spécifique.

Les produits sont ce qu’inAi construit pour des besoins reproductibles. Les produits pour entreprises, les produits pour particuliers et les produits destinés aux agents sont les gammes de produits d’inAi. L’Open Source réunit des technologies publiques sélectionnées pour les créateurs et l’écosystème au sens large. Les services sont différents : ce sont des projets sur mesure construits autour du produit, du processus de travail, des données, de l’infrastructure, des contraintes et des objectifs d’un client.

Cette distinction est importante. Les services ne doivent pas réduire inAi à une agence générique, et les produits ne doivent pas prétendre résoudre tous les problèmes spécifiques du client. Certains besoins sont mieux satisfaits par un produit inAi. Certains sont mieux servis par un projet de services personnalisé. Certains travaux de services peuvent révéler ultérieurement une opportunité de produit reproductible, mais le positionnement public reste clair : problème client spécifique, travail d'IA sur mesure, périmètre convenu, confidentialité par défaut.

Apportez le vrai problème.

Une conversation utile sur les services commence par la situation : ce qui ne fonctionne pas, ce que le client souhaite améliorer, quelles données ou quels systèmes sont impliqués, qui utilisera le résultat, quels risques ou contraintes sont importants et ce qui assurerait la réussite du projet.

À partir de là, inAi peut vous aider à choisir la bonne voie : découverte, prototype, projet à périmètre fixe, intégration, transfert, accompagnement continu ou développement continu sous contrat.

Démarrer une conversation sur les services Découvrir les services d’IA

Loading page content...