En combien de temps une entreprise de Montréal peut-elle vraiment implanter l'IA ?

La réponse courte, selon la taille du projet

Une à deux semaines, c'est réaliste pour un seul flux de travail, cadré serré. Un système de prise en charge et de réponse aux demandes entrantes. Un parcours de soumission qui recueille les bons détails dès le départ. Une séquence de prise de rendez-vous ou de rappels. Un catalogue qui répond à la question que votre équipe répond encore à la main. Ces projets se livrent vite parce que la portée se limite à une seule chose, que la surface d'intégration est petite et que les décisions exigées de vous sont peu nombreuses.

Trois à quatre semaines, c'est la fourchette de la plupart des vrais projets : un système qui touche plusieurs outils, avec une couche d'IA qui exerce un certain jugement, et qui change la façon dont une partie de l'entreprise fonctionne au quotidien. Un arrière-guichet de concessionnaire avec un site web alimenté à partir de celui-ci. Un agent de soutien branché sur les données de commandes en direct. Une boutique en ligne rebâtie avec des outils sur mesure qui remplacent des applications louées.

Plus long que ça, c'est soit une plateforme réellement importante, soit un projet qui aurait dû être découpé en phases. Passé environ six semaines sans rien en production, on a un problème de cadrage, pas un problème de complexité, et la bonne réaction est de réduire la première livraison plutôt que d'allonger l'échéancier.

Ces fourchettes ne sont pas des vœux pieux. C'est ce que les derniers projets ont pris. La version semaine par semaine se trouve plus bas sur cette page.

Ce qui ralentit vraiment un projet

Les décisions, pas le développement. Le plus grand retard dans un projet d'automatisation, c'est d'attendre que quelqu'un décide ce qui doit se passer dans un cas limite. Que fait le système quand une demande de soumission arrive sans photos ? Qui reçoit l'escalade à 21 h ? Refuse-t-on automatiquement les travaux hors territoire ou les redirige-t-on ? Ces questions prennent des minutes à répondre et des semaines à attendre.

Les accès. Identifiants, clés d'API, droits d'administration sur le CRM, permissions sur le compte publicitaire. Régler les accès dans les deux premiers jours vaut plus pour l'échéancier que tout ce que vous pouvez faire d'autre.

La portée qui s'élargit de côté. Chaque projet a son moment où quelqu'un dit « pendant qu'on y est, est-ce que ça pourrait aussi... ». Parfois la réponse est oui et ça coûte une journée. La plupart du temps, c'est ce qui transforme un projet de trois semaines en projet de sept, et le bon réflexe est de le noter pour la phase suivante.

Les systèmes existants qui ne veulent pas parler. Certaines plateformes exposent tout, d'autres presque rien. Laquelle vous avez, on l'établit dans les premiers jours plutôt que de le découvrir à la troisième semaine, parce que ça change ce qui est possible avant que quiconque s'engage.

Les textes et la langue. Pour un système en contact avec la clientèle, rédiger ce qu'il dit, en français et en anglais, et le faire approuver, est souvent la tâche la plus longue à elle seule. Pas parce que c'est difficile, mais parce que ça demande l'attention du propriétaire, et le propriétaire est occupé.

Ce qui rend un projet rapide

Commencer par le flux de travail où la rapidité rapporte le plus. Pour la plupart des entreprises, c'est la réponse aux demandes entrantes, parce que c'est mesurable, fréquent, et que le retour est immédiat. C'est aussi habituellement le plus simple à construire, ce qui est un alignement rare.

Bâtir sur les outils que vous utilisez déjà. Remplacer des outils ajoute une migration au projet. La plupart des projets devraient connecter ce que vous payez déjà et ne remplacer quelque chose que lorsque c'est réellement le goulot d'étranglement.

Mettre une chose en production et la laisser tourner. Un système testé sur du vrai trafic pendant une semaine vous en apprend plus qu'un mois de révision interne, et il commence à rapporter pendant que le reste se construit.

Donner à une seule personne le pouvoir de décider. Les comités sont plus lents que la complexité. Les projets qui se livrent en deux semaines ont un seul responsable qui peut répondre à une question de cas limite le jour même.

Dire non à la deuxième idée tant que la première ne fonctionne pas. C'est la plus difficile, et c'est la différence entre une entreprise qui a un système qui tourne le mois prochain et une entreprise qui a un plan.

Une séquence réaliste de quatre semaines

Jours 1 à 3. Cartographier l'opération, s'entendre sur le premier flux de travail, régler les cas limites, obtenir les accès. C'est ici que l'échéancier se gagne ou se perd.

Semaine 1. Le flux principal se construit et se teste sur de vraies entrées. Les textes sont rédigés dans les deux langues et envoyés pour approbation, tôt, parce qu'ils reviendront avec des modifications.

Semaine 2. Le premier flux entre en production, de façon limitée. Souvent après les heures d'ouverture seulement, ou sur un seul canal, pour observer le comportement réel avec une exposition restreinte. Les transcriptions et les résultats sont revus chaque jour.

Semaine 3. La portée s'élargit selon ce que la première semaine a montré. Les règles d'escalade se resserrent. Le deuxième flux démarre, habituellement celui que le premier a révélé comme prochain goulot d'étranglement.

Semaine 4. Le reste entre en production, la documentation est rédigée pour votre équipe, et le transfert a lieu. Vous êtes propriétaire du système, des accès et de la documentation, et rien dans son fonctionnement ne devrait dépendre de nous.

Cette forme tient, que vous soyez un concessionnaire, un commerce ou une salle. Ce qui change, c'est quel flux passe en premier, et c'est exactement la conversation qu'on a lors du premier appel. Pour le contexte local, y compris la façon dont la Loi 25 et la Loi 96 façonnent un système en contact avec la clientèle ici, consultez notre page Montréal.

Là où Montréal change l'échéancier

Deux facteurs locaux ajoutent du vrai travail à un système en contact avec la clientèle, et tout fournisseur qui vous soumet un échéancier sans en tenir compte vous soumet le mauvais échéancier.

Les textes bilingues doublent la rédaction et la révision. Chaque message, chaque script et chaque libellé d'interface existe deux fois, rédigé nativement plutôt que traduit, et les deux versions doivent être approuvées. Bâtir bilingue dès le premier jour coûte quelques jours. L'ajouter après coup coûte plusieurs fois plus, parce que chaque séquence déjà en production doit être révisée.

La Loi 25 ajoute des décisions plutôt que du retard : la formulation du consentement, ce qui est enregistré et conservé, si le système décide ou prépare une décision. Prises au cadrage, ce sont une conversation. Prises après le lancement, c'est la reconstruction de quelque chose que les clients utilisent déjà.

Aucun des deux ne fait passer un projet de quatre semaines à huit. Les deux font passer un projet qui les a ignorés dans une deuxième phase coûteuse.