Une entreprise nous contacte presque toujours avec une demande déjà écrite noir sur blanc. Un chatbot pour le service client, un outil qui trie les candidatures, un système qui résume les rapports internes avant chaque comité. Le budget est validé, une deadline traîne quelque part dans un tableau partagé, et souvent quelqu'un dans l'équipe a déjà commencé à comparer des devis. La première question qu'on pose casse en général ce rythme-là. On ne demande pas quand le projet doit être prêt. On demande ce qui se passe aujourd'hui, dans le détail, sans l'outil qu'on nous demande de construire. Est-ce que quelqu'un a déjà essayé de résoudre ce problème autrement ? La réponse, la plupart du temps, est non. Personne n'a eu le temps de se poser la question avant de rédiger le cahier des charges. C'est précisément ce que sert à faire un diagnostic avant de développer quoi que ce soit, et c'est une étape qu'un projet sur deux saute complètement.
Ce qu'on nous demande n'est presque jamais ce qu'il faut construire
Vérifier ce qui se passe aujourd'hui révèle en général autre chose que ce qui a motivé l'appel. Les données existent, mais elles vivent dans trois outils qui ne communiquent pas entre eux, et personne dans l'équipe ne s'était rendu compte à quel point ça pesait sur le quotidien. Le process qu'on veut automatiser n'est écrit nulle part, il tient dans la tête d'une seule personne qui part en congé la semaine suivante. Ou alors ce qu'on veut mesurer n'a jamais été défini avec précision, et personne ne sait vraiment dire à quoi ressemblerait un résultat réussi si on l'avait sous les yeux.
Un développement lancé sur cette base construit une réponse technique à un problème qui n'est pas encore posé clairement. Ça arrive plus souvent qu'on ne le pense, une entreprise découvre une fois l'outil livré que le vrai frein n'était pas la technologie mais l'absence d'un processus clair à automatiser. Un diagnostic sert d'abord à vérifier qu'il y a bien un projet, avant même de se demander lequel.
Il arrive qu'il n'y ait rien à développer du tout
Une partie des demandes qui arrivent chez nous se résolvent sans une ligne de code. Un outil déjà présent dans l'entreprise, mal configuré ou à moitié exploité, couvre souvent une bonne partie du besoin réel. Une automatisation simple, sans intelligence artificielle, suffit parfois à régler ce qui semblait justifier tout un projet. Construire un système sur mesure dans ce cas revient à ériger une solution compliquée pour un problème qui, lui, ne l'était pas.
Ça n'arrange personne à court terme de le dire, surtout pas un prestataire qui vit du développement. Mais un projet qui n'aurait jamais dû exister coûte toujours plus cher, sur la durée, qu'un après-midi passé à le vérifier avant de commencer.
Ce que les chiffres disent quand personne ne pose la question avant
Une étude publiée par le MIT en 2025 a analysé plus de 300 déploiements d'intelligence artificielle en entreprise. Le résultat est net. 95% des projets pilotes ne produisent aucun impact mesurable sur les résultats de l'entreprise qui les a lancés.
La cause la plus citée n'est pas la qualité des modèles utilisés, c'est la manière dont les entreprises choisissent où et comment les déployer. Plus de la moitié des budgets IA analysés dans l'étude sont allés vers des outils commerciaux et marketing, alors que le vrai retour se trouvait ailleurs, dans l'automatisation de tâches internes répétitives et peu visibles. Un diagnostic sert précisément à repérer où se trouve ce retour avant de dépenser le budget au mauvais endroit.
La même étude relève un autre écart, presque aussi parlant. Les projets construits en achetant une solution existante et en s'appuyant sur un partenaire réussissent environ deux fois sur trois. Les projets construits en interne, sans accompagnement extérieur, réussissent trois fois moins souvent. Ça n'a rien d'un argument commercial, c'est une donnée qui explique pourquoi le cadrage initial compte presque autant que le développement lui-même.
En France, deux tiers des grandes entreprises savent aujourd'hui mesurer le retour sur investissement de leurs projets IA, contre un tiers un an plus tôt à peine. Le progrès est réel, mais il vient surtout du fait qu'elles ont appris à poser les bonnes questions avant de lancer un projet, pas après coup.
Ce qu'on gagne avec un après-midi de diagnostic
Un diagnostic sérieux ne rallonge pas le calendrier d'un projet. Il évite le plus souvent un développement qui aurait fini abandonné six mois plus tard, une fois le budget dépensé et la déception installée. Il permet aussi de séquencer, de commencer par un usage à faible risque et facile à mesurer avant de toucher un processus sensible comme une décision client ou un calcul financier. Et il donne à l'équipe métier et à l'équipe technique un langage commun, ce qui manque presque toujours au tout début d'un projet.
La question à se poser avant de rédiger un cahier des charges IA n'est pas quelle technologie choisir. C'est ce qui, aujourd'hui, empêche réellement l'équipe d'avancer sans elle. Si la réponse est claire et précise, le développement a du sens. Si elle reste vague, c'est le signe qu'il manque une étape avant, et ce n'est pas une mauvaise nouvelle. C'est juste la prochaine à faire.
Un diagnostic IA se fait en général en une rencontre, avant même de parler de devis ou de développement. Si vous hésitez à lancer un projet sans savoir par où commencer, c'est en général le bon premier rendez-vous à prendre, avant celui avec un développeur.