Aller au contenu

Application métier sur mesure

Votre situation et le résultat recherché

Une bonne application n’est pas celle qui fait le plus. C’est celle que votre équipe s’approprie vraiment — y compris quand l’IA s’en mêle.

Ce qu’on fait autrement

Beaucoup de projets numériques (et d’essais d’IA) partent trop vite : on empile une solution, on oublie le reste, et six mois plus tard personne ne s’en sert vraiment.

Avec vous, on tient trois fils en même temps :

L’existant reste quand il tient sa place. L’application (et l’IA qu’on y branche) vient combler le trou entre la route et le bureau, entre les fichiers et les décisions — pas remplacer pour le plaisir.

Comment on avance ensemble


Des exemples de réalisation

Catellani — Quand le planning Excel mangait presque toute la journée du disponant, le terrain et le bureau ont enfin pu parler le même langage.

Chez Catellani, PME de transport, le cœur du métier — organiser les courses, suivre les chauffeurs, facturer proprement — passait encore par un tableur fragile et des ordres papier. Le disponant y passait l’essentiel de son temps. Sur le terrain, les notes manuscrites étaient difficiles à lire ; au bureau, il fallait tout ressaisir. La facturation devenait une chasse aux informations. Leur outil comptable faisait bien son travail : il ne fallait surtout pas le jeter, mais combler le trou entre la route et le bureau.

Nous avons commencé par écouter le quotidien — disponant, chauffeurs, exceptions du terrain — puis construire avec eux une première version : une appli simple pour les chauffeurs (notes vocales, validations d’étapes) et un écran de planning pour le bureau. Rien d’imposé d’en haut : chaque itération partait de leurs cas réels, jusqu’à ce que l’outil colle au métier.

Aujourd’hui, le planning n’est plus un fichier qu’on craint de casser. Le terrain alimente le bureau sans double saisie ; le logiciel comptable reste en place. Une solution encore évolutive, déjà utilisable — aperçu ci-dessous (interface et fonctions, sans les données réelles).

Cré'Architecture — Dicter le PV sur le chantier, le retrouver propre dans Excel : plus de réécriture interminable au bureau.

Chez Cré'Architecture, le chantier produisait de la matière — observations, remarques, points à traiter — et le bureau passait ensuite longtemps à tout reformater dans leur modèle Excel de procès-verbal. Deux écritures pour le même contenu : stress, pertes, et un temps précieux mangé par la forme plutôt que par le fond.

En échange avec l’équipe, l’enjeu était clair : ne pas leur imposer un nouvel outil magique, mais partir de leur Excel, qu’ils connaissent et maîtrisent. Ensemble, nous avons cadré une première version : sur place, on choisit le projet, on dicte ; le texte est mis en forme (corps de métier, zone, description, échéance), une personne le relit et corrige, puis le PV rejoint leur fichier habituel.

Le gain est immédiat et humain : le PV naît sur le chantier ; le bureau valide et publie au lieu de tout retaper. Une solution provisoire au bon sens du terme — utile tout de suite, destinée à s’affiner avec l’usage.

Ypsys — Un diagnostic nLPD clair en quelques questions, un rapport personnalisé : de la valeur avant de demander un contact.

Ypsys accompagne des PME — notamment dans le médical — face à la nouvelle loi suisse sur la protection des données. Beaucoup d’entreprises se croient en règle ; trop découvrent leurs failles trop tard, lors d’un contrôle ou d’un incident. Un audit classique est lourd. Il fallait un premier pas simple, utile, non culpabilisant — et qui aide aussi Ypsys à parler aux bonnes personnes.

Après avoir clarifié le message et le parcours avec eux, nous avons co-construit un questionnaire interactif : une quinzaine de questions, un score de maturité compréhensible, un aperçu personnalisé, puis un rapport envoyé par email. L’idée forte : montrer d’abord ce qui compte pour la personne, avant de lui demander ses coordonnées.

Le résultat sert les deux côtés : le prospect repart avec un diagnostic clair et des priorités ; Ypsys reçoit des contacts déjà engagés, pas un formulaire mort. L’outil est en ligne et continue d’évoluer avec les retours du terrain — à tester ici : nlpd.ypsys.com.

Astonish — Un site vivant dont l’équipe édite les contenus elle-même, sans passer par un développeur à chaque phrase.

Astonish propose des expériences rares, éphémères, locales. Leur site devait renforcer la crédibilité de la marque, inviter à s’inscrire, et surtout laisser l’équipe (Lili, Adrien, Adèle) publier textes et images au rythme de la vie réelle — sans attendre quelqu’un d’autre à chaque mise à jour.

Nous avons écouté comment ils travaillaient déjà dans Notion, puis conçu avec eux un site dont le contenu éditorial vit dans cet espace familier. Ils écrivent et publient là où ils pensent ; le site suit. La navigation reste stable ; le fond, lui, reste entre leurs mains.

Résultat : une vitrine qu’ils font évoluer au quotidien, sans dépendre d’un intermédiaire pour chaque correction. Voici la landing page actuelle, développée avec Lovable; la version déployée par dessus Notion va arriver cet automne.

Because Productions — Une seule base pour personnes, projets, contrats et logistique de tournage : fini les Excel et Word dispersés.

