Question 1

Qu'est-ce qui change concrètement quand une fonctionnalité IA passe de la démonstration à la production ?

Accepted Answer

À peu près tout, sauf le modèle. Une fonctionnalité IA en production est non déterministe, son coût est variable et proportionnel à l'usage, ses pannes sont silencieuses — elle répond à côté au lieu de renvoyer une erreur — et ses tests unitaires ne servent à rien. Ce qui fait tenir une telle fonctionnalité dans la durée, ce sont un jeu de cas d'évaluation, une stratégie de repli entre fournisseurs, et des prompts traités comme du code : versionnés, relus, testés.

Question 2

Comment éviter d'être prisonnier d'un fournisseur de téléphonie quand on déploie un agent vocal ?

Accepted Answer

En faisant entrer les appels par un trunk SIP plutôt que par l'API propriétaire de l'opérateur. Le SIP est un standard : changer d'opérateur revient à repointer un trunk, sans toucher au code de l'agent. Le piège se déplace alors ailleurs — vers la gestion des numéros, qui reste propre à chaque opérateur et qui est le vrai endroit où l'on se retrouve attaché.

Question 3

Sur quels appareils faut-il tester une application mobile avant de la publier ?

Accepted Answer

Sur trois appareils physiques bien choisis plutôt que sur vingt simulateurs : le modèle le plus répandu chez vos utilisateurs, un appareil ancien de milieu de gamme, et le plus récent. Les simulateurs conviennent au développement mais ne reproduisent ni les performances réelles, ni la caméra, ni le comportement du réseau, ni les stratégies d'économie d'énergie propres à chaque constructeur — qui sont la première cause d'incidents inexplicables sur Android.

Question 4

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 5

Que faut-il vérifier dans ses données avant de lancer un projet d'IA ?

Accepted Answer

Quatre choses, dans cet ordre : que la donnée soit accessible par un programme, qu'elle soit fraîche, qu'on sache ce que chaque champ signifie, et qu'on ait le droit de l'utiliser pour cet usage. Un modèle n'invente pas ce qui manque et ne corrige pas ce qui est faux — il donne à des données médiocres l'apparence de la fiabilité, ce qui est pire que de ne rien faire.

Question 6

Un agent vocal IA qui fonctionne en anglais fonctionne-t-il aussi bien en français ?

Accepted Answer

Non, et l'écart ne vient pas du modèle de langage mais de tout ce qui l'entoure : la transcription bute sur les liaisons et les chiffres, la synthèse se trompe sur les nombres et les noms propres, et les tours de parole français comportent plus d'hésitations. Un agent démontré en anglais peut perdre l'essentiel de sa fiabilité en français sans qu'aucune ligne de code ne change.

Question 7

Comment écrire des critères d'acceptation pour une fonctionnalité qui n'est pas déterministe ?

Accepted Answer

En remplaçant « le système affiche X » par des propriétés vérifiables et un taux attendu, mesurés sur un échantillon de cas réels. Un critère d'acceptation classique suppose une sortie unique et reproductible ; une fonctionnalité IA n'en a pas. La recette se fait alors sur un jeu de cas construit avec le métier, et l'essentiel du travail de spécification porte sur ce qui doit arriver quand le système se trompe.

Question 8

Comment budgéter une fonctionnalité qui utilise un modèle de langage ?

Accepted Answer

En séparant le coût de construction, qui ressemble à n'importe quel développement, et le coût d'usage, qui n'existe pas ailleurs : chaque utilisation se paie. Une fonctionnalité classique amortie devient gratuite ; une fonctionnalité IA coûte d'autant plus qu'elle réussit. Le budget doit donc comporter une ligne récurrente, un plafond, et une décision écrite sur ce qui se passe quand ce plafond est atteint.

Question 9

Pourquoi un agent vocal IA paraît-il lent au téléphone, et que peut-on y faire ?

Accepted Answer

Parce que la latence perçue n'est pas celle du modèle de langage mais celle de la chaîne entière : détection de fin de parole, transcription, génération, synthèse, transport téléphonique. Sur notre chaîne, c'est la transcription qui domine — 700 à 1500 ms avant que le résultat soit déclaré définitif — loin devant le modèle. Le levier le plus rentable n'est donc pas de changer de modèle mais de diffuser la réponse au fil de l'eau plutôt qu'une fois complète.

