Livrer
Les quatre types de projets, la signature de code Windows et les outils de projet. De la version testée à l’application entre les mains de vos utilisateurs.
10. Builds et déploiement
Le type de projet se choisit à sa création et détermine le livrable. Les capacités optionnelles (FTP, email, stockage cloud, SMS, base externe) ne sont embarquées que si le projet les utilise réellement.
Trois modes de génération pour une application Windows
Le mode se choisit à chaque génération, selon ce que vous avez à faire : équiper un poste, faire tester un binaire, ou corriger une installation déjà en place.
11. Signature de code Windows
Quatre niveaux configurables par projet, pour éliminer l'avertissement SmartScreen « Éditeur inconnu » selon le contexte de diffusion.
12. Outils de projet
Ce que la plateforme prend en charge autour du code lui-même.
Un instantané de la structure du projet, à reprendre en cas de fausse manœuvre. Vingt au maximum, les plus anciens étant remplacés. La base de données n'en fait pas partie.
Compare deux états du projet et montre ce qui a changé, fenêtre par fenêtre et requête par requête.
Les dix dernières générations restent retéléchargeables sans tout reconstruire. Au-delà, les plus anciennes sont purgées avec leurs fichiers.
Un export du projet en PDF ou en Markdown, sections au choix. Le PDF est produit par capture des pages : c'est un document à lire et à diffuser, pas un texte cherchable.
Des étapes de déploiement déclenchées avant ou après la génération : copier un fichier, injecter une configuration, lancer un script, envoyer le paquet. Définies dans le projet, donc partagées en équipe via Git.
Importez un dépôt existant comme projet, committez et poussez vos changements. Le projet est nativement versionnable.
Détecte les fenêtres les plus lourdes (nombre de contrôles, poids du code et des médias) et alerte au-delà de seuils définis.
Signale à la frappe un champ ou une fenêtre renommé·e ou supprimé·e, une méthode inexistante pour ce type, ou du code sans effet. Un correctif « Renommer en » se propose directement sur la référence cassée.
Une rubrique liée à une colonne renommée ou supprimée en base, ou une référence à une couleur de projet supprimée, remontent dans le centre de diagnostics (sévérités critique/élevé/moyen/faible).
Points d'arrêt posés dans le code, suspension en mode Test, inspection des variables locales à l'endroit précis de l'arrêt.
Une requête SQL se teste sans être enregistrée au préalable, un point d'accès webservice se teste avec req/body saisis à la main, sans redéploiement.
Si des erreurs du centre de diagnostics restent non résolues, le build demande une confirmation explicite avant de continuer.
Contraste insuffisant, image sans texte alternatif, champ obligatoire sans libellé visible, texte trop petit. Même panneau de diagnostics.
Une table clé vers texte par langue, un sélecteur d'aperçu dans l'éditeur, un changement de langue pilotable à l'exécution, embarqué dans les applications livrées.
Les dix derniers builds restent téléchargeables. Un point de restauration fige la structure du projet, sans toucher aux données réelles.
Traces envoyées par Trace.ecrire et par le runtime du projet, regroupées par jour.
Compare le projet courant avec un point de restauration existant, section par section.
Checklist adaptée à la cible du projet, web, desktop ou mobile, avant build ou déploiement.
Menu Projet → Documentation technique. Sélectionnez les sections (fenêtres et code d'événements, gabarits, base de données, requêtes, états, classes, webservices, code global, rôles, traductions), puis imprimez ou exportez en PDF.