Because Productions organise la logistique des tournages en Suisse. Personnes, sociétés, projets, contrats, hébergements, dépenses, documents utiles… tout cela vivait dans des fichiers Excel et Word éparpillés. Versions multiples, copier-coller, questions permanentes : « laquelle est la bonne ? », « qui a le dernier fichier ? ». Difficile de travailler à plusieurs sans se marcher dessus.

Ulrich connaît ce monde de près. Avec l’équipe Because, nous avons d’abord cartographié le quotidien, puis co-construit un outil unique — qu’ils peuvent faire évoluer eux-mêmes — pour centraliser contacts, projets, génération et envoi de contrats, hébergements, dépenses et ressources.

L’outil est en usage au quotidien. Ce qui change déjà, c’est la clarté : une seule vérité partagée à la place des fichiers redondants. Plus de détail dans l’étude de cas Memoways.


Ce que vous recevez

Vous repartez propriétaire. Nous pouvons héberger et maintenir l'application, mais un autre développeur peut la reprendre à tout moment — vous n'êtes pas captif.

Pour qui ?

Prix, durée et périmètre



Questions fréquentes

Combien de temps avant une première version utile ?

Ça dépend surtout de votre disponibilité et de la netteté du problème — pas d’une promesse magique. Dès que le périmètre est cadré et que les bonnes personnes sont dans la boucle, on vise une première version utilisable sur vos cas réels, qu’on affine ensuite.

Le levier, c’est le jeu collectif : retours terrain, exceptions remontées tôt, décisions rapides. Sans ça, même la meilleure intention s’étire. Avec ça, on avance par itérations courtes plutôt que par un grand silence avant la « grande livraison ».

Comment on évite que le budget dérape ?

On fixe tôt un plafond et un premier palier utiles — même si la suite reste ouverte. Vous savez où vous mettez les pieds ; on n’empile pas les « on verra ».

Le cadrage (souvent une mini-forme d’audit) sert exactement à ça : séparer le nécessaire du nice-to-have, garder ce qui marche déjà, et ne construire que le trou à combler. Les surprises viennent surtout d’un périmètre flou, pas d’une magie technique.

Qui maintient l’application après — et est-on captifs ?

Le code et les données vous appartiennent. On peut héberger et maintenir si vous le souhaitez ; un autre prestataire peut aussi reprendre.

L’objectif du projet, ce n’est pas de vous garder dépendants : documentation, formation, clés en main. L’autonomie prend un peu de temps au début ; c’est ce qui crée le levier ensuite.

Comment faire entrer l’IA sans que ça reste un essai isolé ?

Beaucoup d’équipes ont déjà des essais personnels ou des outils « à côté ». Le risque, c’est la dispersion : chacun son usage, aucune mémoire partagée, aucun lien avec le process métier.

On ancre l’IA là où le travail a déjà lieu — dans l’application, dans le flux, avec des règles de validation humaines. Dictée structurée, aide à la rédaction, scoring, suggestions : utiles seulement si quelqu’un peut corriger, tracer, transmettre.

Cohérent et efficace, ça veut dire : moins d’outils parallèles, plus de continuité entre ce que le terrain produit et ce que le bureau décide.

Est-ce que nos équipes vont vraiment utiliser l’outil ?

C’est la vraie question — et la seule réponse honnête, c’est : seulement si on le construit avec elles. Un outil inventé hors du quotidien finit en tiroir, qu’il soit brillant ou non.

On travaille donc avec les gens du terrain et du bureau dès le premier jet : leurs gestes, leurs exceptions, leurs mots. L’IA, quand elle entre, s’accroche à ces gestes (dictée, structuration, relances) au lieu de vivre dans un coin expérimental.

Sans implication, on préfère le dire au diagnostic : mieux vaut ne pas dépenser que de fabriquer quelque chose que personne n’ouvrira.

Faut-il remplacer nos outils actuels ?

Rarement d’un coup. On part de ce qui tient déjà sa place — compta, fichiers métier, habitudes d’équipe — et on comble le trou entre la route et le bureau, entre les saisies et les décisions.

Remplacer pour remplacer crée plus de friction que de valeur. L’application (et l’IA qu’on y branche) vient en complément quand c’est le bon geste ; le remplacement, s’il arrive, se décide ensuite, les yeux ouverts.

Et si nos besoins évoluent ?

C’est prévu dès le départ. On livre une première version utile, pas une usine figée. Les itérations suivantes ajoutent ce que l’usage révèle — pas ce qu’on avait imaginé trop tôt.

Les exceptions terrain, les nouvelles règles métier, une brique d’IA qui devient pertinente : tout ça s’ajoute quand le besoin est réel. Une base saine et une équipe qui s’est approprié l’outil changent plus vite qu’un monolithe « qui fait tout ».

On n’a pas de cahier des charges — peut-on démarrer ?

Oui. C’est même souvent le bon point de départ. Le diagnostic de 30 minutes sert à voir si le fit est là ; ensuite un cadrage court (audit léger ou atelier) pose le problème, les personnes, le premier palier.

Un cahier des charges trop tôt fige des hypothèses. On préfère une première version sur vos cas réels, puis on écrit ce qui s’est révélé vrai. Vous repartez avec une roadmap et des prochaines actions — pas avec un document mort.