Un rapport Crystal passe du designer à une application métier via une COLLABORATION entre concepteur et développeur : le concepteur crée le fichier .rpt, le développeur l'intègre dans l'application par le code — voici le parcours. Le principe de séparation des rôles : (1) Le CONCEPTEUR d'états crée le rapport dans le DESIGNER Crystal Reports : il conçoit la mise en page, les champs, les formules, les regroupements, les paramètres, et sauvegarde un fichier .RPT (le modèle de rapport). Il n'écrit pas de code applicatif. (2) Le DÉVELOPPEUR intègre ce .rpt dans l'APPLICATION (un logiciel de gestion, un ERP, une appli web) via le SDK Crystal Reports (par exemple Crystal Reports for Visual Studio, gratuit, pour .NET). Il écrit le code qui charge et affiche le rapport. Le parcours (côté développeur, grandes lignes) : (1) Référencer les composants Crystal Reports dans le projet (.NET). (2) Placer un CrystalReportViewer (le composant d'affichage) sur une page ou une fenêtre de l'application. (3) Charger le .rpt par code (indiquer le fichier de rapport à afficher). (4) Fournir la CONNEXION : passer les informations de connexion à la base (serveur, identifiants) par code — pour que le rapport puisse récupérer les données dans le contexte de l'application (sans coder les mots de passe en dur). (5) Passer les PARAMÈTRES : donner par code les valeurs des paramètres du rapport (par exemple, l'ID de la facture à imprimer, choisi dans l'application). (6) Lier le rapport au viewer : le rapport s'affiche alors dans l'application, avec les boutons d'impression et d'export intégrés. (7) Éventuellement, EXPORTER par code (générer un PDF automatiquement, l'attacher à un e-mail) sans même afficher le rapport. Le résultat concret : dans un logiciel de gestion, un bouton « Imprimer la facture » exécute ce code — il charge le rapport de facture (.rpt), lui passe l'ID de la facture concernée en paramètre, récupère les données, et affiche/imprime/exporte la facture. L'utilisateur final consomme le rapport SANS jamais ouvrir le designer Crystal Reports. C'est ainsi que d'innombrables applications de gestion produisent leurs factures, relevés, bons de commande, etc. Les points importants : (1) Collaboration : le concepteur (métier, mise en page des états) et le développeur (intégration, code) travaillent ensemble — deux compétences complémentaires. Un concepteur peut créer d'excellents .rpt sans savoir coder ; le développeur les intègre. (2) Connexion et sécurité : le développeur fournit les identifiants de base par code, sans les coder en dur (sécurité). (3) Paramètres : l'application passe les paramètres programmatiquement (l'utilisateur ne saisit pas forcément d'invite ; l'appli fournit les valeurs selon le contexte). (4) DÉPLOIEMENT du runtime : les composants d'exécution Crystal Reports (le « runtime ») doivent être installés sur les postes/serveurs qui exécutent l'application — étape à ne pas oublier (sinon les rapports ne s'affichent pas). (5) Technologies : Crystal Reports for Visual Studio (gratuit) pour .NET ; des SDK Java existent ; et SAP BusinessObjects pour la diffusion en entreprise (planification, portail). En résumé : un rapport Crystal passe du designer à une application métier par une collaboration — le CONCEPTEUR crée le fichier .RPT (mise en page, formules, paramètres) dans le designer, et le DÉVELOPPEUR l'INTÈGRE dans l'application via le SDK : il place un CrystalReportViewer, charge le .rpt par code, fournit la connexion et les paramètres, et l'affiche (impression/export intégrés). L'utilisateur final génère alors des états (factures, relevés) depuis l'application, sans le designer. Il faut aussi déployer le runtime Crystal sur les machines cibles. Cette intégration — travail de développeur s'appuyant sur les rapports du concepteur — explique l'omniprésence de Crystal Reports comme moteur d'états dans les logiciels de gestion.

L'intégration applicative demande des compétences de DÉVELOPPEMENT, mais la CONCEPTION des rapports n'en demande pas — concepteur et développeur ont des rôles distincts et complémentaires. Faut-il être développeur ? (1) Pour CONCEVOIR des rapports (créer les .rpt) → NON. Le designer Crystal Reports est un outil VISUEL, accessible à des profils métier (gestionnaires, analystes, comptables) sans compétences de programmation. On crée des états — même complexes (formules, regroupements, sous-rapports) — sans écrire de code applicatif. La conception d'états est un métier en soi, distinct du développement logiciel. (2) Pour INTÉGRER les rapports dans une application → OUI. Embarquer un rapport dans un logiciel (.NET, Java), gérer le viewer, la connexion par code, le passage de paramètres, le déploiement du runtime — cela demande des compétences de DÉVELOPPEUR. C'est du code applicatif. Donc : concevoir des états n'exige pas d'être développeur ; les intégrer dans une application, oui. Comment concepteur et développeur COLLABORENT : (1) Le CONCEPTEUR d'états : crée et maintient les rapports (.rpt) dans le designer — mise en page, champs, formules, regroupements, paramètres, mise en forme. Il connaît le BESOIN MÉTIER (quelles données, quelle présentation) et livre des fichiers .rpt prêts à l'emploi. Il peut modifier un rapport (ajuster une colonne, une formule) sans toucher au code de l'application — un gros avantage (les états évoluent sans redéveloppement). (2) Le DÉVELOPPEUR : intègre ces .rpt dans l'application (charger le rapport, viewer, connexion, paramètres, export, déploiement du runtime). Il connaît l'APPLICATION et le code. Il définit COMMENT les rapports sont appelés (quel bouton, quels paramètres passés selon le contexte). (3) L'interface entre les deux : le fichier .RPT et le contrat sur les PARAMÈTRES. Le concepteur définit les paramètres attendus (l'ID de facture, la période) ; le développeur fournit leurs valeurs par code depuis l'application. Ils s'accordent sur les paramètres, les champs, la source de données. Les avantages de cette séparation : (1) SPÉCIALISATION : chacun fait ce qu'il maîtrise — le concepteur (métier, présentation), le développeur (intégration, code). (2) MAINTENANCE des états sans redévelopper : modifier un rapport (une mise en forme, une formule, une colonne) se fait dans le .rpt par le concepteur, souvent sans changer le code de l'application (il suffit de remplacer le .rpt). Les états évoluent indépendamment du logiciel — un atout majeur de Crystal Reports pour les applications métier. (3) PRODUCTIVITÉ : les experts métier produisent les états, les développeurs se concentrent sur l'application. En pratique : (1) Si vous êtes un profil MÉTIER, vous pouvez CONCEVOIR des rapports (le designer, ce guide) sans être développeur — une compétence précieuse et autonome. (2) Si vous êtes DÉVELOPPEUR, vous intégrez les rapports (SDK, viewer) — en vous appuyant sur les .rpt fournis par les concepteurs. (3) La collaboration efficace repose sur un bon accord sur les paramètres et la source de données. En résumé : il ne faut PAS être développeur pour CONCEVOIR des rapports (le designer est visuel, accessible aux profils métier) ; il faut l'être pour les INTÉGRER dans une application (code, SDK, viewer, déploiement). Concepteur et développeur collaborent avec des rôles distincts : le concepteur crée/maintient les .rpt (métier, présentation, paramètres), le développeur les intègre dans l'application (chargement, connexion, paramètres par code, déploiement). L'interface est le fichier .rpt et le contrat sur les paramètres. Cette séparation permet aux états d'ÉVOLUER sans redévelopper l'application (remplacer le .rpt) — un grand avantage. Concevoir des états est donc une compétence autonome et valorisée, indépendante du développement, tout en s'intégrant à une chaîne applicative quand c'est nécessaire.