En bref
Qui intègre un composant de planification ou Gantt fixe d’abord qui fait quoi : le composant affiche les vues des temps, des ressources et des hiérarchies et les rend modifiables dans le navigateur ; le produit garde objets métier, droits, dialogues et enregistrement. Une évaluation sur un scénario réel et un volume de données réaliste montre s’il vaut mieux développer soi-même ou intégrer.
Si vous intégrez un composant de planification ou Gantt à votre propre logiciel, commencez par définir la répartition des tâches. Le composant affiche les vues des temps, des ressources et des hiérarchies et les rend modifiables dans le navigateur, tandis que votre produit conserve les objets métier, les droits, les boîtes de dialogue et l’enregistrement. Le choix entre développement interne et intégration dépend surtout du volume de données des grandes vues, de l’interaction nécessaire, de l’accessibilité, de la localisation, de l’effort de maintenance sur la durée et des conditions de licence. Pour répondre à cette question de manière fiable, il faut un scénario réel issu de votre produit et un volume de données réaliste.
Les vues de planification typiques
Les composants de planification présentent le travail sur un axe temporel ou dans une structure. Pour Hawk IVO Scheduler, trois vues sont typiques :
- Planification des temps et des ressources : afficher des ressources, des horaires ou des machines sur l’axe du temps et les déplacer par glisser-déposer.
- Hiérarchies : représenter clairement de grandes structures composées de sites, d’équipes et de ressources.
- Gantt et Kanban : traiter les tâches et les commandes sous forme de barres temporelles ou de tableau.
Les vues dont votre produit a besoin dépendent des objets que vos utilisateurs planifient et de la période qu’ils doivent pouvoir embrasser du regard.
Ce que prend en charge le composant et ce que conserve votre produit
Une intégration ne fonctionne que si les responsabilités sont clairement réparties. Pour Hawk IVO Scheduler, la répartition est la suivante :
| Tâche | Responsable |
|---|---|
| Affichage et modification des vues des temps, des ressources et des hiérarchies | Composant de planification |
| Interaction dans le navigateur | Composant de planification |
| Objets métier, par exemple commandes, horaires ou machines | Votre produit hôte |
| Droits et boîtes de dialogue | Votre produit hôte |
| Enregistrement et souveraineté métier sur les données | Votre produit hôte |
Cette séparation a une raison pratique. Une barre dans la vue représente un objet dont votre produit connaît les règles : qui peut le modifier, quelles informations demande une boîte de dialogue et quand une modification est enregistrée de manière valide. Si ces décisions restent dans le produit hôte, vos droits et vos règles métier s’appliquent sans changement, qu’un utilisateur travaille dans un formulaire ou dans la vue de planification. Pour l’architecture, il faut donc clarifier tôt comment votre produit transmet les données au composant et comment une modification effectuée dans la vue revient dans votre logique métier.
Développement interne ou intégration : les questions pour décider
Une frise chronologique simple peut être réalisée avec un effort raisonnable. L’effort croît avec le volume de données, avec les possibilités de modification et avec les années pendant lesquelles la vue doit être maintenue. Les deux voies peuvent être évaluées à l’aune des mêmes questions :
- Volume de données et grandes vues : combien d’objets affiche la plus grande vue réellement utilisée par vos clients, et sur quelle période ? Reste-t-elle utilisable, au chargement comme lors du défilement, du zoom et de la sélection ? Un test avec vos données dans votre environnement cible est révélateur.
- Interaction : de quelles modifications vos utilisateurs ont-ils besoin, par exemple déplacer un élément, modifier une durée ou réaffecter à une autre ressource ? Comment la vue indique-t-elle que votre logique métier refuse une modification ?
- Accessibilité : les objets de planification peuvent-ils aussi être modifiés sans glisser-déposer et au clavier ? Au niveau AA, les WCAG 2.2 (s’ouvre dans un nouvel onglet) exigent que les fonctions reposant sur un mouvement de glissement puissent aussi être utilisées avec un pointeur unique sans glisser, sauf si le glissement est essentiel (critère de succès 2.5.7). Pour l’utilisation au clavier des vues de type tableau, les WAI-ARIA Authoring Practices décrivent le modèle Grid (s’ouvre dans un nouvel onglet), y compris pour des lignes qui ne sont pas toutes chargées en même temps.
- Localisation : la langue, les formats de date et d’heure, le premier jour de la semaine et le sens d’écriture correspondent-ils aux marchés de vos clients ? Comment la vue gère-t-elle les fuseaux horaires et le changement d’heure ? Dans les pays qui appliquent l’heure d’été, un poste de nuit qui chevauche le changement d’heure est plus court ou plus long que d’habitude. Un projet du groupe de travail Internationalisation du W3C (s’ouvre dans un nouvel onglet) donne des indications pour les applications.
- Maintenance : qui maintient le composant au fil des nouvelles versions de navigateurs, des nouvelles exigences de vos clients et des corrections d’erreurs ? Un développement interne mobilise durablement vos propres capacités de développement. Une intégration crée une dépendance dont vous devriez connaître les versions et les limites connues.
- Licence : à quelles conditions pouvez-vous livrer le composant à vos clients dans votre produit ? Comment le support et les mises à jour sont-ils réglés ?
Le développement interne est indiqué lorsque la vue de planification reste petite ou constitue elle-même le cœur de votre produit. L’intégration est plus indiquée lorsque vos utilisateurs ont besoin de grandes vues et de nombreuses modifications, mais que la force de votre produit réside dans la logique métier.
Le déroulement d’une évaluation
Une démonstration de produit montre ce dont un composant est capable. Pour votre décision, ce qui compte, c’est son comportement avec votre scénario. Pour Hawk IVO Scheduler, nous procédons en trois étapes :
- Choisir un scénario : un scénario de planification concret issu de votre produit, avec un volume de données réaliste.
- Intégrer ensemble : nous montrons l’intégration à l’aide d’un exemple minimal vérifié.
- Évaluer : vous évaluez l’effort, l’ergonomie et les performances dans votre environnement.
Vous disposez ensuite d’une appréciation fondée sur vos propres données, qui permet de comparer développement interne et intégration. Nous convenons de la licence, du support et de l’exploitation sur la base de l’évaluation.
Hawk IVO Scheduler et ses limites
Hawk IVO Scheduler est une bibliothèque intégrable qui affiche les plans de temps, de ressources et de hiérarchies dans le navigateur. Il affiche et permet de modifier de grandes vues des temps, des ressources et des hiérarchies, et il est utilisé dans Hawk IVO Force et Hawk IVO Plan. Votre produit intègre le composant et conserve les objets métier, les droits, les boîtes de dialogue et l’enregistrement.
La bibliothèque n’assume aucune souveraineté métier sur les données. Nous vous indiquons la version, les frameworks pris en charge et les limites connues lors de l’échange technique. Les affirmations sur les performances ne deviennent fiables qu’avec votre scénario, car le volume de données, l’environnement cible et l’utilisation diffèrent d’un produit à l’autre.
Si votre produit doit en outre confier des tâches à des agents, vous trouverez les questions correspondantes dans l’article Intégrer des agents dans votre propre logiciel. Pour en savoir plus sur notre collaboration, consultez l’espace Pour les éditeurs de logiciels. Pour discuter de votre scénario de planification, contactez-nous.