Un créateur d'applications par IA suffit-il pour React et Flutter ?

Créer un client web React et un client mobile Flutter avec deux outils d'IA distincts paraît raisonnable jusqu'au premier changement d'une règle commune. Un outil met alors à jour le parcours dans le navigateur, l'autre conserve l'hypothèse de la veille, et la base de données accepte les deux versions. La division du travail apparente s'est transformée en travail d'intégration.

Pour la plupart des petites équipes, un seul créateur d'applications par IA constitue le meilleur choix, à condition qu'il puisse produire des bases de code séparées pour React, Flutter et le backend, fournir le code source et publier chaque client indépendamment. "Un seul outil" doit signifier un contexte de planification et un contrat système communs. Cela ne doit pas vouloir dire une application monolithique, un seul cycle de publication ou une tentative de partager du code d'interface entre TypeScript et Dart.

L'autre solution peut fonctionner. Deux outils spécialisés ont du sens quand des équipes web et mobile distinctes possèdent déjà leurs clients, que le contrat d'API est géré en dehors des deux outils et que l'organisation accepte le coût de coordination. Sans ces conditions, le second outil ajoute une frontière que quelqu'un devra surveiller pendant toute la vie du produit.

Faut-il un créateur d'applications par IA ou deux ?

Choisissez un seul outil lorsque le même produit, le même backend, le même modèle de données et le même système d'identité servent les deux clients. N'en choisissez deux que si la spécialisation par plateforme vaut davantage que le contexte partagé et si des personnes sont chargées d'entretenir la frontière.

Les notes ci-dessous supposent un fondateur ou une petite équipe produit, une API Go, une base PostgreSQL, un client web React et un client mobile Flutter. Une note de 5 signifie que l'approche traite le sujet avec peu de coordination manuelle. Une note de 1 signifie que l'équipe doit créer et surveiller elle-même la liaison manquante.

Ces chiffres aident à décider, ils ne comparent pas des produits. Si un candidat ne peut pas exporter le code source, modéliser un vrai backend ou séparer les déploiements web et mobile, baissez fortement sa note. À l'inverse, une configuration à deux outils peut gagner des points si une équipe plateforme expérimentée possède le contrat d'API, le service d'identité, la politique de publication et les tests de compatibilité.

Ne comptez ni les écrans ni les prompts. Comptez les autorités. Il faut une autorité pour chaque fait métier, un contrat d'API, une politique d'identité et une séquence de migration. React et Flutter consomment ces décisions.

La logique métier commune appartient au backend

Placez dans le backend les autorisations, les règles tarifaires, les transitions de workflow, les quotas et les validations qui protègent les données enregistrées. React et Flutter peuvent répéter des contrôles légers pour répondre rapidement, mais l'API doit prendre la décision finale.

Les équipes appellent souvent "logique partagée" deux choses différentes. Partager le code source signifie que les deux clients importent la même implémentation. Partager le comportement métier signifie qu'ils reçoivent le même résultat d'une seule autorité. React et Flutter utilisent des langages et des modèles d'interface différents. Forcer une implémentation commune crée donc souvent une troisième abstraction, plus difficile à comprendre que chaque client. Partagez le comportement par l'API.

Imaginons qu'une commande ne puisse passer de draft à submitted que si elle contient au moins une ligne et si le compte est actif. Si chaque client possède cette règle, quatre versions apparaissent vite : le contrôle du formulaire React, l'état du bouton Flutter, le gestionnaire d'envoi web et le gestionnaire mobile. Toute modification de la règle doit arriver partout avant la sortie d'un client. Une ancienne version mobile peut rester installée pendant des mois.

Le backend doit exposer l'action autorisée et la vérifier à nouveau lorsqu'elle arrive :

{
  "order_id": "ord_4821",
  "status": "draft",
  "allowed_actions": ["submit"],
  "version": 7
}

Les clients choisissent comment afficher l'action. Le serveur décide si submit est autorisé à la version 7. Si une autre requête modifie d'abord la commande, le serveur renvoie un conflit au lieu de laisser silencieusement gagner la dernière écriture.

La documentation React recommande une source unique de vérité pour chaque état. Ce conseil concerne l'arbre de composants du navigateur, pas tout un produit à plusieurs clients. Le parent commun d'une application web et d'une application mobile est le contrat du backend. Y placer l'état métier durable applique la même idée à la frontière du système.

