Réponse courte
Un premier projet d'IA raisonnable est étroit, mesuré et court. Une tâche, un type de document ou une question, avec une définition de « ça marche » écrite avant toute construction, quelques semaines de travail, puis une période d'utilisation en parallèle du processus existant avant que quoi que ce soit n'en dépende. À la fin, vous êtes propriétaire du code, des prompts, des données et de la documentation. Si une proposition ne ressemble pas à peu près à cela, demandez pourquoi.
La première cause d'échec des premiers projets d'IA n'est pas technique. C'est que personne ne s'est mis d'accord sur ce qu'était la réussite, donc le projet ne pouvait pas se terminer. Voici la forme qui évite cela.
Avant toute construction
Le cadrage
Nous partons de la façon dont le travail est fait aujourd'hui, pas de ce que la technologie saurait faire. Qui le fait, combien de temps cela prend, ce qui se passe quand cela se passe mal, et ce qu'une réponse fausse coûte réellement. Cette dernière question décide de l'essentiel de la conception.
Le résultat du cadrage est une phrase décrivant la tâche, et un chiffre décrivant la performance acceptable. Si nous ne pouvons pas écrire les deux, le projet n'est pas prêt et construire serait prématuré.
L'examen des données
Nous demandons de vrais exemples. Vingt ou trente documents réels, quelques centaines de messages réels, ce sur quoi le travail repose. Pas des échantillons choisis.
Ce n'est pas une formalité. L'état des données est le premier facteur de coût sur presque tous les projets, et c'est là que les devis donnés sans regarder se révèlent faux. Parfois l'examen conclut que les données ne sont pas en état de soutenir le projet, et le bon conseil est de corriger cela d'abord. Voir pourquoi vos données sont la partie difficile.
Le devis
Un périmètre fixe et un prix fixe, avec les coûts de fonctionnement indiqués séparément pour que vous sachiez ce que cela coûte de posséder autant que de construire. Facturé au projet et non au mois, parce qu'un développement a une fin et que facturer mensuellement une chose qui se termine crée la mauvaise incitation des deux côtés.
Les quatre choses qui font bouger le prix
| Facteur | Moins cher quand | Plus cher quand |
|---|---|---|
| État des données | Format constant, numérique, une seule source | Formats mêlés, photos, plusieurs sources qui se contredisent |
| Intégrations | La sortie arrive dans un fichier ou un courriel | Elle doit écrire dans des systèmes sans interface documentée |
| Tolérance à l'erreur | Une personne relit tout de toute façon | La sortie est utilisée directement, ou a une portée juridique |
| Qui maintient | Votre équipe, après passation | Nous, sous accord de maintenance |
Tout prestataire qui chiffre sans poser les quatre questions devine. Vous êtes en droit de demander lequel de ces facteurs porte votre chiffre.
Si vous savez décrire la tâche en une phrase, nous pouvons vous dire lequel de ces quatre facteurs va décider de votre prix, en général dès la première réponse.
Dites-nous ce que vous cherchez à corrigerÀ quoi ressemblent les semaines
- Cadrage et examen des données. Des échanges et un coup d'œil à de vrais exemples. Se termine par un périmètre écrit, une définition de « ça marche » et un devis.
- La construction étroite. La plus petite version qui fait le vrai travail sur de vraies données. Pas une démonstration, pas un prototype jetable.
- Revue sur logiciel qui tourne. Vous l'utilisez, sur votre propre matière. Les retours viennent de quelque chose qui fonctionne plutôt que d'un document décrivant ce qui fonctionnera.
- Mesure. La performance contre le chiffre convenu au départ, sur des exemples que le système n'a pas vus. C'est le moment où le projet a réussi ou non.
- Fonctionnement en parallèle. À côté du processus existant, pour que rien ne soit en jeu pendant que vous vérifiez qu'il tient en conditions ordinaires.
- Passation. Code, prompts, artefacts, données et documentation, écrits pour qu'un autre développeur puisse reprendre sans nous.
Ce que vous obtenez à la fin
- Un système qui fonctionne et fait une chose correctement.
- Le code source et les prompts, qui sont à vous.
- Les données et les artefacts produits en chemin.
- Une documentation écrite pour un développeur qui ne nous a jamais rencontrés.
- Un chiffre de précision mesuré et le jeu de test qui a servi à le mesurer, pour pouvoir recontrôler dans six mois.
- Les coûts de fonctionnement, par écrit.
Le cinquième point est celui que l'on oublie de demander, et c'est celui qui vous protège. Sans le jeu de test, vous ne pouvez pas savoir si le système s'est dégradé, et vous revenez à faire confiance au lieu de savoir.
Ce que « terminé » veut dire
Terminé veut dire que la tâche convenue atteint le niveau convenu sur des données qu'elle n'a pas vues, qu'elle tourne là où le travail se fait, et qu'une autre personne que nous pourrait la maintenir. Cela ne veut pas dire que le système est fini pour toujours, ni que vous êtes engagé sur une deuxième phase.
Un premier projet doit être assez petit pour qu'une erreur soit supportable, et assez réel pour qu'une réussite soit utile.
Ce qu'il est raisonnable d'exiger
- Une définition écrite de « ça marche », convenue avant la construction. Sans elle, impossible de dire si le projet a réussi.
- La propriété de tout à la passation. Code, prompts, données, artefacts.
- Un mode de défaillance énoncé. Ce que fait le système quand il ne sait pas. Si la réponse est qu'il produit toujours quelque chose, c'est un défaut de conception.
- Des coûts de fonctionnement séparés des coûts de construction.
- La documentation comme livrable, et non comme faveur s'il reste du temps.
Une liste plus longue de questions à poser à tout prestataire se trouve dans acheter de l'IA en Algérie : les questions à poser avant de signer.
Et le résultat auquel nous arrivons parfois
Il arrive que le cadrage conclue que le projet ne vaut pas la peine : volume trop faible, un outil plus simple suffit, ou les données ne sont pas là. Nous le disons, et arriver à cette conclusion n'est pas facturé. Refuser un projet nous coûte une facture. En livrer un qui finit abandonné nous coûte la relation et toutes les recommandations derrière.
Voir la page de service : Tarifs et devis pour un projet IA en Algérie.
Questions fréquentes
Combien de temps prend un premier projet d'IA ?
Une première version étroite se compte normalement en semaines plutôt qu'en mois, suivie d'une période de fonctionnement en parallèle du processus existant avant que quoi que ce soit n'en dépende. Un premier projet chiffré en plusieurs mois est en général cadré trop large.
Que doit contenir un premier projet d'IA ?
Une tâche avec une définition écrite de « ça marche » convenue avant la construction, un examen de vos vraies données avant le devis, une construction étroite sur de la vraie matière, une mesure sur des exemples que le système n'a pas vus, un fonctionnement en parallèle, et une passation du code, des prompts, des données, de la documentation et du jeu de test.
Qu'est-ce qui décide du prix d'un projet d'IA ?
Quatre choses : l'état de vos données, le nombre de systèmes à intégrer, le taux d'erreur acceptable, et qui assure la maintenance ensuite. Un devis donné sans poser ces quatre questions est une supposition.
Suis-je propriétaire du code et des données à la fin ?
Vous devriez l'être, et avec nous vous l'êtes. Code, prompts, artefacts et données appartiennent au client à la passation, et la documentation est un livrable pour qu'un autre développeur puisse reprendre.
Et si le projet ne vaut finalement pas la peine ?
Nous le disons pendant le cadrage, avant que vous n'ayez dépensé quoi que ce soit en construction. Cela arrive assez souvent pour être un résultat normal plutôt qu'une gêne.
