Dans l’univers tech, il y a un débat quasi religieux entre les partisans du « vrai » code et les adeptes du no-code. Les premiers méprisent les outils visuels. Les seconds prétendent que le code est mort. Les deux ont tort. La bonne approche dépend du problème à résoudre.
Chez DAIRIA, j’utilise les trois. Du no-code pour prototyper, du low-code pour les outils internes, et du full-code pour les produits critiques. Voici ma grille de décision.
Le no-code : prototyper en 48 heures
Le no-code est imbattable pour une chose : valider une idée rapidement. Quand j’ai une hypothèse de produit — « les DRH auraient besoin d’un outil pour calculer le coût d’un licenciement en 30 secondes » — je ne lance pas un projet de développement. Je construis un prototype no-code en un ou deux jours et je le teste auprès de cinq clients.
Les outils que j’utilise pour ça : des formulaires intelligents, des tableaux connectés, des automatisations basiques. Rien de sophistiqué. Le but n’est pas de construire un produit, c’est de répondre à une question : est-ce que les gens veulent vraiment cette fonctionnalité ?
Le no-code m’a économisé des semaines de développement inutile. Sur les dix dernières idées que j’ai prototypées, trois seulement ont justifié un développement plus poussé. Les sept autres auraient été des projets coûteux sans résultat si j’avais commencé par coder.
« Le no-code n’est pas une solution. C’est un outil de décision. Il vous dit quoi construire avant que vous investissiez dans le comment. »
Le low-code : les outils internes et l’automatisation
Pour les outils internes du cabinet — ceux qu’on utilise nous-mêmes mais qu’on ne vend pas aux clients — le low-code est souvent le bon compromis. Plus puissant que le no-code, plus rapide que le full-code.
Notre système de facturation interne est construit en low-code. Notre outil de suivi commercial aussi. Ce sont des outils qui n’ont pas besoin d’être parfaits en termes d’UX ou de performance — ils doivent juste fonctionner correctement pour notre équipe de dix personnes.
Le low-code excelle aussi pour l’automatisation. Les workflows répétitifs — générer un document à partir d’un template, envoyer un rappel automatique, synchroniser des données entre outils — sont des candidats parfaits. On a automatisé une vingtaine de tâches récurrentes en low-code, ce qui libère plusieurs heures par semaine pour l’équipe.
Le full-code : quand il n’y a pas d’alternative
DAIRIA IA est développé en full-code. Pas par snobisme, mais par nécessité. Quand vous construisez un produit qui traite des données juridiques sensibles avec de l’intelligence artificielle, vous avez besoin d’un contrôle total sur chaque composant.
Le full-code est nécessaire quand la performance compte (temps de réponse de l’IA), quand la sécurité est critique (données clients confidentielles), quand la personnalisation est poussée (algorithmes propriétaires), et quand le produit doit scaler. Aucun outil no-code ne peut gérer des milliers de requêtes simultanées avec la même fiabilité qu’une architecture backend bien conçue.
Le coût est évidemment plus élevé. Le développement prend plus de temps, nécessite des compétences pointues, et la maintenance est permanente. Mais pour un produit commercial dont dépend la réputation du cabinet, ce coût est justifié.
Ma grille de décision
Quand je dois choisir entre les trois approches, je me pose quatre questions :
Est-ce que c’est un test ou un produit ? Si c’est un test, no-code. Toujours.
Combien d’utilisateurs ? Moins de 20 utilisateurs internes ? Low-code suffit. Des centaines ou milliers d’utilisateurs externes ? Full-code obligatoire.
Quelle criticité ? Si un bug cause juste un inconvénient, low-code acceptable. Si un bug cause une perte de données client ou une erreur juridique, full-code.
Quel budget et quel délai ? Budget limité et besoin immédiat ? No-code ou low-code. Budget disponible et vision long terme ? Full-code.
L’erreur du dogmatisme
La plus grande erreur serait de choisir une approche par conviction plutôt que par pragmatisme. J’ai vu des développeurs refuser le no-code par principe, perdant des semaines à coder ce qui aurait pu être testé en un jour. J’ai vu des entrepreneurs no-code s’entêter à construire des produits complexes avec des outils inadaptés, créant des usines à gaz instables.
Le bon choix technique est celui qui résout le problème avec le minimum de ressources et le maximum de fiabilité. Pas celui qui flatte l’ego du développeur ou qui suit la dernière tendance. Le pragmatisme est la seule religion technologique que je pratique.