Question 10

Comment construire une application mobile sur une API existante qu'on ne peut pas modifier ?

Accepted Answer

En traduisant les réponses de l'API en entités propres à l'application dès la frontière, plutôt qu'en laissant sa structure remonter dans les écrans. Le découpage domaine / données / présentation coûte quelques fichiers de plus et rend l'application insensible aux changements de format côté serveur. Sans cette traduction, une évolution de l'API devient une reprise de tous les écrans qui l'utilisaient.

Question 11

Comment démarrer une plateforme de mise en relation quand ni l'offre ni la demande n'est encore là ?

Accepted Answer

En renonçant à lancer les deux côtés en même temps. On choisit la face la plus difficile à recruter — presque toujours celle qui doit publier — et on lui rend un service qui a de la valeur même si l'autre côté est vide. La plateforme n'est utile aux deux qu'ensuite, et ce décalage doit être assumé dans le produit comme dans le budget.

Question 12

Quelles précautions prendre pour analyser des données personnelles dans une entreprise ?

Accepted Answer

Quatre principes couvrent l'essentiel : n'utiliser une donnée que pour une finalité définie et compatible avec celle de sa collecte, ne conserver que ce qui est nécessaire et pas plus longtemps qu'il ne faut, travailler sur des données pseudonymisées dès que l'identité n'est pas indispensable à l'analyse, et tracer qui accède à quoi. L'anonymisation réelle est plus difficile qu'il n'y paraît : retirer le nom ne suffit pas, car un croisement de quelques attributs suffit souvent à réidentifier une personne.

Question 13

Comment relire efficacement du code généré par une IA ?

Accepted Answer

En inversant l'ordre habituel de la revue. Le code généré est presque toujours correct en surface — syntaxe propre, nommage cohérent, tests qui passent — et ses défauts se logent ailleurs : gestion d'erreur optimiste, réinvention de ce qui existe déjà dans le projet, et cas limites traités par omission. Je commence donc par ce que le code ne fait pas, avant de lire ce qu'il fait.

Question 14

Qu'est-ce qu'une équipe de développement doit comprendre du tiers payant avant de coder ?

Accepted Answer

Qu'un dossier n'est pas une transaction unique mais une chaîne à deux payeurs — l'assurance maladie et la complémentaire — chacun avec ses règles, ses délais et ses motifs de rejet. L'essentiel de la complexité n'est pas dans le cas nominal mais dans le rejet : il arrive des semaines plus tard, il faut savoir à quel dossier le rattacher, et le corriger sans perdre l'historique.

Question 15

Qu'apporte le paiement en ligne à une association, au-delà du confort ?

Accepted Answer

Il supprime le travail de relance et de rapprochement, qui coûte bien plus de temps aux bénévoles que l'encaissement lui-même. Le gain n'est pas dans l'acte de payer mais dans ce qui l'entoure : plus de chèques à déposer, plus de tableau de suivi, un état des impayés à jour en permanence. En contrepartie, il faut traiter des cas que le chèque masquait — paiement en plusieurs fois, aides, remboursements.

Question 16

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 17

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 18

Comment piloter le budget d'un projet de développement pendant sa réalisation ?

Accepted Answer

En suivant le reste à faire plutôt que le consommé. Un budget consommé à 60 % ne dit rien : ce qui compte est ce qu'il reste à produire, réestimé à intervalles réguliers par ceux qui font le travail. Trois indicateurs suffisent — le reste à faire en jours, le périmètre encore ouvert, et le nombre de demandes ajoutées depuis le début. Un dépassement se voit toujours plusieurs semaines avant qu'il ne se produise, à condition de regarder le bon chiffre.

Question 19

Comment mesurer honnêtement ce qu'une automatisation fait gagner ?

Accepted Answer

En mesurant avant, sur le processus manuel, et en comptant le temps de bout en bout plutôt que celui de l'étape automatisée. Le piège classique est de comparer la durée de saisie avant et après, en oubliant le temps de vérification, de correction et de reprise des cas rejetés — qui absorbe souvent une grande part du gain annoncé.