Le guide d'architecture de Flutter sépare les vues et modèles de vue des dépôts et services. Il indique aussi que les services enveloppent les points d'accès des API externes et que les dépôts transforment leurs résultats en modèles de domaine. C'est une bonne frontière côté client. N'interprétez pas un dépôt comme une permission de reconstruire la politique du serveur en Dart. Un dépôt mobile peut mettre en cache, réessayer et transformer des données ; il ne doit pas devenir une deuxième autorité pour décider si une commande peut être envoyée.

Certaines logiques restent légitimement propres au client : formatage des saisies, présentation hors ligne, navigation, animation et gestion des permissions de l'appareil. Une application mobile peut mettre un brouillon en attente hors connexion, tandis que le web enregistre immédiatement. Une fois connectés, les deux doivent envoyer la même commande à la même règle serveur.

PostgreSQL doit rester derrière une API

Ni un paquet React ni une application Flutter ne doivent se connecter directement à PostgreSQL. Ce sont des clients distribués dont le code et les informations de connexion peuvent être inspectés, copiés et modifiés par les utilisateurs.

Le manuel PostgreSQL décrit l'authentification du client comme la décision prise par le serveur de base de données d'autoriser ou non un client à se connecter avec l'utilisateur demandé. Ce mécanisme protège une connexion à la base. Il ne comprend pas qu'Alice peut modifier la commande 42 mais pas la 43, ni qu'une ancienne version mobile ne doit pas employer une nouvelle transition. L'autorisation applicative appartient à l'API.

Une connexion directe depuis React est particulièrement intenable : le navigateur aurait besoin d'un accès réseau à la base et d'identifiants dans le code téléchargé. Emballer un mot de passe dans Flutter ne le cache que jusqu'à l'extraction de l'application. La sécurité par ligne peut ajouter une défense dans PostgreSQL, mais elle ne transforme pas un client non fiable en pair sûr de la base de données. Il faut toujours des points d'accès stables, des limites de débit et de saisie, un contexte d'audit et un endroit où faire évoluer les schémas sans casser les versions installées.

Utilisez une topologie avec une seule frontière applicative publique :

React client  \n               -> HTTPS API -> domain rules -> PostgreSQL
Flutter client /

Donnez à l'API un rôle de base de données restreint. Gardez les identifiants de migration hors de l'application en cours d'exécution. Exécutez les migrations comme une tâche de déploiement séparée, avec son propre examen et son propre plan de récupération. Cette séparation limite ce qu'un processus d'API compromis peut faire et empêche les clients de connaître les identifiants de la base.

Deux outils d'IA produisent parfois deux backends parce que chacun veut livrer un projet complet. Refusez ce résultat, sauf si deux services forment une séparation volontaire du domaine. Un backend web et un backend mobile qui écrivent dans les mêmes tables créent une autorisation dupliquée, des transactions incohérentes et deux endroits à réparer pour chaque évolution de schéma. Un adaptateur backend léger par client peut être pertinent lorsque les formes de réponse diffèrent, mais ces adaptateurs doivent appeler le même service de domaine plutôt que le contourner.

Testez la frontière avec une vérification simple et efficace. Cherchez dans les dépôts React et Flutter les chaînes de connexion PostgreSQL, variables d'hôte de base, pilotes SQL et identifiants de service privilégiés. Toute présence dans le code client fait échouer la revue d'architecture. La configuration attendue d'un client ne contient qu'une URL de base d'API, une configuration publique d'identité et des réglages fonctionnels non secrets.

Les migrations de base ont aussi besoin de rétrocompatibilité. Ajoutez d'abord une colonne nullable ou une nouvelle table, déployez un code qui gère les deux formes, remplissez les données si nécessaire, basculez les lectures et ne supprimez l'ancien champ qu'une fois que les clients pris en charge n'en dépendent plus. La distribution mobile allonge cette dernière période au-delà de ce qu'imaginent la plupart des équipes uniquement web.

L'authentification a une autorité et deux adaptateurs

