Code Apps en production : CSP, ALM et leçons durement apprises

Construire une Code App en local est simple. La mettre en production, et la maintenir en fonctionnement fiable, c'est là que les vraies leçons se produisent. Cet article couvre les problématiques de production que la documentation officielle survole.

CSP : l'activation de janvier 2026

Le 30 janvier 2026, Microsoft a activé l'application de la Content Security Policy pour les Code Apps. Chaque requête vers un domaine externe non explicitement autorisé est désormais bloquée par défaut.

Cela a impacté de nombreuses équipes. Si votre application charge des polices depuis un CDN, appelle une API tierce, utilise un SDK JavaScript ou même affiche des images blob, elle risque de casser en production sans configuration CSP.

Comment configurer le CSP

Naviguez vers Admin Center > Environments > Settings > Security > Content Security Policy.

Directives courantes que vous devrez mettre à jour :

Stratégie de test CSP

1. Déployez d'abord dans un environnement de développement
2. Activez le mode report-only dans les paramètres CSP
3. Ouvrez les DevTools du navigateur > Console et recherchez les messages de violation CSP
4. Ajoutez chaque domaine bloqué à la directive appropriée
5. Testez minutieusement, puis passez en mode application
6. Répétez en QA avant de promouvoir en production

ALM : le pattern Connection Reference

La plus grande erreur d'ALM est de lier les Code Apps à des connexions spécifiques à un utilisateur pendant le développement. Ces connexions ne se transfèrent pas entre les environnements.

Le bon pattern

Utilisez des Connection References au lieu de connexions directes :

# Pendant la configuration du developpement
pac code add-data-source \
  --apiId shared_commondataservice \
  --connectionRef <connection-ref-id> \
  --solutionId <solution-id>

Les Connection References sont des composants de solution. Lorsque vous exportez une solution managée depuis DEV et l'importez en QA, l'environnement cible fournit ses propres connexions pour chaque référence. Aucun recâblage manuel nécessaire.

Le pipeline de déploiement

DEV:  pac code push --solutionName MySolution
      pac solution export --name MySolution --path ./export --managed

QA:   pac solution import --path ./export/MySolution_managed.zip
      (Configurer les mappings de connection ref si c'est le premier import)

PROD: Meme solution managee, meme processus

Particularités Dataverse à connaître

URL d'organisation null sur les connexions

C'est le problème de production le plus courant. Les connexions créées par pac code add-data-source ont souvent une URL d'organisation null, causant des retours de résultats vides par les méthodes de service standard, sans aucun message d'erreur.

Utilisez toujours les variantes de méthode WithOrganization :

// INCORRECT — peut retourner des resultats vides
MicrosoftDataverseService.ListRecords('accounts', ...);

// CORRECT — passe explicitement l'URL de l'organisation
MicrosoftDataverseService.ListRecordsWithOrganization(
  'https://your-org.crm.dynamics.com',
  'accounts',
  ...
);

Create retourne void

CreateRecordWithOrganization retourne void. Vous ne pouvez pas lire l'ID du nouvel enregistrement depuis la réponse. Utilisez un pattern query-after-create avec des retries pour tenir compte du délai de réplication Dataverse (~500ms) :

async function retryFind<T>(
  fn: () => Promise<T>,
  maxRetries = 3,
  delayMs = 500
): Promise<T> {
  for (let i = 0; i < maxRetries; i++) {
    if (i > 0) await new Promise(r => setTimeout(r, delayMs));
    const result = await fn();
    if (result) return result;
  }
  return fn();
}

Identifiants invalides dans le code généré

Le générateur de code peut produire des identifiants TypeScript avec des points (par exemple, MSCRM.IncludeMipSensitivityLabel), ce qui n'est pas du TypeScript valide. Corrigez en remplaçant les points par des underscores dans le fichier généré.

Checklist pré-déploiement

Avant chaque déploiement en production :

• npm run build se termine sans erreur
• Aucune instruction console.log dans le code de production
• WithOrganization utilisé pour tous les appels Dataverse
• Connection References (pas de connexions directes) pour toutes les sources de données
• CSP : tous les domaines externes autorisés dans l'environnement cible
• Taille du bundle < 500 Ko gzip (utilisez le code splitting avec React.lazy)
• Thèmes sombre et clair testés (si applicable)
• Navigation clavier fonctionnelle pour tous les éléments interactifs
• Error boundaries sur les composants critiques
• Testé avec un compte utilisateur non-admin
• Mise en page responsive vérifiée (desktop + tablette minimum)
• Version React 18.x ou 19.x (les deux sont supportées)

En résumé

Les Code Apps en production sont fiables une fois que vous connaissez les pièges : configuration CSP, Connection References pour l'ALM, et le pattern WithOrganization pour Dataverse. La plateforme gère l'authentification, l'hébergement et la gouvernance : votre travail est de bien configurer la couche de données et de garder le bundle léger.

Pour la référence technique complète, consultez :

Le guide complet des Power Apps Code Apps

Sources

• Configure CSP for Code Apps - Microsoft Learn
• ALM Guide for Code Apps - Microsoft Learn
• Power Apps Code App with Dataverse: Building CRUD Operations - Rajeev Pentyala
• Retrieve Dataverse Records in Power Apps Code App - Alphavima
• Code Apps Office Hours Highlights - Tim Leung, Power Apps Guide