---
title: "Expression de besoin et cahier des charges : modèle"
description: "Ce qu’un prestataire lit pour chiffrer une application, une trame de cahier des charges commentée section par section, et les pièges qui font dériver un budget."
url: "https://lonestone.io/blog/cahier-des-charges-developpement"
---
[Lonestone](/) ⟩ [Blog](/blog)
# Expression de besoin et cahier des charges : la trame pour faire chiffrer votre projet
22 septembre 2026 · 16 min de lecture
Points clés
* L’expression de besoin décrit le problème à résoudre et les personnes qui le vivent. Le cahier des charges y ajoute le périmètre, les contraintes, les critères d’acceptation et les règles de la consultation
* Un prestataire chiffre l’incertitude autant que le travail. Chaque zone floue d’un cahier des charges se retrouve dans le devis, sous forme de marge ou d’hypothèse
* Un cahier des charges décrit ce que les utilisateurs doivent pouvoir faire. Le choix des écrans et des technologies revient au prestataire, qui propose parfois une solution plus simple
* En méthode agile, le cahier des charges fixe les objectifs et le budget de départ, puis le périmètre fonctionnel devient un backlog que l’on repriorise à chaque sprint
Pour faire développer une application, vous devez d’abord écrire ce dont vous avez besoin, puis le transmettre aux prestataires que vous consultez. L’expression de besoin décrit le problème à résoudre, les personnes qui le vivent et les résultats attendus. Le cahier des charges reprend ce contenu et y ajoute le périmètre, les contraintes, les critères d’acceptation et les règles de la consultation. Vous pouvez rédiger les deux sans connaissances techniques. Vous trouverez ci-dessous ce qu’un prestataire cherche dans ces pages pour chiffrer, une trame commentée à reprendre section par section, et les erreurs qui font dériver un budget.
## La différence entre expression de besoin et cahier des charges
L’expression de besoin vient en premier. Elle répond à la question « pourquoi ce projet ? » : quel problème, pour quels utilisateurs, avec quels objectifs mesurables. Le client la rédige en interne, souvent avant de savoir qui réalisera le projet, pour mettre la direction d’accord avec les équipes métier, puis décider de lancer le projet ou non. Elle décrit le problème et laisse la solution pour plus tard.
Le cahier des charges vient ensuite. Il s’adresse aux prestataires, qui s’en servent pour chiffrer leurs devis. Une fois le prestataire choisi, on l’annexe au contrat. Il reprend l’expression de besoin et y ajoute ce qu’un prestataire doit connaître pour s’engager : le périmètre fonctionnel, l’existant, les contraintes, le budget, le calendrier et la façon dont la livraison sera validée.
La norme NF EN 16271, publiée par l’AFNOR en 2013 à la suite de la NF X50-151, nomme les deux documents « expression fonctionnelle du besoin » et « cahier des charges fonctionnel ». Le second décrit le besoin en fonctions à remplir plutôt qu’en solutions. Le prestataire rédige ensuite, en général, les spécifications techniques.
Expression de besoin
Cahier des charges
Spécifications techniques
Question traitée
Pourquoi le projet existe
Quels usages le produit doit permettre
Comment le produit sera construit
Rédacteur
Le client
Le client, parfois avec une assistance à maîtrise d’ouvrage
Le prestataire
Moment
Avant de lancer le projet
Avant la consultation
Après le choix du prestataire
Destinataire
La direction et les équipes métier
Les prestataires consultés
L’équipe de développement
Valeur contractuelle
Aucune
Annexe du contrat
Annexe du contrat ou contenu du backlog
Pour un outil métier de PME, rédigez un seul document qui commence par le besoin et continue sur le périmètre. Deux documents distincts se justifient dans une grande organisation, où l’expression de besoin circule entre plusieurs directions avant que quiconque parle de prestataire.
## Les informations qu’un prestataire cherche pour chiffrer
Un prestataire qui chiffre une application découpe le projet en tâches et estime chacune d’elles. Chez Lonestone, on liste toutes les tâches d’un projet, y compris les tâches secondaires qu’on a tendance à oublier, puis on pèse les [facteurs de complexité de l’estimation](/blog/comment-on-estime-les-projets-web-chez-lonestone) : les zones de flou du périmètre, le nombre de parties prenantes, les dépendances à des services externes, les contraintes de planning.
Chaque question laissée sans réponse par le cahier des charges devient une hypothèse. Un prestataire prudent ajoute une marge pour chacune. Un prestataire pressé choisit une réponse à votre place, sans toujours vous le signaler. Dans les deux cas, les devis reçus deviennent difficiles à comparer, puisque chacun chiffre un projet différent.
Pour estimer sans deviner, un prestataire cherche six informations :
* le contexte, c’est-à-dire l’entreprise, le problème actuel et ce qui se passe si rien ne change
* les utilisateurs, leurs rôles et leur nombre
* les parcours principaux, décrits comme une suite d’actions
* l’existant, c’est-à-dire les logiciels en place, les fichiers Excel à reprendre et les API à appeler
* les contraintes, comme l’hébergement, la sécurité, le RGPD, l’accessibilité ou l’usage sur mobile en extérieur
* les critères d’acceptation, c’est-à-dire la façon de vérifier qu’une fonctionnalité marche
Les intégrations pèsent souvent plus lourd dans un devis que les écrans. Une synchronisation avec un ERP dont l’API est mal documentée peut prendre plus de temps que tout le back-office. Si vous ne savez pas comment votre logiciel actuel expose ses données, écrivez-le : un prestataire préfère lire « à vérifier » plutôt que de découvrir le problème au troisième sprint.
## Modèle de cahier des charges commenté section par section
Cette trame convient à une application web ou mobile sur mesure, un outil métier ou un SaaS. La plupart des sections donnent un exemple tiré d’un même projet fictif, un outil de gestion des interventions pour une PME de maintenance de 40 techniciens.
### 1\. Contexte et objectifs
Présentez l’entreprise en quelques lignes, puis le problème. Décrivez la situation actuelle telle qu’elle est, avec ses contournements. Donnez deux ou trois objectifs chiffrés.
Pour l’outil d’interventions, cela donne : « Les interventions sont planifiées sur un fichier Excel partagé et transmises aux techniciens par SMS. Les bons d’intervention papier arrivent au bureau avec une semaine de retard, ce qui décale d’autant la facturation. Nous voulons facturer une intervention le jour même et diviser par deux le temps de planification hebdomadaire. »
### 2\. Utilisateurs et rôles
Listez chaque type d’utilisateur, son nombre et ce qu’il a le droit de faire. Précisez son contexte d’usage : au bureau sur grand écran, sur le terrain avec un téléphone, avec ou sans réseau.
Les utilisateurs de l’outil d’interventions sont trois planificateurs au bureau, 40 techniciens sur smartphone, souvent dans des sous-sols où le réseau passe mal, et un comptable qui exporte les interventions terminées.
### 3\. Parcours principaux
Décrivez les trois à six parcours qui font l’essentiel de l’usage, sous forme d’étapes. Le format « en tant que \[rôle\], je veux \[action\] pour \[bénéfice\] » des user stories fonctionne bien.
Le parcours principal du technicien s’écrit ainsi : « En tant que technicien, je veux voir mes interventions du jour dans l’ordre de la tournée, pour ne pas appeler le bureau chaque matin. »
### 4\. Périmètre fonctionnel priorisé
Listez les fonctionnalités et classez chacune en « indispensable au lancement », « utile ensuite » ou « si le budget le permet ». Ce classement compte plus que la liste elle-même : il permet au prestataire de proposer une première version réaliste, et à vous de comparer les devis sur une même base.
Dans l’outil d’interventions, la signature du client sur le téléphone du technicien est indispensable au lancement. Le calcul automatique des tournées passe dans « utile ensuite ».
### 5\. Données et volumes
Indiquez les données manipulées, leur volume et leur croissance, ainsi que les données à reprendre depuis l’existant.
L’outil d’interventions gère 800 interventions par mois et 3 000 clients, avec des photos jointes à chaque intervention et un historique de cinq ans à importer depuis Excel.
### 6\. Existant et intégrations
Nommez chaque logiciel avec lequel l’application doit échanger, puis précisez dans quel sens, à quelle fréquence, et ce que vous savez de son API. Joignez la documentation si vous l’avez.
L’outil d’interventions envoie chaque soir les interventions terminées au logiciel de facturation et récupère la liste des clients depuis le CRM.
### 7\. Contraintes
Regroupez ici les points non négociables : hébergement en France, authentification unique avec les comptes Microsoft de l’entreprise, conformité au RGPD, accessibilité, compatibilité avec les téléphones des techniciens. Distinguez les contraintes réelles des préférences, pour que le prestataire sache ce qu’il peut discuter.
### 8\. Critères d’acceptation
Pour chaque fonctionnalité indispensable, écrivez une ou deux phrases vérifiables qui diront si elle marche. Rédigez ensuite le [cahier de recette](/blog/recette-informatique) à partir de ces critères, pendant le développement.
Pour la signature sur le terrain, le critère peut être : « Une intervention signée sur le terrain sans réseau apparaît au bureau dans les cinq minutes qui suivent le retour du réseau. »
### 9\. Budget et calendrier
Donnez une fourchette de budget. Beaucoup de clients la cachent, de peur que les devis s’alignent dessus. En pratique, un budget annoncé permet à chaque prestataire de proposer ce qui tient dedans. Sans lui, vous recevez trois devis construits sur trois idées différentes du projet. Indiquez la date qui compte vraiment et pourquoi : une saison, un salon, la fin d’un contrat de licence.
### 10\. Modalités de la consultation
Précisez ce que vous attendez dans la réponse (compréhension du besoin, démarche, planning, équipe, devis détaillé), la date limite, la date de décision, et les critères qui guideront votre choix.
Copiez la trame vide ci-dessous dans votre éditeur de texte.
```
# Cahier des charges : [nom du projet]
## 1. Contexte et objectifs- L’entreprise en quelques lignes- Le problème actuel et ses contournements- Deux ou trois objectifs chiffrés
## 2. Utilisateurs et rôles- Rôle, nombre, droits, contexte d’usage (bureau, terrain, mobile, réseau)
## 3. Parcours principaux- En tant que [rôle], je veux [action] pour [bénéfice]
## 4. Périmètre fonctionnel priorisé- Indispensable au lancement- Utile ensuite- Si le budget le permet
## 5. Données et volumes- Données manipulées, volumes, croissance, reprise de l’existant
## 6. Existant et intégrations- Logiciel, sens de l’échange, fréquence, documentation de l’API
## 7. Contraintes- Hébergement, sécurité, RGPD, accessibilité, appareils- Contraintes non négociables / préférences
## 8. Critères d’acceptation- Une phrase vérifiable par fonctionnalité indispensable
## 9. Budget et calendrier- Fourchette de budget- Date clé et raison de cette date
## 10. Modalités de la consultation- Contenu attendu de la réponse, date limite, date de décision, critères de choix
```
## Décrire le besoin sans imposer la solution
Un cahier des charges décrit ce que les utilisateurs doivent pouvoir faire. Quand il décrit les écrans ou la technique, le prestataire chiffre la solution imaginée par le client, même quand une autre coûterait moins cher ou servirait mieux les utilisateurs.
Formulation qui impose une solution
Formulation qui décrit le besoin
« Une liste déroulante des techniciens sur la fiche intervention »
« Le planificateur affecte une intervention à un technicien disponible sur le créneau »
« Une application iOS et une application Android »
« Les techniciens consultent et signent les interventions depuis leur téléphone personnel, iPhone ou Android »
« Une base de données MySQL »
« Les données restent hébergées en France » (si c’est bien la contrainte)
« Un tableau de bord avec 12 graphiques »
« Le dirigeant suit chaque lundi le nombre d’interventions facturées et le délai moyen de facturation »
Quand vous décrivez le besoin, le prestataire peut proposer mieux, par exemple une affectation automatique au lieu d’une liste déroulante, ou une seule application web installable sur iPhone et Android au lieu de deux développements. Une contrainte technique réelle a toute sa place dans la section des contraintes : un système d’information interne qui impose une technologie, une DSI qui n’héberge que certains environnements. Signalez en revanche une simple préférence comme telle, pour que le prestataire sache qu’il peut proposer autre chose.
## Trois erreurs qui font dériver un budget
Une application sur mesure coûte moins cher à développer qu’il y a dix ans, grâce aux frameworks modernes et à l’IA. Ce qui coûte cher, c’est de partir dans la mauvaise direction. Cette direction se décide dès le cahier des charges. Le Standish Group, un cabinet américain qui étudie les projets informatiques, plaçait déjà les exigences incomplètes en tête des causes d’abandon citées par les responsables informatiques interrogés pour son enquête CHAOS de 1994 (13,1 % des réponses).
### Figer le besoin trop tôt
Un cahier des charges de 80 pages, rédigé six mois avant le début du développement, décrit un besoin vieux de six mois le jour où l’équipe commence. Les premiers tests avec de vrais utilisateurs remettent presque toujours en cause une partie des hypothèses. Si le contrat engage chaque ligne du document, chaque découverte devient un avenant. Écrivez avec précision les objectifs et les parcours, mais laissez les détails d’écran ouverts.
### Tout déclarer indispensable
Quand tout est prioritaire, le prestataire chiffre tout, donc le devis dépasse le budget. Classez les fonctionnalités en « indispensable au lancement », « utile ensuite » et « si le budget le permet » pour l’éviter. Avec ce classement, vous pouvez aussi lancer une première version réduite, que les utilisateurs ont en main plus tôt, sur le principe du [produit minimum viable](/blog/mvp-minimum-viable-product).
### Oublier les critères d’acceptation
Sans critère écrit, la livraison se discute fonctionnalité par fonctionnalité : le client estime que « l’export ne marche pas », le prestataire répond qu’il fait ce que le document demandait. Avec une phrase vérifiable par fonctionnalité, le client et le prestataire savent dès le départ ce qui sera validé. Ces phrases deviennent ensuite les cas de test du cahier de recette.
## Cahier des charges et méthode agile
En méthode agile, le cahier des charges devient le cadre de départ du projet plutôt qu’un contrat figé. Il fixe les objectifs, les contraintes, le budget et les critères d’acceptation, qui bougent peu. Le périmètre fonctionnel, lui, devient un backlog que l’équipe et le client repriorisent à chaque [sprint](/blog/sprint-agile), à budget constant.
Pour l’[application NaonAir](/realisations/naonair), Air Pays de la Loire a fourni un cahier des charges et la documentation de son API. L’équipe Lonestone en a tiré l’architecture technique, puis a travaillé avec le client sur les parcours utilisateurs et les wireframes, avant de développer en sprints de deux semaines. Chaque sprint se terminait par une démo et une nouvelle version que le client testait en conditions réelles.
Un [cadrage de projet](/blog/cadrage-projet) a lieu avant le premier sprint. Le prestataire y anime des ateliers avec les utilisateurs, puis livre les parcours, les maquettes, le backlog priorisé et des recommandations techniques. Si le client n’a pas encore de cahier des charges, le prestataire le rédige avec lui pendant le cadrage.
graph TD
A\[Expression de besoin
le problème, les utilisateurs, les objectifs\] --> B\[Cahier des charges
périmètre priorisé, contraintes, critères d'acceptation\]
B --> C\[Échanges avec les prestataires et devis\]
C --> D\[Cadrage
parcours, maquettes, backlog, choix techniques\]
D --> E\[Développement en sprints
le backlog est repriorisé à chaque sprint\]
E --> F\[Recette
les critères d'acceptation deviennent des cas de test\]
## Se faire aider pour rédiger son cahier des charges
Pour un outil interne au périmètre clair, vous pouvez souvent rédiger le cahier des charges seul, à partir de la trame commentée. Quand le produit est nouveau, que les utilisateurs sont externes ou que plusieurs équipes ont des attentes différentes, faites-vous aider. Avec son [offre Shape](/offres/shape), Lonestone livre un cahier des charges fonctionnel, des parcours utilisateurs, des wireframes ou des maquettes, une recommandation d’architecture et une estimation, pour 6 K€ en moyenne dans le cas d’un outil interne. Vous restez libre de faire développer le produit par l’équipe de votre choix.
Pour un [outil métier sur mesure](/solutions/developpement-outil-metier) au besoin déjà clair, envoyez-nous votre document, même incomplet. Nos ingénieurs, qui ont pour la plupart entre 10 et 25 ans d’expérience, le relisent avec vous, posent les questions qu’un développeur poserait au troisième sprint, et vous renvoient des conseils et un devis détaillé.
FAQ
## Questions fréquentes
### Faut-il un cahier des charges pour développer une application ?
Oui, un document écrit est nécessaire pour obtenir des devis comparables. Pour un outil métier ou une première version d’application, quelques pages suffisent si elles couvrent le contexte, les utilisateurs, les parcours principaux, le périmètre priorisé, les intégrations, les contraintes et les critères d’acceptation. Sans ce document, chaque prestataire chiffre sa propre interprétation du projet. En méthode agile, le cahier des charges reste utile comme cadre de départ, puis son périmètre fonctionnel devient un backlog repriorisé à chaque [sprint](/blog/sprint-agile).
### Quelle différence entre expression de besoin et cahier des charges ?
L’expression de besoin décrit le problème à résoudre, les utilisateurs concernés et les objectifs, sans parler de solution. Le client la rédige en interne pour décider de lancer le projet. Le cahier des charges reprend ce contenu et y ajoute le périmètre fonctionnel, l’existant, les contraintes, les critères d’acceptation, le budget et les modalités de consultation. Il s’adresse aux prestataires. Le client l’annexe ensuite au contrat. La norme NF EN 16271 parle d’expression fonctionnelle du besoin et de cahier des charges fonctionnel. Pour un projet de PME, les deux tiennent souvent dans un seul document.
### Qui rédige le cahier des charges d’un projet informatique ?
Le client rédige le cahier des charges, parce qu’il connaît le métier et les utilisateurs. Dans les grandes organisations, une assistance à maîtrise d’ouvrage (AMOA) l’aide souvent à le structurer. Le prestataire intervient ensuite pour poser des questions, proposer des solutions et rédiger les spécifications techniques. Pendant un [cadrage de projet](/blog/cadrage-projet), le prestataire peut aussi rédiger un cahier des charges fonctionnel avec le client, à partir d’ateliers avec les utilisateurs.
### Peut-on se faire aider pour rédiger un cahier des charges ?
Oui. Une agence de développement ou un consultant AMOA peut animer des ateliers, formaliser les parcours et prioriser le périmètre. Avec son [offre Shape](/offres/shape), Lonestone livre un cahier des charges fonctionnel, des parcours utilisateurs, des wireframes ou maquettes, une recommandation d’architecture et une estimation. Le client peut ensuite faire développer le produit par l’équipe de son choix. Lonestone propose aussi un échange, des conseils et un devis gratuits à partir d’un document existant, même incomplet.
### Que mettre dans un cahier des charges fonctionnel ?
Un cahier des charges fonctionnel pour une application contient en général dix sections : contexte et objectifs, utilisateurs et rôles, parcours principaux, périmètre fonctionnel priorisé, données et volumes, existant et intégrations, contraintes, critères d’acceptation, budget et calendrier, modalités de la consultation. Il décrit ce que les utilisateurs doivent pouvoir faire, sans imposer d’écrans ni de technologies, sauf contrainte réelle comme un hébergement imposé ou une authentification unique existante.
### Faut-il indiquer son budget dans un cahier des charges ?
Oui, une fourchette de budget donne des devis plus utiles. Sans elle, chaque prestataire imagine une ampleur de projet différente, si bien que les réponses deviennent difficiles à comparer. Avec elle, les prestataires proposent ce qui tient dans l’enveloppe et signalent ce qui la dépasse. Le classement des fonctionnalités en « indispensable », « utile ensuite » et « si le budget le permet » aide à construire une [première version](/blog/mvp-minimum-viable-product) qui tient dans le budget.
Sommaire
[1 / La différence entre expression de besoin et cahier des charges](#la-différence-entre-expression-de-besoin-et-cahier-des-charges) [2 / Les informations qu’un prestataire cherche pour chiffrer](#les-informations-quun-prestataire-cherche-pour-chiffrer) [3 / Modèle de cahier des charges commenté section par section](#modèle-de-cahier-des-charges-commenté-section-par-section) [4 / Décrire le besoin sans imposer la solution](#décrire-le-besoin-sans-imposer-la-solution) [5 / Trois erreurs qui font dériver un budget](#trois-erreurs-qui-font-dériver-un-budget) [6 / Cahier des charges et méthode agile](#cahier-des-charges-et-méthode-agile) [7 / Se faire aider pour rédiger son cahier des charges](#se-faire-aider-pour-rédiger-son-cahier-des-charges)
Sommaire 1 / La différence entre expression de besoin et cahier des charges 2 / Les informations qu’un prestataire cherche pour chiffrer 3 / Modèle de cahier des charges commenté section par section 4 / Décrire le besoin sans imposer la solution 5 / Trois erreurs qui font dériver un budget 6 / Cahier des charges et méthode agile 7 / Se faire aider pour rédiger son cahier des charges
Lonestone est une agence qui conçoit et développe des produits web et mobile innovants intégrant de l'IA.
Nos experts partagent leurs expériences sur le blog. Contactez-nous pour discuter de vos projets !
[En savoir plus sur Lonestone](/)
[Parler à un expert](/contact)
Un cahier des charges à faire relire ?
Envoyez-nous votre expression de besoin, même incomplète. Vous repartez avec nos questions, des conseils et un devis détaillé.
[Découvrir l’offre Shape](/offres/shape)
## On continue la lecture ?
[Tous les articles](/blog)
[
Comment réussir le cadrage de vos projets de produits numériques ?
Découvrez comment un cadrage projet efficace optimise le développement de produits numériques : flexibilité, itération, alignement des objectifs stratégiques.
](/blog/cadrage-projet)[
La recette d’un projet informatique, du cahier de recette au procès-verbal
Le recettage vérifie qu’un logiciel livré est conforme à la commande. Niveaux, cahier de recette, qualification des anomalies, procès-verbal et garantie.
](/blog/recette-informatique)[
Minimum Viable Product (MVP) : définition, exemples et méthode
Version minimaliste et fonctionnelle d'un produit, le MVP sert à valider un concept à moindre coût grâce aux retours des tout premiers utilisateurs.
](/blog/mvp-minimum-viable-product)
[Tous les articles](/blog)
## Nos guides
### Guide de l'IA générative
[
01\. IA, Machine Learning & Deep Learning
](/ai/deep-learning)[
02\. LLM (Large Language Model) : définition et fonctionnement
](/ai/llm)[
03\. RAG + MCP : Architecture pour agents IA
](/ai/rag-mcp)[
04\. Agents IA : définition, fonctionnement et cas d’usage
](/ai/agents-ia)[
05\. Boostez vos logiciels avec l’intégration de l’IA
](/ai/integration-ia)[
06\. Meilleurs outils IA pour les entreprises
](/ai/outils-ia)
### Guide pour créer un SaaS IA
[
01\. Construire un SaaS IA rentable : la méthode qui fonctionne
](/creer-saas-ia/roadmap)[
02\. Comparatif LLM 2026 : quel modèle choisir pour son produit
](/creer-saas-ia/comparatif-llm-saas)[
03\. Héberger un produit IA en France : performance et conformité
](/creer-saas-ia/heberger-ia)[
04\. Framework d’évaluation IA : comment le mettre en place
](/creer-saas-ia/evaluation)[
05\. MCP (Model Context Protocol) : connecter l’IA aux logiciels
](/creer-saas-ia/mcp)[
06\. RAG ou alternatives : choisir l’approche pour son SaaS IA
](/creer-saas-ia/rag)[
07\. Concevoir un copilote IA utile et adopté dans un produit
](/creer-saas-ia/copilote-ia)[
08\. POC IA : valider votre idée avant d’investir dans un produit
](/creer-saas-ia/poc)
### Blog de Lonestone
Retrouvez nos derniers articles sur le développement web, l'IA, le product design et les retours d'expérience de nos projets.
[Accéder au blog](/blog)
Lonestone apporte son expertise product à 200+ grands comptes, PME et startups depuis 11 ans.
Avec notre équipe senior et nos méthodes rodées, vous pouvez comptez sur une livraison rapide d'un produit robuste vraiment utile.
## Nos solutions
[
01\. Intégration IA pour éditeurs logiciels
](/solutions/integration-ia-editeurs)[
02\. Automatisation IA
](/solutions/automatisation-ia)[
03\. Création de SaaS pour startup
](/solutions/creation-saas)[
04\. Développement d'applications métier
](/solutions/developpement-outil-metier)[
05\. Création d'app mobile
](/solutions/creation-app-mobile)[
06\. Création de site web
](/solutions/creation-site-web)[
07\. Création de CRM sur mesure
](/solutions/crm-sur-mesure)[
08\. Création de marketplace sur mesure
](/solutions/creation-marketplace)[
09\. Refonte de site web
](/solutions/refonte-site-web)[
10\. Création d'un ERP sur mesure
](/solutions/creation-erp)[
11\. Formation harness IA
](/solutions/formation-harness)
## On discute de votre projet ?
Échange gratuit et sans engagement, directement avec un expert du sujet. Devis sous 48h.
[Demander un devis](/contact) Prendre rdv
Contacter l'équipe
de Lonestone