Utilisez un émetteur d'identité, un enregistrement utilisateur et une politique d'autorisation côté serveur, puis créez des adaptateurs de session distincts pour le navigateur et le mobile. L'authentification prouve qui appelle. L'autorisation décide ce que cet appelant peut faire. Les confondre produit des points d'accès qui acceptent un jeton valide, puis font confiance au client pour masquer les actions interdites.

Le client React gère généralement les redirections du navigateur, les cookies ou jetons, la protection contre les requêtes entre sites et les onglets qui peuvent se concurrencer pendant le renouvellement. Flutter doit gérer les liens profonds, la suspension de l'application, le stockage de l'appareil et les callbacks du système. Ces différences justifient du code client distinct. Elles ne justifient pas des annuaires utilisateurs séparés ni des rôles aux sens différents.

La fiche Mobile Application Security d'OWASP déconseille les identifiants intégrés au code et recommande des jetons d'accès sûrs et révocables, stockés avec des mécanismes propres à la plateforme. Suivez le principe, mais comprenez ses limites. Le stockage sécurisé réduit le vol occasionnel de jetons dans les fichiers. Il ne rend pas un appareil compromis fiable. L'API vérifie donc l'expiration, l'audience, l'émetteur, l'état du compte et l'autorisation à chaque opération protégée.

Rédigez le contrat d'authentification avant de demander aux clients de créer leurs écrans :

Access token: short lived, sent to the API
Refresh mechanism: rotated or invalidated by the identity system
Logout: ends the local session and revokes server-side refresh authority
Account disabled: API rejects new operations even if a client still shows cached data
Role changed: next authorized request uses current server policy

Le test le plus révélateur n'est pas une connexion réussie. Désactivez un compte alors que les deux clients sont ouverts. La requête protégée suivante doit échouer de la même façon dans chacun, les données privées locales doivent être effacées selon la politique et aucun client ne doit boucler sans fin sur le renouvellement. Modifiez ensuite un rôle et vérifiez qu'un écran obsolète ne peut pas effectuer l'ancienne action.

Évitez de placer la vérité des rôles dans les attributs du jeton plus longtemps que vous ne pouvez tolérer une autorisation périmée. Ces attributs peuvent accélérer l'affichage, mais le serveur doit consulter la politique actuelle pour les opérations sensibles. Si un changement de rôle doit prendre effet immédiatement, un jeton autonome à longue durée de vie contenant les anciens rôles va à l'encontre de cette exigence.

Un outil obtient ici 4 plutôt que 5, car le contexte partagé ne supprime pas le travail de sécurité propre aux plateformes. Il peut générer les deux adaptateurs, mais une personne doit encore tester les redirections web, les liens profonds mobiles, les courses de renouvellement, le décalage des horloges, la révocation et la restauration d'appareil.

Un contrat maintient React et Flutter cohérents

Traitez la description d'API comme une entrée de compilation pour les deux clients et une promesse de compatibilité envers les versions publiées. Un prompt en prose n'est pas un contrat, car deux générations peuvent interpréter différemment la même phrase.

OpenAPI est un choix pratique pour les API HTTP. Définissez les champs des requêtes et réponses, les corps d'erreur, les exigences d'authentification et des identifiants d'opération stables. Générez ou maintenez de minces clients TypeScript et Dart depuis ce document, puis conservez le comportement applicatif dans des hooks React et des dépôts Flutter ordinaires. Le code client généré doit rester remplaçable ; n'y enfouissez pas les décisions produit.

Cet extrait rend explicite un conflit de version :

/orders/{orderId}/submit:
  post:
    operationId: submitOrder
    requestBody:
      required: true
      content:
        application/json:
          schema:
            type: object
            required: [expected_version]
            properties:
              expected_version:
                type: integer
    responses:
      "200":
        description: Order submitted
      "409":
        description: Order changed since the client loaded it

La source de vérité est le comportement du serveur avec le contrat contrôlé. Les types TypeScript et Dart générés en sont des projections. Si un outil modifie un type côté client sans changer le contrat, la compilation doit écraser ou rejeter cette modification.

Les tests de contrat doivent exercer les comportements qu'un schéma statique ne peut pas exprimer. Envoyez une commande vide et attendez le même code d'erreur pour les requêtes créées par les deux clients. Rejouez une requête avec une ancienne expected_version et attendez 409. Envoyez une valeur d'énumération inconnue à un ancien client de test et vérifiez qu'il adopte un comportement sûr au lieu de planter.