Question 20

Pourquoi la gestion des créneaux d'un club sportif est-elle si difficile à informatiser ?

Accepted Answer

Parce qu'un planning de club n'est pas un agenda mais une allocation sous contraintes : des créneaux, des installations, des encadrants et des groupes, dont la disponibilité change en permanence. L'erreur habituelle est de partir d'un calendrier ; il faut partir des contraintes, et concevoir l'outil autour de l'exception plutôt qu'autour du cas nominal.

Question 21

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 22

Comment migrer les données d'une association qui gérait tout dans des fichiers Excel ?

Accepted Answer

En traitant le tableur comme une source de vérité partielle et non comme une base de données. La reprise ne consiste pas à importer des colonnes mais à reconstituer des règles qui n'ont jamais été écrites : ce qu'est un adhérent actif, à quoi correspond une case colorée, pourquoi deux lignes portent le même nom. Le travail est d'archéologie autant que de technique, et il se fait avec la personne qui tenait le fichier.

Question 23

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 24

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 25

Quels contrôles de qualité mettre en place sur une chaîne de données ?

Accepted Answer

Cinq familles suffisent à couvrir l'essentiel : la fraîcheur (les données sont-elles arrivées ?), la volumétrie (en quantité attendue ?), la complétude (les champs obligatoires sont-ils remplis ?), la validité (les valeurs respectent-elles leur format et leur domaine ?) et la cohérence entre sources (les totaux se recoupent-ils ?). Ces contrôles tournent à chaque rafraîchissement et alertent avant les utilisateurs. Ce qui change la perception de fiabilité n'est pas l'absence d'erreur — c'est le fait d'être prévenu avant celui qui consulte le tableau de bord.

Question 26

Comment diagnostiquer efficacement un bug qui ne se produit qu'en production ?

Accepted Answer

En reconstituant les faits avant de formuler la moindre hypothèse. La séquence qui fonctionne : établir précisément ce qui s'est passé et quand, vérifier ce qui a changé récemment, isoler une reproduction fiable même partielle, puis seulement chercher la cause. L'erreur la plus coûteuse est de commencer par une intuition et de chercher à la confirmer — on trouve alors une explication plausible qui n'est pas la bonne, et le bug revient.

Question 27

Comment construire une feuille de route produit réaliste et utile ?

Accepted Answer

En la structurant par horizons plutôt que par dates. Le trimestre en cours est engageant et détaillé ; le suivant est une intention par thème ; au-delà, ce sont des problèmes à résoudre, sans solution ni date. Une feuille de route qui promet des fonctionnalités datées à douze mois est fausse le jour où elle est publiée, et son principal effet est de détruire la confiance quand la réalité s'en écarte. Ce qui doit rester stable, ce sont les objectifs ; ce qui doit bouger, ce sont les moyens de les atteindre.

Question 28

Comment réussir la reprise de données lors du remplacement d'une application ?

Accepted Answer

En la traitant comme un projet à part entière, avec son propre planning et ses propres critères de réussite. La difficulté n'est jamais technique : elle vient de ce que les données existantes ne respectent pas les règles que le nouveau système impose. La méthode qui fonctionne consiste à faire une reprise à blanc très tôt, à mesurer le taux de rejet, à décider avec le métier quoi faire des cas non conformes, et à répéter l'opération jusqu'à ce qu'elle soit fiable et chronométrée.

Question 29

Comment utiliser les notifications push sans faire fuir les utilisateurs d'une application mobile ?

Accepted Answer

En n'envoyant que ce qui concerne personnellement l'utilisateur et appelle une action de sa part. Trois règles gouvernent le reste : ne demander l'autorisation qu'après avoir montré à quoi elle sert, laisser un réglage fin par type de notification plutôt qu'un interrupteur unique, et respecter le fuseau horaire ainsi que les heures de repos. Une autorisation refusée est très difficile à récupérer — la demander au premier lancement est l'erreur la plus coûteuse et la plus fréquente.

Question 30

Faut-il contractualiser un développement au forfait, en régie ou en centre de services ?

