Intelligence artificielle / Votre projet
Du cadrage à l’exploitation au quotidien : comment nous menons un projet d’intelligence artificielle
Six étapes, un livrable à chacune, et deux moments où le projet peut s’arrêter — sans que ce soit un échec.Un projet d’intelligence artificielle échoue rarement sur le modèle. Il échoue sur un prototype qui ne sort jamais du laboratoire, sur un serveur acheté avant l’usage, sur une plateforme que personne ne tient le dimanche. Notre méthode est faite pour ces trois pièges : rien ne se commande avant le prototype, rien ne se met en production sans quelqu’un pour l’exploiter, et chaque étape laisse un livrable que vous gardez.
Trois façons d’échouer, et aucune n’est technique
Nous les avons vues chez d’autres, et nous avons construit la méthode pour qu’elles ne se produisent pas. Chacune correspond à une étape qu’on saute.
Le prototype qui ne sort jamais du laboratoire
Il tourne, il impressionne, il a été montré au comité. Mais il a été construit sur des documents choisis, sans les droits réels, sans intégration. Le passer en production, c’est tout refaire — et personne ne l’a budgété. Il reste un prototype, puis il s’éteint.
Le prototype se fait sur vos vraies données, avec vos vrais droits.
Le serveur acheté avant l’usage
La direction veut du local, le fournisseur a une configuration, et le matériel arrive trois mois avant qu’on sache ce qu’il portera. Dimensionné au hasard, il est trop petit pour le cas qui vient ou trop grand pour celui qui reste. Et il vieillit dès le premier jour.
On dimensionne sur les mesures du prototype, pas sur un catalogue.
La plateforme que personne ne tient
Le projet est livré, l’équipe projet se disperse, et six mois plus tard le modèle est périmé, l’index n’est plus sauvegardé, et les réponses ont dérivé sans que personne les relise. Ce n’est pas la technologie qui a lâché : c’est l’absence de quelqu’un dont c’était le rôle.
L’exploitation au quotidien se décide avant la mise en production.
Six étapes, un livrable à chacune
Elles s’enchaînent dans cet ordre, et deux d’entre elles se terminent par une décision qui peut être « on arrête ». C’est ce qui rend les quatre autres possibles.
Le cadrage
Le cas d’usage écrit selon notre modèle en douze points : le problème, ce qui reste humain, les données et leur qualité, les contraintes écrites, les intégrations. L’état des droits et des référentiels. Les indicateurs de départ, relevés avant que quoi que ce soit change.
Deux à quatre semaines selon le nombre de services concernés.
L’architecture
Chez Microsoft, dans vos locaux, hybride ou sur place, décidé sur la sensibilité des données, le volume, la latence, la connectivité et le seuil de coût sur trois ans. Les technologies viennent en dernier. Si du matériel est nécessaire, il est dimensionné ici — et commandé après l’étape suivante.
Le prototype, et la première décision
Sur vos vraies données, avec vos vrais droits, pour une vingtaine d’utilisateurs, trois à quatre semaines. Sur du matériel existant ou prêté quand du local est en jeu. On mesure la justesse, la latence, l’usage réel et le coût constaté — contre les indicateurs de départ.
C’est ici que le projet peut s’arrêter. Si les mesures ne tiennent pas, nous l’écrivons, avec les raisons et ce qu’il faudrait changer. Un prototype qui conclut « pas maintenant » a fait son travail.
Le test et la validation
Le matériel s’il y en a, installé et raccordé. L’intégration avec Teams, SharePoint, Dynamics 365, l’ERP ou les systèmes industriels. Les droits testés : une personne sans droit sur un périmètre ne doit rien en obtenir. Le passage à l’humain testé. La journalisation vérifiée. Et la validation par les utilisateurs, pas par le comité.
L’industrialisation
L’ouverture progressive, service par service. La formation par métier, pas par outil. La supervision en place : qui voit que les réponses dérivent, que la latence monte, que la consommation dépasse. Le dossier d’exploitation, utilisable par une autre équipe que la nôtre.
Deuxième décision : qui exploite — nous, dans le cadre de notre infogérance, ou votre équipe, que nous formons. Elle se prend ici, pas après.
L’exploitation au quotidien
Les modèles mis à jour selon un cycle décidé, testés sur vos questions avant remplacement. Les réponses signalées relues. Les droits revus. La sauvegarde et le retour arrière éprouvés. La facture lue chaque mois par quelqu’un dont c’est le rôle. Et la revue trimestrielle qui dit ce que le cas suivant devrait être.
Hypothèse de durée, du premier assessment à la mise en production : deux à quatre mois pour un cas d’usage chez Microsoft sans matériel ; quatre à six mois quand du matériel dans vos locaux est nécessaire, délai de livraison compris. Ce sont des ordres de grandeur, pas des engagements : la mesure fait partie du travail. Le premier cas d’usage n’est pas le rentable ; le troisième, sur le même socle, l’est.
La gouvernance et la sécurité, à chaque étape
Elles ne sont pas une étape à part : elles traversent les six. Quatre choses qui s’écrivent dès le premier assessment et se vérifient jusqu’à l’exploitation au quotidien.
Gouverner des agents comme des collaborateurs numériques
La gouvernance des agents à l’échelle de l’entreprise, ce que change Agent 365, et les décisions à prendre avant le troisième agent — trois articles qui traitent la question en détail.
Trois façons de nous engager
Les mêmes que pour tous nos projets, parce qu’un projet d’intelligence artificielle est un projet informatique : un périmètre écrit avant de commencer, les mêmes personnes jusqu’au bout, une limite dite en clair.
Une étape, un périmètre, un prix
Assessment, prototype, industrialisation : chaque étape se contracte séparément, avec son livrable. Vous décidez de la suivante en connaissant le résultat de la précédente.
Un ingénieur dans vos équipes, le temps qu’il faut
Quand votre équipe mène le projet et qu’il lui manque une compétence — la recherche documentaire, l’intégration, le dimensionnement. Autorisation LSE depuis 2018.
Nous tenons ce que nous avons construit
Modèles, supervision, coûts, sauvegardes, revue trimestrielle, avec un engagement de délai. Dans le cadre de notre infogérance — et nous tenons aussi ce que nous n’avons pas construit.
Ce qu’on nous demande avant de commencer
Cinq questions qui reviennent à la première réunion, et les réponses que nous donnons.
Combien de temps, et combien ça coûte ?
Deux à six mois selon l’architecture, et un coût qui se donne par étape, pas pour l’ensemble : un assessment se chiffre à la première réunion, le reste dépend de ce qu’il trouve. Ce que nous refusons, c’est un prix global avant tout assessment — il serait faux dans un sens ou dans l’autre.
Et si le prototype ne tient pas ?
Le projet s’arrête, avec un rapport qui dit pourquoi et ce qu’il faudrait changer. Vous gardez ce premier assessment, la carte des données, les droits relus et les indicateurs de départ — qui servent au cas suivant. C’est écrit dans le périmètre dès le début.
Qui exploite ensuite ?
Vous, ou nous. La décision se prend à l’industrialisation, pas après, et elle est chiffrée. Si c’est vous, nous formons votre équipe et nous restons en deuxième niveau. Si c’est nous, c’est un contrat d’infogérance, avec un engagement de délai.
À qui appartiennent les livrables ?
À vous. La fiche du cas d’usage, l’architecture, les règles, le dossier d’exploitation, les mesures : tout est écrit pour être utilisable par une autre équipe que la nôtre. C’est la condition pour que vous restiez libre.
Faut-il commencer par vos locaux ou par Copilot ?
Ni l’un ni l’autre par principe. Par le cas d’usage, puis par ce que ses données imposent. Il arrive que la réponse soit « Copilot dans vos licences suffit, pas de projet d’infrastructure » — nous l’écrivons quand c’est vrai. Le comparateur d’architectures donne une première réponse en sept questions.
Les pages qui vont avec
Ce qui vient avant le projet, ce qui le nourrit, et les projets déjà menés.
Identifier les bons cas d’usage
Quand le cas n’est pas encore nommé : les cinq questions qui qualifient un processus, et l’atelier qui les pose.
Voir la page ArchitecturesQuelle architecture pour votre projet ?
Les critères, les quatre architectures comparées, et une réponse indicative en sept questions.
Voir la page Cas d’usageToute la bibliothèque, classée par problème
Chaque cas écrit selon le même modèle en douze points, avec ce qui reste humain.
Voir la page ServicesComment nous travaillons, sur tous nos projets
Les neuf domaines, les trois façons de s’engager, et ce qui reste sur votre bureau à la fin.
Voir la page ExploitationL’infogérance : tenir ce qui a été construit
Deuxième et troisième niveau derrière votre équipe, avec un engagement de délai — pour une plateforme d’intelligence artificielle comme pour le reste.
Voir la page ProjetsCe que nous avons déjà mené
Trente projets publiés, dont un CRM avec assistance et classification, un centre de contact raccordé et un contrôleur autonome avec Azure IoT.
Voir les projetsParlons de votre projet
Décrivez votre cas d’usage, nous revenons avec un périmètre et un prix
Le problème, les données, ce qui ne doit pas sortir, et ce que vous avez déjà essayé. Nous revenons avec le périmètre du premier assessment, sa durée, son prix, et ce que le prototype qui le suivrait permettrait de mesurer.
Ce que nous offrons, c’est la rencontre des ingénieurs qui feront le travail. Assessment, prototype et industrialisation font partie du projet. La discussion qui les précède, elle, ne coûte rien.
Renens, Sion, Châtel-Saint-Denis
Microsoft Solutions Partner et Dell Technologies Gold Partner. Les mêmes ingénieurs du premier assessment à l’exploitation au quotidien, logiciel et matériel compris.
Renens VD +41 21 806 37 15
Sion VS +41 27 552 00 22
Châtel-Saint-Denis FR +41 26 322 59 05