Préférez les changements d'API additifs. De nouveaux champs de réponse facultatifs sont généralement sûrs lorsque les clients ignorent les champs inconnus. Supprimer un champ, rendre obligatoire un champ facultatif ou réutiliser une valeur d'énumération avec un nouveau sens peut casser une version mobile installée. Ne versionnez un point d'accès que si vous ne pouvez pas préserver son sens ; les changements de version systématiques déplacent seulement le poids de la compatibilité dans davantage de dossiers.

Une recommandation populaire propose de partager les modèles de domaine dans un paquet multiplateforme. Elle semble efficace puisque commande, compte et facture existent dans les deux clients. En pratique, les paquets TypeScript et Dart ont tout de même besoin de comportements de sérialisation, de gestion des valeurs nulles, de dates et d'outils de publication distincts. Générez les formes de transport depuis un contrat, puis laissez chaque client les transformer en modèles d'interface locaux. Les définitions communes sont utiles. Un modèle d'exécution commun imposé ne l'est pas.

Un contrat rend aussi deux outils plus viables. Il donne à chacun une frontière qu'il ne peut pas réinterpréter à la légère. Mais quelqu'un en dehors des deux sessions de génération doit posséder les changements de contrat, les contrôles de compatibilité et les notes de publication. Si personne n'occupe ce rôle, le contrat prendra du retard sur les implémentations.

Les cycles de publication doivent rester indépendants

Publiez le client web, le client mobile et l'API selon des calendriers séparés, même si un seul outil crée les trois. Une génération coordonnée n'impose pas un déploiement coordonné.

React peut atteindre les utilisateurs quelques minutes après le déploiement. Les versions mobiles passent par l'examen des boutiques et les utilisateurs peuvent reporter leur mise à jour. L'API doit donc prendre en charge la version web actuelle et toutes les versions mobiles encore dans la période de support. Un plan qui suppose une mise à jour simultanée échouera au premier examen retardé ou déploiement progressif.

Utilisez une matrice de compatibilité pour chaque changement :

Les mots dans les cellules comptent plus que les numéros de version. Ils obligent l'équipe à préciser ce que fait réellement un ancien client. Conservez la matrice dans le plan de changement et transformez ses affirmations en tests quand c'est possible.

Une publication de fonctionnalité sûre suit souvent cet ordre :

1. Ajoutez des structures de base de données et un comportement d'API rétrocompatibles.
2. Publiez des clients qui comprennent la nouvelle réponse, mais gardent la fonctionnalité masquée.
3. Observez les erreurs et les signaux de compatibilité avant d'autoriser les écritures.
4. Activez la fonctionnalité avec une capacité contrôlée par le serveur ou un réglage de compte.
5. Supprimez les anciens chemins seulement après la fin de la période de support.

Les drapeaux de fonctionnalité servent à contrôler l'exposition, pas à réparer un schéma incompatible. Si un ancien client plante en analysant un nouveau champ obligatoire ou une valeur d'énumération, masquer un bouton après le démarrage ne le sauvera pas. La compatibilité appartient à la conception des données échangées.

Deux outils peuvent être performants pour le packaging propre à chaque plateforme. Un outil mobile peut mieux connaître les métadonnées des boutiques et les droits de l'appareil, tandis qu'un outil web peut bien gérer le déploiement dans le navigateur. N'augmentez la note de publication de l'approche à deux outils que si ces forces dépassent le travail supplémentaire de coordination de l'API, de l'exposition des fonctionnalités et des périodes de support.

Rendez les identifiants de version visibles dans les journaux et rapports d'erreur. Chaque requête d'API doit transmettre un nom de client et un identifiant de build non secrets afin que les équipes d'exploitation distinguent une régression du navigateur d'un vieux comportement mobile. Ne faites pas confiance à cet identifiant pour l'autorisation, car un client peut le falsifier.

Un retour arrière a trois sens différents

Le retour du client, celui du serveur et celui des données répondent à des pannes différentes et exigent des procédures séparées. Les traiter comme un seul bouton "annuler" transforme facilement une publication récupérable en perte de données.