Accepted Answer

Le forfait convient quand le périmètre est stable et documenté : le prestataire porte le risque de dérive, et vous payez cette assurance dans le prix. La régie convient quand le besoin évoluera en cours de route : vous payez des jours et vous portez le risque, ce qui suppose d'avoir quelqu'un pour piloter. Le centre de services est un compromis pour une relation durable : une capacité récurrente avec des engagements de résultat sur le service rendu. Le mauvais choix n'est jamais le modèle en soi, c'est le décalage entre le modèle et la maturité du besoin.

Question 31

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 32

Comment gérer les traitements asynchrones et les files d'attente dans une application ?

Accepted Answer

Trois règles suffisent à éviter la quasi-totalité des incidents : toute tâche doit être rejouable sans effet de bord (idempotence), toute tâche qui échoue définitivement doit atterrir quelque part où quelqu'un la voit (file d'échec), et l'ordre d'exécution ne doit jamais être supposé. Une file d'attente ne garantit pas qu'un message est traité une seule fois — elle garantit qu'il est traité au moins une fois, ce qui n'est pas la même chose et change la façon d'écrire le code.

Question 33

Comment réussir l'adoption d'une nouvelle application par les équipes qui l'utiliseront ?

Accepted Answer

En traitant l'adoption comme une partie du projet, pas comme une formation de fin de parcours. Ce qui fonctionne : associer quelques utilisateurs dès le cadrage, livrer d'abord à un petit groupe volontaire, accepter de modifier l'outil après les premiers retours, et fixer une date de bascule ferme. Une application refusée l'est presque toujours parce qu'elle demande plus d'efforts qu'elle n'en fait gagner à celui qui la saisit — et ce déséquilibre se corrige dans la conception, pas dans la conduite du changement.

Question 34

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 35

Que coûte l'entretien d'une application mobile après sa mise en production ?

Accepted Answer

Entre quelques jours et quelques semaines par an et par plateforme, même sans ajouter la moindre fonctionnalité. Ce budget couvre trois obligations subies : les versions annuelles d'iOS et d'Android à tester, les exigences des magasins qui évoluent avec des échéances fermes, et les dépendances techniques qu'il faut suivre pour rester à jour. Une application mobile laissée sans entretien pendant deux ans ne dégrade pas progressivement — elle devient impubliable d'un coup, et la remise à niveau coûte alors bien plus cher que l'entretien évité.

Question 36

Faut-il développer une application en interne, l'externaliser, ou acheter un logiciel existant ?

Accepted Answer

Achetez un logiciel du marché si votre besoin est standard — c'est presque toujours moins cher, même en s'adaptant un peu. Développez sur mesure quand le processus concerné vous différencie de vos concurrents. Externalisez quand vous avez besoin de la compétence sans vouloir la recruter durablement. La question à trancher d'abord n'est pas « qui code ? » mais « ce processus fait-il partie de ce qui nous distingue ? ».

Question 37

Pourquoi les tableaux de bord ne sont-ils pas utilisés, et comment en concevoir un qui le soit ?

Accepted Answer

Parce qu'ils répondent à la question « que peut-on afficher ? » au lieu de « quelle décision faut-il prendre ? ». Un tableau de bord utilisé tient sur un écran, comporte cinq à sept indicateurs maximum, affiche systématiquement une référence de comparaison, et se rattache à une réunion existante. S'il ne change aucune décision, il ne sera pas consulté — quelle que soit sa qualité graphique.

Question 38

Comment prendre en main une application existante que l'on ne connaît pas ?

Accepted Answer

En cinq étapes, dans l'ordre : faire tourner l'application en local sans aide, suivre un parcours utilisateur complet dans le code, lire l'historique des six derniers mois pour voir où ça bouge, corriger un bug minuscule et le mettre en production, puis écrire ce qui manquait à la documentation. La compréhension vient de l'exécution et de la première livraison, pas de la lecture exhaustive du code.

Question 39

Comment rédiger une user story ou une spécification claire pour une équipe de développement ?

Accepted Answer

