Comment nous travaillons avec les entreprises
Nous faisons une seule chose : prendre un problème qui coûte du temps réel à votre organisation, construire ce qui le résout à l’intérieur de vos propres systèmes, et rester jusqu’à ce que les personnes dont le travail change s’en servent effectivement. Puis nous transmettons et nous partons, le code, la documentation et le jeu d’évaluation vous appartenant. Nous ne vendons pas de logiciel, nous ne revendons la plateforme de personne, et nous ne touchons aucune commission sur les outils que nous recommandons, ce qui est la seule raison pour laquelle notre avis sur le choix d’un modèle ou d’un fournisseur mérite d’être écouté. Une mission commence par une phase courte dont l’unique objet est d’établir ce qui ne va pas réellement et quel est le plafond atteignable. Une part non négligeable des projets s’arrête là, parce que la réponse honnête est de ne pas construire. Nous préférons livrer cette réponse en trois semaines plutôt qu’un système en fonctionnement dont personne ne voulait en six mois.
Ce que nous faisons
Un ingénieur de déploiement en mission
Le métier complet sur un projet plutôt qu’un recrutement permanent : comprendre le problème, construire, intégrer, et rester jusqu’à l’usage réel.
Déploiement d’un système d’IA
Les cinq étapes qui mènent d’un système capable à un système utilisé, et les deux où les projets meurent réellement. Aucune des deux n’est la construction.
Automatisation de processus
Quelles formes de travail s’automatisent bien avec la technologie actuelle, lesquelles en ont seulement l’air, et pourquoi les heures libérées ne deviennent pas de la valeur.
Calculateur de rentabilité
Six entrées, chaque étape du calcul affichée, et une réponse nette avant même de parler à quiconque de construire quoi que ce soit.
Le déroulé d’une mission
Un premier échange, trente minutes, gratuit. Venez avec un problème précis plutôt qu’avec une stratégie. La version utile de cet appel porte sur une tâche qui prend trop de temps aujourd’hui, décrite avec assez de détail pour que nous puissions dire s’il s’agit d’un problème de déploiement, d’un problème d’organisation, ou d’un problème qu’il ne faut pas résoudre avec du logiciel.
Une phase de diagnostic, courte et volontairement peu chère. Le temps de regarder comment le travail se fait réellement, de découvrir ce que les données contiennent vraiment, et d’établir le plafond atteignable. Elle se termine par une recommandation écrite avec un coût et un calendrier, ou par une recommandation de ne pas poursuivre. Les deux sorties sont légitimes et les deux sont facturées au même prix.
La construction, contre un problème défini. Avec un responsable nommé de votre côté, un chemin convenu vers l’accès aux données, et quelque chose devant un vrai utilisateur tôt plutôt qu’à la fin. La première version sera fausse d’une manière que personne n’avait prévue, et c’est précisément l’intérêt de la montrer tant qu’il reste du temps pour la changer.
La transmission, traitée comme un livrable. La documentation, le jeu d’évaluation, et une période où l’une de vos personnes fait tourner le système pendant que nous répondons à ses questions plutôt que l’inverse. Une mission qui s’achève sans cela produit quelque chose qui se dégrade en deux trimestres.
Ce que nous ne promettons pas
Nous ne promettons pas de pourcentage. Quiconque vous annonce un gain d’efficacité avant d’avoir regardé vos données vous cite une moyenne d’autres entreprises, et l’écart entre deux organisations sur un même processus est plus grand que l’effet annoncé.
Nous ne promettons pas que le projet sera utilisé. Nous pouvons promettre de construire quelque chose qui fonctionne, de le mettre tôt devant des gens, et de consacrer du temps réel à l’adoption au lieu de la traiter comme une séance de formation. Qu’une organisation adopte ou non un changement dépend de choses qu’aucun prestataire ne contrôle, et prétendre le contraire reviendrait à vous vendre une garantie que nous ne pourrions pas honorer.
Nous ne promettons pas que l’IA soit la réponse. Dans une part sérieuse des problèmes qu’on nous soumet, la meilleure correction est un changement de reporting, un changement de processus, ou un logiciel ordinaire sans le moindre modèle dedans. Nous le disons, et c’est la phrase la moins commercialement commode de cette page.
Quand ne pas nous appeler
Si vous avez une équipe interne solide et que le problème est bien compris, construisez-le vous-mêmes. Vous le ferez moins cher et vous garderez la connaissance, ce qui compte davantage sur trois ans que n’importe quelle vitesse que nous pourrions ajouter.
Si l’obstacle réel est que deux directions ne s’accordent pas sur la propriété d’un processus, aucun ingénieur de déploiement ne corrigera cela, et le projet consommera du budget pendant que le problème restera exactement où il était. Celui-ci mérite d’être nommé explicitement, parce que c’est la raison la plus fréquente pour laquelle un projet techniquement réussi ne produit rien.
Et si personne au niveau de décision ne veut réellement le changement, arrêtez. Un système qui fonctionne, livré dans une organisation où le changement n’a pas de porteur, est la façon la plus coûteuse d’apprendre ce qu’une seule conversation aurait révélé.
Comment nous sommes payés
À la mission, sur un périmètre fixe convenu après la phase de diagnostic. Pas à l’heure, parce que la facturation horaire récompense la mauvaise chose sur ce type de travail, et pas en partage des économies, parce que cela suppose de s’accorder sur une mesure des économies et que cet accord finit par devenir le projet lui-même.
Rien n’est retenu pour créer une dépendance. Le code, les consignes de modèle, le jeu d’évaluation et la documentation sont à vous sans réserve, et nous ne conservons aucune licence dessus. Si vous ne nous rappelez jamais, le travail continue de fonctionner, et c’est la seule définition défendable d’un déploiement réussi.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