Un déploiement React peut généralement rediriger le trafic vers un artefact précédent. Un retour mobile consiste souvent à arrêter un déploiement progressif et à soumettre un build corrigé ; les appareils déjà mis à jour peuvent garder la version défectueuse. L'API doit tolérer les deux pendant cet intervalle.

Le code serveur ne peut revenir en arrière que si la base reste compatible avec l'ancien binaire. Une migration additive le permet souvent. Une migration qui renomme une colonne sur place, en change le sens ou supprime des données peut l'interdire. Utilisez des migrations d'expansion puis de contraction : ajoutez la nouvelle représentation, laissez les deux versions de code fonctionner, déplacez les données, changez les lectures et supprimez plus tard l'ancienne représentation.

Le retour des données est le plus dangereux. Restaurer un instantané de la base efface les écritures valides effectuées après celui-ci. Pour de nombreux incidents en production, une réparation vers l'avant est plus sûre : déployez le code corrigé, repérez les lignes touchées avec une requête d'audit et appliquez une correction compensatoire ciblée. Les instantanés protègent contre les catastrophes, mais ne remplacent pas sans précaution une migration réversible.

Prenons une panne typique. Le déploiement de l'API ajoute delivery_window comme champ obligatoire. Le nouveau client web l'envoie. Le build mobile en cours d'examen ne l'envoie pas. L'équipe passe la colonne à NOT NULL et les soumissions des anciens mobiles commencent à produire des erreurs serveur. Revenir uniquement sur le client web ne change rien. Revenir uniquement sur l'API peut échouer si l'ancien binaire ne lit pas le nouveau schéma. Restaurer toute la base supprimerait des commandes sans rapport.

La récupération propre consiste à faire accepter le champ absent par l'API, à définir une valeur par défaut documentée ou à reporter la transition, puis à renvoyer le champ comme facultatif jusqu'à ce que la prise en charge mobile soit assez répandue. L'équipe peut ensuite réparer les enregistrements touchés sans annuler les autres écritures. L'erreur initiale n'était pas l'absence d'un bouton de retour. C'était une séquence incompatible.

Avant chaque déploiement, écrivez ces quatre lignes :

Web rollback: artifact and routing action
Mobile containment: rollout stop, affected builds, fixed build path
API rollback: compatible binary and schema range
Data repair: query, owner, backup point, and forward correction

Un seul outil aide si ses instantanés et son historique de planification couvrent le changement lié, mais vérifiez leur portée. Un instantané du code source, un artefact déployé et une sauvegarde PostgreSQL sont des éléments différents. Un test convaincant restaure chacun dans un environnement jetable et prouve que l'ancien client peut encore terminer son écriture principale.

Deux outils augmentent la responsabilité d'intégration

Deux outils ne divisent pas la maintenance par deux. Ils créent deux historiques de génération, deux ensembles d'hypothèses et une surface d'intégration située en dehors des deux.

Le premier mois peut paraître plus rapide, car chaque outil produit un code familier pour sa plateforme. Le coût apparaît quand un changement franchit la frontière : renommer un champ, modifier une permission, ajouter un état de compte, changer la déconnexion ou retirer un point d'accès. Chaque prompt doit contenir le contrat actuel et les conséquences de l'état de publication de l'autre client. Un seul détail manquant produit un code plausible qui compile tout en violant le comportement du produit.

Le scénario de panne est prévisible. L'outil web ajoute archived à une énumération et l'affiche correctement. L'outil mobile traite encore toute valeur inconnue comme une erreur d'analyse. L'API est déployée d'abord, un enregistrement archivé apparaît dans la liste d'un utilisateur et l'écran mobile ne charge plus aucun enregistrement. Chaque changement local semblait raisonnable. Personne n'a testé la combinaison entre versions.

La maintenance a besoin d'un responsable et d'un dossier de changement reproductible :

• Le changement de comportement et la règle serveur qui le possède
• Les différences d'API et de migration
• Les cas d'acceptation React
• Les cas d'acceptation Flutter
• L'ordre de publication et les limites de retour

Ce dossier est également utile avec un seul outil, mais un contexte de planification peut le garder attaché à tout le changement. Avec deux outils, l'équipe doit le copier, enregistrer les deux résultats et réconcilier les modifications contradictoires. L'automatisation peut détecter une dérive du schéma ; elle ne peut pas décider quelle interprétation correspond au produit.