En décrivant le problème et les critères d'acceptation observables, jamais la solution technique. Une demande exploitable tient en une page : qui, quel problème, ce qui doit être vrai à la fin, les cas particuliers connus, et ce qui est explicitement hors périmètre. La section « hors périmètre » est celle qui évite le plus de malentendus, et c'est celle qu'on oublie systématiquement.

Question 40

Quels sont les points de sécurité à vérifier sur une application web métier ?

Accepted Answer

Huit points, avant toute mise en production : l'authentification déléguée à un composant éprouvé, un contrôle d'accès vérifié côté serveur sur chaque requête, le cloisonnement des données entre organisations, le chiffrement en transit et au repos, la journalisation des accès sensibles, la gestion des secrets hors du code, les mises à jour de dépendances automatisées, et une procédure de restauration testée. Aucun de ces points n'est exotique : ce sont les mêmes failles que l'on retrouve année après année.

Question 41

Pourquoi les utilisateurs désinstallent-ils une application mobile, et comment l'éviter ?

Accepted Answer

Trois causes dominent : un démarrage trop long, une interface qui saccade, et une consommation de batterie perçue comme anormale. Les deux premières se corrigent en déplaçant le travail hors du démarrage et hors du fil d'affichage. La troisième vient presque toujours de la position en continu, de la synchronisation trop fréquente ou d'un travail en arrière-plan mal borné. Ces trois causes se mesurent avec l'outillage fourni par les plateformes, sur un appareil ancien plutôt que sur le téléphone du développeur.

Question 42

Quelle est la différence entre une ESN, une agence web, un éditeur de logiciel et un freelance ?

Accepted Answer

Une ESN met des consultants à disposition dans vos équipes et vous pilotez. Une agence ou un studio livre un projet complet et porte l'engagement de résultat. Un éditeur vend son logiciel, que vous adaptez à la marge. Un freelance apporte une compétence pointue sans continuité garantie. Le bon choix dépend d'une seule chose : qui, chez vous, va piloter — et pendant combien de temps.

Question 43

Comment retrouver la confiance dans les données quand chaque service a ses propres chiffres ?

Accepted Answer

En arrêtant de chercher le bon chiffre pour chercher la bonne définition. Dans la quasi-totalité des cas, deux services qui affichent un résultat différent calculent en réalité deux choses différentes : périmètre, date de référence ou statut retenu ne sont pas les mêmes. La première étape n'est donc pas technique mais lexicale — écrire, indicateur par indicateur, ce que chaque terme recouvre exactement, et qui en est responsable.

Question 44

Quels tests automatisés écrire en priorité sur une application métier ?

Accepted Answer

Trois familles, dans cet ordre : les tests des règles de gestion — celles qui coûtent de l'argent si elles se trompent ; les tests des parcours critiques de bout en bout, deux ou trois maximum ; et un test de non-régression pour chaque bug corrigé. Chercher un taux de couverture élevé est une mauvaise cible : une couverture de 40 % concentrée sur les règles métier protège mieux qu'une couverture de 80 % répartie uniformément.

Question 45

Comment prioriser un backlog quand toutes les demandes sont présentées comme urgentes ?

Accepted Answer

En remplaçant la question « est-ce urgent ? » par « que se passe-t-il si on ne le fait pas ce trimestre ? ». Cette reformulation fait apparaître le coût réel de l'attente, qui est souvent nul. Ensuite, imposez une contrainte de rareté : une liste ordonnée sans ex æquo, et une capacité affichée. Tant que plusieurs demandes peuvent être « prioritaires » simultanément, aucune priorisation n'a lieu.

Question 46

Comment reprendre la maintenance d'une application développée par un autre prestataire ?

Accepted Answer

Par un audit de deux à trois semaines avant tout engagement : capacité à reconstruire l'application depuis zéro, état des dépendances et des failles connues, couverture de tests, accès aux environnements, et qualité de la reprise de données. Le critère décisif n'est pas la propreté du code mais la capacité à déployer une correction en production en moins d'une journée. Tant qu'on ne sait pas faire ça, on ne peut pas s'engager sur des délais de rétablissement.

Question 47

Comment concevoir une application mobile qui fonctionne hors ligne ?

Accepted Answer

