Cinq projets d'IA que nous ne vous vendrons pas
La meilleure façon de réussir un projet d'IA est parfois de ne pas le commencer. Nous publions notre grille de refus d'avance : cinq profils de projet auxquels nous dirons non — et, pour chacun, ce que nous proposerons à la place.
Aussi disponible en : English
Une partie de notre métier consiste à vendre des projets d'intelligence artificielle. Voici donc un texte que notre service commercial n'aurait pas écrit : la liste des projets auxquels nous dirons non.
Soyons précis sur ce que ce texte n'est pas. Une jeune société qui raconterait avoir « refusé des dizaines de contrats », ce serait du storytelling — et notre principe éditorial est que tout ce que nous publions doit être vérifiable. Alors nous faisons mieux : nous publions notre grille de refus d'avance. Elle est datée, publique, opposable. Si un jour nous vous vendons un des projets décrits ci-dessous, vous pourrez nous renvoyer cette page. C'est le contraire d'un argument marketing : c'est un engagement qui nous coûtera des contrats.
Chaque critère vient d'une expérience réelle — la nôtre, sur nos propres produits et sur le terrain. Et chaque refus vient avec son alternative, parce qu'un non sans chemin n'aide personne.
1. « La direction veut de l'IA » — le projet sans problème
Le brief commence par la solution : « il nous faut de l'IA », « nos concurrents en font », « le conseil d'administration demande notre stratégie IA ». Ce qu'il manque : le problème. Aucune métrique qui fait mal, aucun processus dont on connaît le coût actuel, aucune définition de ce que « réussi » voudrait dire.
Ces projets n'échouent pas avec fracas — c'est pire : ils réussissent techniquement et ne changent rien. Une démo impressionnante, un pilote qui tourne, et six mois plus tard personne ne l'utilise, parce qu'il ne résout rien que quelqu'un vivait comme un problème.
Ce que nous proposons à la place : commencer par l'inventaire des opérations, pas par la technologie. Où partent les heures ? Quelles tâches ont un volume, une répétition, une règle ? Quelle métrique, si elle bougeait de 20 %, changerait votre trimestre ? S'il n'y a pas de réponse, il n'y a pas de projet — et vous venez d'économiser six mois.
2. Le calcul déguisé en conversation
« Le chatbot pourra aussi calculer le devis, non ? » Non. Pas chez nous.
Un modèle de langage est probabiliste par construction : même entrée, sorties possiblement différentes. C'est une qualité pour rédiger ; c'est disqualifiant pour calculer un prix, un total, une marge, l'application d'un barème. Nous avons construit une plateforme entière autour de cette séparation — le modèle interprète la demande et rédige le document, un moteur déterministe et auditable fait toute l'arithmétique. Même entrée, même résultat, chaque montant explicable ligne par ligne.
Ce que nous proposons à la place : la bonne répartition des rôles. Le modèle aux frontières du système — comprendre une demande en langage libre, rédiger, résumer. Le logiciel classique au centre — règles, calculs, données. Si votre besoin est à 90 % du calcul, la réponse honnête est parfois qu'il vous faut un bon logiciel métier, pas un projet d'IA.
3. Le RAG sur un marécage documentaire
« Posez des questions à vos documents » est la promesse la plus vendue du moment, et elle fonctionne — à une condition que la promesse omet : que les documents méritent des réponses. Trois versions contradictoires de la même procédure, des classeurs sans propriétaire, des archives que personne n'a triées depuis dix ans : un système de recherche augmentée par IA (RAG, retrieval-augmented generation) posé là-dessus produira des réponses fluides, sourcées — et fausses une fois sur trois, sans que personne sache laquelle.
Il y a une seconde condition, que nous avons détaillée dans notre playbook nLPD : les droits d'accès du système source doivent survivre dans l'index. Un assistant qui répond à tout le monde avec les documents de tout le monde n'est pas un produit, c'est un incident en attente.
Ce que nous proposons à la place : un périmètre réduit et gouverné — un seul corpus, un propriétaire, une version faisant foi, des droits d'accès clairs — et un pilote mesurable dessus. La gouvernance documentaire d'abord ; elle restera un actif même si le projet d'IA s'arrête.
4. Personne n'a d'heures pour la vérité terrain
C'est le critère que le terrain nous a enseigné le plus durement, et nous l'avons raconté en détail : l'IA compresse la construction, elle ne compresse pas la validation. Un système d'entreprise doit être ancré dans la réalité de l'entreprise — ses prix, ses règles, ses cas particuliers — et cette vérité-là n'est écrite nulle part. Elle est dans la tête de vos experts.
Si, au moment de signer, l'entreprise ne peut pas nommer qui validera et combien d'heures il y consacrera, le projet ne mourra pas — c'est plus sournois : il restera en pilote pour toujours. Techniquement réussi, opérationnellement orphelin.
Ce que nous proposons à la place : les heures d'expert au contrat, des sessions de validation cadencées, et un produit conçu pour rendre la validation aussi peu coûteuse que possible. Si ces heures n'existent vraiment pas, le moment du projet n'est pas venu — et le dire avant de signer est un service, pas un désistement.
5. Le remplacement silencieux
Parfois le vrai cahier des charges n'est pas écrit : automatiser une décision lourde de conséquences — trier des candidatures, accorder ou refuser quelque chose à un client, évaluer des collaborateurs — sans revue humaine, parce que la revue humaine « coûte ». Ou remplacer une équipe sans le dire, en appelant ça « augmentation ».
Nous refusons ces projets pour une raison éthique qui n'a pas besoin d'être déguisée en raison technique. Mais la raison technique existe aussi : la loi suisse impose d'informer les personnes des décisions individuelles automatisées et de permettre une revue humaine, et un système sans point de contrôle humain est fragile exactement là où il coûte le plus cher de se tromper. Notre position d'architecture ne varie pas, du devis individuel au catalogue entier : l'IA prépare, le professionnel signe.
Ce que nous proposons à la place : l'automatisation assumée de ce qui peut l'être — le volume, la préparation, le brouillon — avec des points de signature humaine aux décisions qui engagent. Et si l'objectif est une réduction d'effectifs, qu'elle soit décidée et annoncée comme telle, par la direction, pas déléguée en silence à un modèle.
Ce que cette page nous coûte
Relisons : nous venons de décrire cinq familles de contrats que nous nous interdisons. C'est un coût réel, assumé pour une raison économique autant que morale : la Suisse romande est un petit marché. Un projet livré qui ne sert à rien se raconte plus vite qu'un projet réussi — et il se raconte avec notre nom dessus.
Alors apportez-nous votre projet, y compris s'il ressemble à l'un des cinq. Le diagnostic est le début de notre travail, et il n'est pas complaisant : si c'est non, vous saurez pourquoi, et vous repartirez avec le chemin de ce qu'il faut construire d'abord. Un non argumenté vaut mieux qu'un pilote qui ne finira jamais — c'est, littéralement, notre première page de vente.
Questions fréquentes
- Quand ne faut-il pas utiliser l'IA ?
- Quand le problème n'est pas mesuré (pas de métrique qui fait mal, pas de projet), quand la tâche est un calcul qui exige un résultat exact et reproductible (c'est du logiciel classique, pas un modèle probabiliste), quand les documents ou données de base sont un marécage sans gouvernance, quand personne dans l'entreprise n'a d'heures à consacrer à la validation, ou quand l'objectif réel est d'automatiser une décision lourde de conséquences sans revue humaine. Ces cinq situations condamnent le projet avant la première ligne de code.
- Comment savoir si mon entreprise est prête pour un projet d'IA ?
- Trois tests rapides. Un : pouvez-vous citer la métrique opérationnelle que le projet doit améliorer, et sa valeur actuelle ? Deux : les données ou documents dont le système a besoin ont-ils un propriétaire, une version à jour et des droits d'accès clairs ? Trois : un expert métier peut-il s'engager sur des heures de validation régulières pendant le projet ? Trois oui, et le projet a une chance sérieuse. Un non, et c'est là qu'il faut travailler d'abord — c'est moins cher que d'échouer.
- Un modèle d'IA peut-il remplacer un logiciel classique ?
- Pour le calcul, non — et il ne devrait pas essayer. Un modèle de langage est probabiliste : même entrée, sorties possiblement différentes. Un prix, un total, une règle métier exigent l'inverse. Les systèmes qui fonctionnent utilisent chaque outil pour ce qu'il sait faire : le modèle interprète et rédige aux frontières, le logiciel déterministe calcule au centre. C'est l'architecture que nous appliquons dans nos propres produits.
- Pourquoi une société de conseil refuserait-elle un projet ?
- Par intérêt bien compris. La Suisse romande est un petit marché : un projet livré qui ne sert à rien se raconte plus vite qu'un projet réussi. Refuser un projet condamné coûte un contrat aujourd'hui et rapporte une réputation demain. Et un refus utile n'est jamais stérile : il vient avec le diagnostic de ce qui manque et le chemin pour y arriver.