Ne supposez pas que l'export du code met fin à la dépendance envers l'outil. Le code exporté vous en donne la garde, ce qui compte, mais sa maintenance dépend d'une structure lisible, de tests, des dépendances, des instructions de build et d'un moyen propre de ne régénérer que ce qui a changé. Examinez un projet généré comme si l'outil disparaissait demain. Un développeur React compétent peut-il publier le web, un développeur Flutter construire l'application mobile et un développeur backend migrer PostgreSQL sans l'historique du chat ?

Mesurez la maintenance avec des preuves ordinaires : échecs de tests de contrat, temps passé à réconcilier les changements générés, modifications manuelles perdues pendant une régénération, versions clientes non prises en charge et résultats des exercices de récupération. Évitez une mesure flatteuse telle que le nombre de lignes partagées. Un peu de duplication dans la transformation de présentation peut coûter moins cher qu'une couche de partage ingénieuse.

Deux outils deviennent raisonnables quand deux équipes fonctionnent déjà ainsi. Chacune possède son client, une équipe plateforme possède l'API et l'identité, et les tests de compatibilité automatiques s'exécutent avant la publication. Dans ce cas, les outils correspondent à l'organisation. Un fondateur seul ne doit pas imiter un organigramme qu'il n'a pas.

Comment prendre la décision ?

Choisissez l'approche en prouvant un changement commun aux deux clients, pas en comparant la vitesse à laquelle chaque outil dessine le premier écran. L'essai doit inclure un changement de schéma, une règle d'autorisation, une ancienne version mobile, des publications indépendantes et une répétition du retour arrière.

Demandez aux candidats à un seul outil de créer une petite tranche verticale : les clients React et Flutter envoient la même commande à une API Go soutenue par PostgreSQL. Modifiez la règle après le bon fonctionnement des deux clients. Ajoutez un champ facultatif, refusez un rôle, ne publiez que le changement web et restaurez l'ancien artefact serveur sans perdre de nouvelles lignes. Exportez le code source et lancez ses tests en dehors de l'interface de l'outil.

Demandez aux candidats à deux outils d'exécuter la même séquence avec un document OpenAPI contrôlé fourni aux deux. Mesurez le nombre de faits à copier entre les sessions et la fréquence à laquelle un outil modifie ce qui se trouve hors de sa frontière. Comptez le temps nécessaire pour diagnostiquer les divergences, pas seulement celui de la génération.

Utilisez un seul outil s'il passe ces contrôles :

• Il crée des projets React, Flutter et backend séparés autour d'un contrat.
• Il garde PostgreSQL derrière le backend et les secrets hors des clients.
• Il permet des publications indépendantes des clients et du serveur.
• Il expose le code source, l'état de déploiement et des points de récupération distincts.
• Son code généré peut être construit et testé sans dépendre de l'historique du chat.

Choisissez-en deux lorsqu'une capacité spécialisée change réellement le résultat mobile ou web et qu'une personne nommée possède la gouvernance du contrat. "La sortie mobile était plus jolie" ne suffit pas. L'intégration aux appareils, l'accessibilité, le packaging pour les boutiques, le fonctionnement hors ligne ou une compétence existante de l'équipe peuvent suffire si le bénéfice résiste au calcul de maintenance.

Koder.ai peut générer des applications React, Go avec PostgreSQL et Flutter depuis un même contexte de chat, avec un mode de planification, l'export du code source, le déploiement et l'hébergement, les instantanés et le retour arrière. Cet ensemble correspond à l'architecture à un seul outil décrite ici, mais exécutez tout de même le test vertical, car une liste de fonctions ne prouve pas votre chemin de publication et de récupération.

La décision peut changer plus tard. Un système bien délimité permet à l'équipe de remplacer le générateur React, le générateur Flutter ou les deux sans déplacer les règles métier hors de l'API. La première architecture doit préserver cette possibilité.

Le test inconfortable est simple : si l'outil mobile disparaissait le jour de la publication, pourriez-vous expliquer le contrat d'API actuel, construire le client exporté et continuer à publier ? Si la réponse dépend de prompts mémorisés, corrigez le modèle de responsabilité avant d'ajouter un outil.