En considérant l'appareil comme la source de vérité temporaire et le serveur comme un point de synchronisation, pas l'inverse. Concrètement : une base locale sur le téléphone, une file d'opérations en attente rejouées à la reconnexion, un identifiant généré côté appareil pour ne pas dépendre du serveur, et une règle de résolution de conflits décidée avec le métier. Le hors ligne n'est pas une option qu'on ajoute — c'est une décision d'architecture qui doit être prise au début du projet.

Question 48

Que faut-il vérifier dans un contrat de développement d'application avant de signer ?

Accepted Answer

Sept points : la cession des droits sur le code (intégrale et sans condition), la documentation comme livrable contractuel, les conditions de réversibilité, la définition précise de la recette et de ses délais, le traitement des demandes de changement, les engagements de service après mise en production, et la propriété des données. L'absence d'une seule de ces clauses peut vous coûter plus cher que l'écart de prix entre deux prestataires.

Question 49

Quelles sont les erreurs de modélisation de base de données les plus fréquentes ?

Accepted Answer

Six reviennent constamment : absence de contraintes d'intégrité déléguées au code applicatif, suppression physique des enregistrements au lieu d'un archivage, stockage des dates sans fuseau horaire, montants en nombres flottants, statuts en texte libre sans référentiel, et absence d'index sur les colonnes de filtrage. Toutes se corrigent facilement au début du projet et deviennent très coûteuses une fois la base remplie.

Question 50

Comment organiser la recette d'une application avant sa mise en production ?

Accepted Answer

En la préparant avant le début du développement, pas à la fin. Il faut trois choses : des personnes nommées avec du temps réellement bloqué dans leur agenda, des scénarios écrits à partir de situations réelles plutôt qu'une liste de fonctionnalités, et un jeu de données représentatif incluant les cas tordus. Une recette improvisée en fin de projet ne trouve que les erreurs évidentes et laisse passer celles qui coûtent cher.

Question 51

Peut-on réutiliser un même logiciel pour plusieurs métiers différents ?

Accepted Answer

Oui, à condition de séparer dès le départ le socle technique du vocabulaire métier. Nous exploitons une même plateforme de gestion d'association sous quatre marques — Vibe-it pour les écoles de danse, Moove-IT pour les clubs sportifs, et deux autres verticales — avec un socle commun et des parcours propres à chaque univers. Ouvrir un nouveau marché coûte alors une fraction du coût initial.

Question 52

Combien de temps et quelles contraintes pour publier une application sur les magasins iOS et Android ?

Accepted Answer

Comptez deux à quatre semaines entre l'application finie et sa disponibilité publique, dont la moitié en préparation administrative. Apple relit chaque version manuellement — de quelques heures à plusieurs jours — et refuse pour des motifs souvent non fonctionnels : formulaire de confidentialité incomplet, connexion imposée sans justification, mécanisme de paiement hors du sien. Google publie plus vite mais impose une validation d'identité et des phases de déploiement progressif. Les comptes développeur, les certificats et les fiches produit doivent être créés au nom de l'entreprise, jamais d'une personne.

Question 53

Comment évaluer le coût de l'inaction sur un projet de digitalisation ?

Accepted Answer

En additionnant quatre postes rarement mesurés : le temps passé sur des tâches manuelles évitables, le coût des erreurs et de leur rattrapage, les occasions perdues faute de réactivité, et le risque de dépendance à une personne ou à un fichier unique. Ce coût est invisible parce qu'il est réparti et n'apparaît sur aucune ligne budgétaire — mais il se reconduit chaque année et augmente avec l'activité.

Question 54

Comment découper une fonctionnalité en tâches de développement ?

Accepted Answer

En tranches verticales qui traversent toutes les couches et produisent chacune quelque chose de démontrable, plutôt qu'en couches horizontales — base, puis service, puis interface. Chaque tranche doit être livrable en un à trois jours et apporter une valeur observable, même minime. Un découpage horizontal donne l'illusion d'avancer pendant des semaines sans que rien ne soit vérifiable.

Question 55

Qu'est-ce qu'un MVP et comment définir son périmètre ?

Accepted Answer

