Question 1

Que veulent réellement les entreprises qui demandent de l'IA dans leur projet ?

Accepted Answer

Trois choses très différentes, qu'il faut séparer avant de chiffrer : réduire un coût de traitement, ne pas paraître en retard face à un concurrent, ou répondre à une injonction interne. Seule la première se cadre comme un projet. Les deux autres se traitent d'abord par une conversation, sinon on livre une fonctionnalité que personne n'utilise mais que tout le monde a validée.

Question 2

Faut-il une base relationnelle ou une base documentaire pour une application métier ?

Accepted Answer

Une base relationnelle par défaut, dans la quasi-totalité des applications métier. Dès que les données ont des relations et que l'intégrité compte — une commande référence un client, un paiement une facture — le moteur relationnel fait respecter ces règles à votre place, ce qu'aucune couche applicative ne garantit durablement. Une base documentaire se justifie pour des documents autonomes sans relations fortes, ou pour des volumes que le relationnel ne tient plus. Dans les faits, la combinaison la plus courante est une base relationnelle qui stocke aussi du document quand c'est utile.

Question 3

Faut-il faire tourner l'IA sur le téléphone ou côté serveur dans une application mobile ?

Accepted Answer

Côté serveur par défaut, sur l'appareil pour les cas où la latence, le hors-ligne ou la confidentialité l'imposent. Un traitement local évite l'aller-retour réseau et ne coûte rien à l'usage, mais il alourdit l'application, consomme la batterie et fige le modèle dans une version publiée. Le choix se fait tâche par tâche, pas une fois pour toute l'application.

Question 4

Quelles décisions ne faut-il jamais déléguer à une IA dans une application métier ?

Accepted Answer

Celles dont l'erreur n'est pas rattrapable, celles qui doivent être justifiées à un tiers, et celles qui engagent juridiquement. Une IA excelle à préparer une décision — trier, extraire, résumer, proposer. Elle ne convient pas à la prendre quand personne ne pourra expliquer pourquoi, ni revenir en arrière.

Question 5

Faut-il développer une application mobile native, ou un site web suffit-il ?

Accepted Answer

Cela dépend de ce qui existe déjà. Si vous avez une application web moderne, emballez-la : Capacitor la met dans une coque native en réutilisant l'essentiel du code, et réécrire l'interface en React Native ou Flutter ne rapporterait rien sur un outil de gestion. Si l'existant est un site serveur classique, il n'y a rien à emballer et le natif multiplateforme est justifié. La technologie se choisit après avoir regardé l'existant, pas avant.

Question 6

Dans quels cas faut-il renoncer à mettre un agent vocal IA au téléphone ?

Accepted Answer

Quand l'appel porte un enjeu émotionnel, quand l'information demandée n'existe pas dans un système accessible, ou quand le volume est trop faible pour rentabiliser l'exploitation. Un agent vocal traite bien les demandes fréquentes, factuelles et vérifiables ; il dégrade tout le reste, et il le dégrade auprès de gens qui avaient choisi le téléphone parce que le libre-service n'avait pas suffi.

Question 7

Faut-il un data warehouse, un data lake, ou un tableur suffit-il ?

Accepted Answer

Un tableur suffit tant que les données tiennent dans un fichier, qu'une seule personne les met à jour et qu'aucune décision engageante n'en dépend. Un entrepôt de données devient utile dès qu'il faut croiser plusieurs sources, garder l'historique et que plusieurs personnes consomment les mêmes chiffres. Un lac de données ne se justifie que pour de gros volumes de données brutes hétérogènes — c'est rarement le besoin d'une PME ou d'une ETI, et c'est souvent une réponse surdimensionnée.

Question 8

Faut-il développer une application sur mesure ou utiliser un outil no-code ?

Accepted Answer

Le no-code convient tant que l'application reste dans les rails de la plateforme : peu d'utilisateurs simultanés, logique métier simple, peu d'intégrations, aucune contrainte forte de performance ou de conformité. La frontière ne se situe pas au niveau de la complexité apparente mais du modèle de données : dès qu'il devient relationnel et contraint, le no-code coûte plus cher qu'un développement classique. Le bon usage est de valider vite un besoin en no-code, puis de reconstruire ce qui a trouvé son public.

Question 9

Faut-il partir sur une architecture monolithique ou en micro-services pour une application métier ?

Accepted Answer

Partez sur un monolithe modulaire, sauf raison explicite de faire autrement. Les micro-services résolvent des problèmes d'organisation — plusieurs équipes qui doivent déployer indépendamment — et de mise à l'échelle différenciée. Une application métier avec une seule équipe n'a ni l'un ni l'autre : elle hérite alors de toute la complexité distribuée sans aucun des bénéfices. Le bon découpage se découvre en construisant, pas en dessinant.

Question 10

Faut-il développer une application mobile en natif, en multiplateforme, ou faire un site web mobile ?

Accepted Answer

Un site web responsive suffit si l'usage est occasionnel et ne demande ni fonctionnement hors ligne, ni notifications, ni accès au matériel. Le multiplateforme est le meilleur compromis pour une application métier : une seule base de code pour iOS et Android, avec 80 à 90 % du code partagé. Le natif se justifie quand la performance graphique, l'accès fin au matériel ou l'intégration système sont au cœur du produit — sinon il double le coût de développement et de maintenance.

Question 11

Faut-il héberger une application métier dans le cloud ou sur un serveur dédié ?

Accepted Answer

Un serveur dédié ou un VPS suffit à la grande majorité des applications métier : charge prévisible, quelques centaines d'utilisateurs, coût trois à cinq fois inférieur à un équivalent cloud managé. Le cloud se justifie sur trois critères précis — charge très variable, besoin de redondance géographique, ou volonté d'externaliser l'exploitation faute d'équipe. La question n'est pas technique mais économique : qui exploite, et combien de temps cela coûte-t-il ?

Question 12

Sur quels critères choisir la technologie d'une application métier qui doit durer ?

Accepted Answer

Quatre critères, dans cet ordre : la capacité à recruter ou remplacer un développeur sur cette technologie dans votre région, la stabilité des versions majeures et la longueur du support, la qualité de l'écosystème sur les besoins non fonctionnels (authentification, paiement, export, observabilité), et l'expérience réelle de l'équipe qui va construire. La performance brute et la modernité du langage arrivent loin derrière : elles ne sont presque jamais le facteur limitant d'une application métier.

arbitrage

« On voudrait de l'IA » : ce qu'il y a derrière la demande

Choisir sa base de données : relationnel, document, ou les deux

L'IA sur mobile : ce qui tourne sur l'appareil, ce qui part au serveur

Les décisions que nous ne confions pas à un modèle

Emballer ou réécrire : comment nous choisissons une techno mobile

Quand un agent vocal n'est pas la bonne réponse

Tableur, entrepôt ou lac de données : de quoi avez-vous vraiment besoin ?

Sur-mesure ou no-code : où passe la frontière, vraiment

Monolithe ou micro-services pour une application métier ? Notre choix par défaut

Application mobile : natif, multiplateforme ou web ?

Cloud ou serveur dédié : comment nous choisissons

Choisir sa stack technique : les critères qui comptent vraiment

Un projet à cadrer ?