Un MVP est la plus petite version qui résout un problème réel de bout en bout pour un utilisateur, et dont on peut tirer un apprentissage. Ce n'est pas une version incomplète, ni une maquette, ni un prototype jetable : ce qu'il fait, il le fait correctement, en production. Le bon critère de découpage n'est pas « quelles fonctionnalités enlever » mais « quel utilisateur, sur quel cas, peut aller au bout sans nous ».

Question 56

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 57

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 58

Combien coûte le développement d'une application web métier sur mesure ?

Accepted Answer

Une application métier sur mesure se situe le plus souvent entre 50 000 € et 400 000 € pour une première version en production, selon le nombre d'interfaces avec l'existant, de profils utilisateurs et de contraintes réglementaires. Le budget de départ n'est pas le vrai sujet : il faut compter 15 à 25 % du coût initial par an pour l'exploitation et les évolutions, sans quoi l'application se dégrade en quelques mois.

Question 59

Sur quoi faut-il se concentrer lors d'une revue de code ?

Accepted Answer

Sur quatre choses, dans cet ordre : la gestion des cas d'erreur, les frontières entre modules, la lisibilité pour quelqu'un qui découvre le code, et la testabilité. Le style, le nommage et la mise en forme ne doivent pas être discutés en revue — ils relèvent de l'outillage automatique. Une revue qui parle surtout de style est une revue qui n'a pas regardé la conception.

Question 60

Combien de temps faut-il pour créer une application web métier ?

Accepted Answer

Comptez 1 à 3 mois entre le premier atelier et la mise en production d'une première version utilisable. Le cadrage prend 1 à 2 semaines, la conception 1 à 3 semaines, la construction 2 à 6 semaines par sprints de 2 semaines, et la mise en production 1 à 2 semaines. L'IA a divisé la durée de construction ; elle n'a rien changé au cadrage, à la décision ni à la reprise de données — qui occupent désormais la moitié du calendrier.

Question 61

Comment recruter et faire progresser une équipe de développement ?

Accepted Answer

En recrutant sur la capacité à apprendre et à travailler avec d'autres plutôt que sur la maîtrise d'une technologie précise, et en organisant la montée en compétence dans le travail réel : revue de code systématique, binômes sur les sujets difficiles, et rotation sur les parties du système. Les formations ponctuelles sans mise en pratique immédiate ne laissent presque rien. Le vrai facteur de progression est le temps d'exposition à du code relu par quelqu'un de plus expérimenté.

Question 62

Comment construire un dossier pour faire accepter un budget de développement applicatif ?

Accepted Answer

En chiffrant le coût de la situation actuelle avant de parler du coût du projet. Une direction ne compare pas un devis à zéro : elle compare deux coûts. Le dossier tient en une page — ce que la situation actuelle coûte chaque année, ce que le projet coûte en investissement et en fonctionnement, à partir de quand l'un compense l'autre, et ce qui se passe si l'on ne fait rien pendant deux ans.

Question 63

Comment automatiser la saisie de documents dans une application métier ?

Accepted Answer

En traitant l'extraction comme une aide à la saisie, pas comme un remplacement. OptiBot lit les documents de tiers payant et pré-remplit les dossiers : l'opérateur valide au lieu de ressaisir. Le point déterminant n'est pas la qualité du modèle d'extraction, mais la conception de l'écran de validation et le traitement des cas où la lecture échoue.

Question 64

Comment une équipe de développement utilise-t-elle concrètement l'IA pour produire du logiciel ?

Accepted Answer

Nous l'utilisons sur quatre tâches où le résultat est vérifiable : générer du code à partir d'une spécification écrite, écrire des tests, produire de la documentation, et faire une première passe de revue. Nous ne lui confions ni les décisions d'architecture, ni la modélisation des données, ni l'arbitrage de périmètre. La règle est simple : l'IA écrit ce qu'un humain peut vérifier en moins de temps qu'il n'en aurait mis à l'écrire.

Créer une application web,concrètement

Huit métiers, huit points de vue

Julien

Vincent

Ayoub

Alban

Julie

Oussama

Thomas

Ali

Un projet à cadrer ?

Créer une application web,
concrètement